[Gc] conclusions (benchmarking, compilation, failures)
axilmar at otenet.gr
Thu Apr 26 12:11:44 PDT 2007
Thanks to Christophe Meessen, I successfully compiled the DLL
multithreaded version of the library, and then I downloaded the Java, C,
and C++ benchmarks and run them. Here are the results:
Java with 64M heap: 600 ms
Java with 256M heap: 400 ms
C/C++ with multithreaded libgc: 1200 ms
C/C++ with dlmalloc and new/delete: 400 ms
C/C++ with simple allocator(*): 300 ms
C/C++ with default allocator and new/delete: 22 sec (seconds!)
The compiler was VC8 in release mode with full optimizations.
I had to disable the incremental collection in the C++ test, because it
crashed the program.
1) the Microsoft's malloc implementation is very very slow. It took 22
seconds to finish the benchmark! I did not believe my eyes.
2) using dlmalloc, the C/C++ test came down to 400 ms, including
deletion of objects. That's an impressive 'in your face Java' result.
3) libgc is not as fast as Java! it takes roughly double the time to run
the test in C++ with libgc as in Java :-(. I would like to believe that
C would be as fast as Java, but it is not.
4) (*) using a simple allocator which incremented a pointer to an array
of 256 MB, the test time drop to 300 ms. That's probably the fastest
allocation possible, and it shows that it is a shame that we can't have
native applications with a copying collector.
The test was done on an Athlon 64 3400+, in Windows XP service pack 2,
with 1 GB ram.
Conclusion? libgc is not bad, but it is still a long way from the ideal.
Java is a better solution, as it is right now, considering all the other
More information about the Gc