[Gc] Re: conclusions (benchmarking, compilation, failures)
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
> 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