Slow GC?

bearophile bearophileHUGS at lycos.com
Fri Mar 14 19:47:18 PDT 2008


Vladimir Panteleev:

>Yes, just apply the patch (to src/phobos/internal/gc/gcx.d) and rebuild Phobos (using the makefiles).<

I'm sure for most of you doing this is really easy, but for me it wasn't an immediate thing. I have succed.

Phobos of DMD 1.028 for Win compiled with the patch (I'll keep them online for just few days):
http://www.fantascienza.net/leonardo/phobos.7z
Or bigger download (use the smaller if possible):
http://www.fantascienza.net/leonardo/phobos.zip
I suggest interested people to try this patch, to find if it gives improvements or the opposite to code that uses the GC.


>Here are the exact times for me:<

My timings, the deallocation is about 9 times faster!

OLD TIMINGS, with GC:
loading time: 0.41 s
splitting time: 3.76 s
TOTAL time: 11.4 s

OLD TIMINGS, without GC:
loading time: 0.40 s
splitting time: 0.67 s
TOTAL time: 8.25 s


NEW TIMINGS, with GC:
loading time: 0.39 s
splitting time: 0.8 s
TOTAL time: 1.71 s

NEW TIMINGS, without GC:
loading time: 0.39 s
splitting time: 0.67 s
TOTAL time: 1.58 s


The generation of a a long list of matches with a regex like the following one goes from 7.63s to 3.28s:
auto txt = cast(string)read("text.txt");
auto words = RegExp("[a-z]+", "g").match(txt);


The "bintrees" benchmark of the Shootout version (with the version of the code that doesn't use manual memory management. The code is online in that site, look for my nick in the code) goes (with input n = 15) from 42.1s to 34.1s.


>Good optimizations often require significant and complicated changes to the code. Luckily this one doesn't :)<

I know, things aren't easy, but:
- Various tests have shown me that the D GC is (was? With this patch it may be a bit faster in some situations) up to 10-11 times slower than the GC of the last Java, so I presume there's space for improvements.
- Comparing the speed of the same programs from D to other fast languages (C with GCC, OcaML, Clean, etc) helps you to *know* the spots where the performance is bad. Then later you can let things as they are, or you can try to improve things. Otherwise you just are ignorant and you can't even start thinking about solving problems. It's like a higher-level form of code (language) profiling :-)

And by the way, now the D program I was talking about is about 15% faster than the Python version ;-)

Bye and thank you,
bearophile



More information about the Digitalmars-d mailing list