[Gc] conclusions (benchmarking, compilation, failures)

Achilleas Margaritis axilmar at otenet.gr
Thu Apr 26 12:11:44 PDT 2007


Hello all.

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.

Some notes:

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 
factors.

Achilleas Margaritis



More information about the Gc mailing list