Hi,

I have changed the FastMM4 that it seemd to work with fpc now. Here are the results of my prior tests now with FastMM4 for fpc:

Test1:
fpc (standard MM): 3.1 sec - factor = 1.34
fpc (FastMM4): 3.0 sec - factor = 1.30
delphi (standard MM): 3.1 sec - factor = 1.34
delphi (FastMM4): 2.3 sec - factor = 1

Test2:
fpc (standard MM): 2.8 sec - factor = 1.47
fpc (FastMM4): 2.2 sec - factor = 1.15
delphi (standard MM): 2.9 sec - factor = 1.52
delphi (FastMM4): 1.9 sec - factor = 1

Test3:
fpc (standard MM): 2.5 sec - factor = 1,19
fpc (FastMM4): 2.1 sec - factor = 1
delphi (standard MM): 3.4 sec - factor = 1.61
delphi (FastMM4): 2.1 sec - factor = 1

As you can see the benefits are not as big as compared to the standard Delphi MM, but it is still slightly better than the standard MM in fpc (and it reports memory leeks). I have not yet tested all of its features but it seems to work so far.

I've commited another bunch of small optimizations, maybe you can retest. FastMM is implemented in assembler and hand optimized so it's clear that it's rather fast.

I have changed the FastMM4 that it seemd to work with fpc now. Here are the results of my prior tests now with FastMM4 for fpc:

How did you fix FastReallocMem? FPC uses a 'var APointer', but delphi doesn't, apparantly.

Are you using the assembly optimized routines here ?

Micha

I wrote a small wrapper for ReallocMem.

{$ifdef fpc}
function FastReallocMemFP(var APointer: Pointer; ANewSize: Integer):
Pointer;
begin
  if APointer = nil then
    Result:= FastAllocMem(ANewSize)
  else
    Result:= FastReallocMem(APointer, ANewSize);
  APointer:= Result;
end;
{$endif}

In my tests I use the asm routines, but the pascal routines work as well. Only the Debug-routines don't work (or need some overwork), because they access the vmt, which is different in delphi and fpc.

Adrian Veith.

I compiled fpc from the sources from the svn repository today, but the results are almost the same as I posted yesterday (I marked with ** where the results have changed):

Test1:
** fpc (standard MM): 3.0 sec - factor = 1.30
fpc (FastMM4): 2.9 sec - factor = 1.30
delphi (standard MM): 3.1 sec - factor = 1.34
delphi (FastMM4): 2.3 sec - factor = 1

Test2:
fpc (standard MM): 2.8 sec - factor = 1.47
** fpc (FastMM4): 2.1 sec - factor = 1.10
delphi (standard MM): 2.9 sec - factor = 1.52
delphi (FastMM4): 1.9 sec - factor = 1

Test3:
fpc (standard MM): 2.5 sec - factor = 1,19
fpc (FastMM4): 2.1 sec - factor = 1
delphi (standard MM): 3.4 sec - factor = 1.61
delphi (FastMM4): 2.1 sec - factor = 1

I took a look at the MM and found that this test is not representative at all. At least in the FPC MM it triggers only a single code path for Reallocmem. And that code path is even the fastest for a not-in-place-reallocation. And looking at the (unmaintable) FastMM4 sources i guess that the FPC code path is even shorter.

Also i don't know why you make the remark "(and it reports memory leeks)". FPC already supports that for years with the heaptrc units. And with compiling with debug info and adding the lineinfo you get output with source information.

Commited some optimizations (remove some expensive calculations) to the heap for small memory blocks. Please test again.

Strange, for me most tests improved by at least 10 %. Did you use a recompiled rtl compiled with -O3p3r?

He did the test on friday morning. Friday afternoon i commited some optimizations in heap.inc.

Please test again with current svn.

You are right again ;-) I didn't compile the rtl with the new source...

Now it looks like this:

Test1:
fpc (standard MM): 3.0 sec - factor = 1.30
fpc (FastMM4): 2.8 sec - factor = 1.21
delphi (standard MM): 3.1 sec - factor = 1.34
delphi (FastMM4): 2.3 sec - factor = 1

Test2:
fpc (standard MM): 2.1 sec - factor = 1.23
fpc (FastMM4): 1.7 sec - factor = 1
delphi (standard MM): 2.9 sec - factor = 1.70
delphi (FastMM4): 1.9 sec - factor = 1.11

Test3:
fpc (standard MM): 2.3 sec - factor = 1,15
fpc (FastMM4): 2.0 sec - factor = 1
delphi (standard MM): 3.4 sec - factor = 1.70
delphi (FastMM4): 2.1 sec - factor = 1.05

Test1 isn't relevant anymore. And in Test2 and Test3 fpc beats delphi clearly. The benefits for the FastMM4 are now not that big anymore, but it helps to compare delphi and fpc on a fair base, since the impact of the MM is now leveled out.

please forget the remark - after more than 20 years of tp and delphi I am starting with fpc - and i havn't learned yet all the things that are possible with fpc, which are not possible with delphi.

Adrian Veith wrote

Test1 isn't relevant anymore. And in Test2 and Test3 fpc beats delphi clearly. The benefits for the FastMM4 are now not that big anymore, but it helps to compare delphi and fpc on a fair base, since the impact of the MM is now leveled out.

But currently all these optimization have come at the cost of various new bugs in the ansistring handling (and possibly also in the heap manager), so don't use the current 2.1.1 for production work at this time. According to someone else's tests, svn revision 1948 is safe revision 1966 and onwards isn't (I don't think he tested 1949-1965, but 1949 is the one with the first optimizations).

Jonas

I think it's the decr ref. problem, however, it shouldn't have an impact on speed to fix this. I'll look at it tonight.

You can improve test1 by changing the moves in your program to Move(s[1], pointer(AFS)^, AFS.l);
if there is an setlength(afs,...); before.

Background is: all indexed ansistring accesses cause an unique call, however, after a setlength call, the ref. count of a string is 1 so the unique call can be saved. This can be achieve by avoiding the an index ansistring access :) The s[1] doesn't matter because it is passed to a const parameter so no unique call is done.