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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
