[Gc] Re: conclusions (benchmarking, compilation, failures)

Achilleas Margaritis 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 έγραψε:
> 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