[Gc] conclusions (benchmarking, compilation, failures)

Boehm, Hans hans.boehm at hp.com
Thu Apr 26 12:57:09 PDT 2007


Thanks.

Which benchmark was this?

This presumably did not use thread-local allocation for the GC?
(Windows support there has unfortunately been behind other platforms.)

Assuming this was GCBench or another similar small allocation benchmark,
the time is often dominated by locking.  I expect that's what you're
seeing with the default allocator, and to a lesser extent with libgc.
It sounds like your dlmalloc was single-threaded, and Java presumably
uses thread-local allocation, so those two are the only ones that lock
on allocation.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Achilleas 
> Margaritis
> Sent: Thursday, April 26, 2007 12:12 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] conclusions (benchmarking, compilation, failures)
> 
> 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
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list