DMD + nedmalloc? last one

Jarrett Billingsley jarrett.billingsley at gmail.com
Fri Jun 5 10:26:36 PDT 2009


On Fri, Jun 5, 2009 at 9:20 AM, Robert Jacques<sandford at jhu.edu> wrote:
> On Fri, 05 Jun 2009 00:31:50 -0400, Jarrett Billingsley
> <jarrett.billingsley at gmail.com> wrote:
>
>> 2009/6/4 davidl <davidl at nospam.org>:
>>>
>>> attachment 7
>>
>> Wow, just.. wow.  I can't believe you got it working :D  Thanks so
>> much; I'm sure other people will find this useful as well!
>>
>> At long last, I was able to test it!  And... amazingly, it was 50%
>> slower than the default malloc/free :\  I even compiled it with
>> optimization enabled.
>>
>> In disbelief, I tried it in my virtualized linux box with GCC as well,
>> and got a similar result, so it doesn't seem to be DMC's fault..
>>
>> Hm.  Maybe it's just supposed to be faster for multithreaded code.
>
> Well, that's not too surprising. From the little bit on nedmalloc's website,
> it looks like dmd and nedmalloc are using very similar algorithms, and D
> knows you're in a single threaded app, nedmalloc doesn't. That said, manual
> use of nedmalloc should be faster under multi-threaded contention, but it's
> not going to improve the GC since it's locking. If you want to improve D's
> allocation performance, I'd suggest looking for and increasing the number of
> pages grabbed from the OS at any one time (it's hopefully a constant
> somewhere in the GC codebase).

MiniD uses its own separate GC and heap, partly for performance (and
what an improvement it has been), and partly so script code does not
trigger full-program GC cycles, important for soft-realtime apps like
games.

MiniD's GC is not terribly fast, but I was more than a little
surprised to see something like 85% of the GC time being spent in
malloc/free than in any other part.  Using nedmalloc pushes that to
about 98%.



More information about the Digitalmars-d mailing list