On Fri, Jun 5, 2009 at 9:20 AM, Robert Jacques<[email protected]> wrote: > On Fri, 05 Jun 2009 00:31:50 -0400, Jarrett Billingsley > <[email protected]> wrote: > >> 2009/6/4 davidl <[email protected]>: >>> >>> 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%.
