[Gc] Re: conclusions (benchmarking, compilation, failures)
axilmar at otenet.gr
Thu Apr 26 14:51:32 PDT 2007
Thanks for replying.
It was the standard GCBench program provided in the site.
How can I make local allocation work in Windows? the various
headers/docs say that I have to recompile the library with
-DTHREAD_LOCAL_ALLOC, which is available only in Linux.
O/H Boehm, Hans έγραψε:
> 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.
>> -----Original Message-----
>> From: gc-bounces at napali.hpl.hp.com
>> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Achilleas
>> 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
More information about the Gc