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

Achilleas Margaritis axilmar at otenet.gr
Fri Apr 27 13:08:31 PDT 2007


You have a point. Unfortunately, my company was a C++ shop and now we 
are moving to Java, and these numbers don't help me persuade them that 
we should stay with C++ for some projects.

I know C/C++ with gc can be faster than Java...but until I can compile 
this library, I can not prove it.

O/H Lothar Scholz έγραψε:
> Hello Achilleas,
> 
> Friday, April 27, 2007, 2:11:44 AM, you wrote:
> AM> C/C++ with multithreaded libgc: 1200 ms
> AM> C/C++ with simple allocator(*): 300 ms
> 
> AM> 4) (*) using a simple allocator which incremented a pointer to an array
> AM> of 256 MB, the test time drop to 300 ms. That's probably the fastest 
> AM> allocation possible, and it shows that it is a shame that we can't have
> AM> native applications with a copying collector.
> 
> Looks like libgc is pretty good. If it is only 4 times slower then the
> easiest and fastest possible case then it is very usefull in real
> applications.
> 
> I must say that after using the gc for a few years in my app, i worry
> anything else more then the garbage collectors runtime. But this is
> only after i added code to NULLify all non used items (at least where
> it is easy to do so). Only the lack of good thread local allocator
> is a thing that still should come soon.
> 
> So my advise: Don't worry to much about an artifical benchmark.
> 



More information about the Gc mailing list