[fpc-devel] Re: Compiler bottlenecks

[Adem]

  On 2010-07-15 17:46, Michael Schnell wrote:
>  On 07/15/2010 03:36 PM, Sergei Gorelkin wrote:
>>
>> - FastMM is somewhat slower than FPC's memory manager, but the 
>> difference is small.
> Good to know !
>> - Given the amount of source code in FPC and FastMM, FPC is clearly a 
>> winner :)
> Yep. FastMM uses a lot ASM, so a plus for FPC RTL.
I was curious about the differences about FastMM (which I use under 
Delphi) and TopMM, and asked about it in Delphi ThirdPartyTools NG.

FastMM is a lot more helpful WRT debugging user code, yet TopMM seems to 
have speed advantage for multi-threaded/multi-core application. [I 
haven't done any benchmarks.]

I was particularly interested in how 'Cross Thread performance hit' 
would affect applications --since TopMM mentions it as significant.

Here is the reply I got to that question.

[ 
nntp://forums.codegear.com/embarcadero.public.delphi.thirdpartytools.general/10280 
]

Arnaud BOUCHEZ wrote:

 > > I could live with the others, but what excatly is 'Cross Thread 
performance hit'; I mean, when (under what cirsumstances) would I fall 
for that?
 >
 > The FastMM4 uses a LOCKed asm instruction for every memory allocation 
or dis-allocation. This LOCK ensure that a memory is modified by only a 
thread at a time. This is the same LOCKed asm function which is used 
internally by Windows with its Critical Sections. Windows itself is told 
not to be very multi-core friendly, because it does use a lot of 
critical sections in its internal... Linux is much more advanced, and 
scales pretty well on massive multi-core architectures.
 >
 > On a multi-core CPU, all cores just freeze in order to make this 
LOCKed asm function threadsafe. If you have a lot of threads with more 
than one CPU, the context of every CPU core has to be frozen, cleared, 
all cores wait for the LOCKed asm  instruction to complete, then the 
context is to be retrieved, and execution continue.
 >
 > So a LOCK-free memory manager will improve "Cross Thread performance 
hit" a lot.
 >
 > One another big problem with the current implementation of the Delphi 
compiler is that string types and dynamic arrays just use the same 
LOCKed asm instruction everywhere.
 >
 > See what I wrote here (this post was not very popular, but indeed I 
think I've raised a big issue on the Delphi compiler internals and 
performance here - and I don't think Embarcadero has plans to resolve this):
 > https://forums.codegear.com/thread.jspa?threadID=30826&tstart=90
 >
 > IMHO if you use strings in your application and need speed, using 
another memory manager than FastMM4 is not enough. You'll have to avoid 
most string use, and implement a safe TStringBuilder-like class. 
ShortStrings could be handy here, even if they are limited to 255 
character long. In our enhanced RTL for Delphi 7, we avoid use of this 
LOCKed asm instruction if your application has only one thread: so if 
you use our enhanced RTL, and make thread by yourself (not using the 
TThread object), you'll have th e best multi-thread performance possible.

 From this, I gather TopMM is a "GOOD THING"; and from Ivo's TopMM site, 
he seems to have intentions (TODO) to port TopMM to FPC.

I wonder if it would be a good idea to ask him to speed up that port.

Cheers,

Adem