Re: [computer-go] Pattern Matcher

[Darren Cook <darren@xxxxxxxxx>]

> > I have seen benchmarks where some idiots do just memory allocations and
> > deallocations where java is faster than C. Which is published on the
> > website of Sun.
> >
> > However you can also write the software without stupid memory allocations
> > and deallocations, then the C code is 3 times faster than the java code.
> > ...
> Sorry, Vincent, absolutely not true for Go programming. A straight
> translation of Goliath from C to Java lost about 30% in speed given the
> right choice of JIT. And that was not because of allocation and
> deallocations, as there are zero of that after initialisation.
Hi Mark,
Do you mean you don't do any dynamic memory allocation, and instead are 
using a memory pool or something along those lines so you only allocate 
memory once? If so, I guess only a 30% difference is plausible. Have you 
tried the java compiler (gcj) mentioned earlier to see if the speed 
difference gets even less?

(If I correctly understand Victor's quote above he is saying java dynamic 
memory allocation plus garbage collection is 3 times slower than the same in 
C done without dynamic memory allocation.)

When using C++, with all optimizations on, lots of functions get inlined. 
That allows me the freedom to move code out of the body of loops and into 
functions to make code more understandable, safe in the knowledge there is 
no speed loss. Are the latest java compilers able to do this? In C++ you 
don't use virtual functions when speed is important as they cannot be 
inlined; I thought in Java everything was a virtual function?

As for java being more productive, that is eye of the beholder territory, so 
I won't go there :-). I do wish I had something as good as Eclipse for C++ 
though.

Darren
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/