RE: [computer-go] Pattern Matcher

["Mark Boon" <tesuji@xxxxxxxxx>]

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Darren Cook
> Sent: Monday, November 08, 2004 23:22
> To: computer-go
> Subject: Re: [computer-go] Pattern Matcher
>
>
> >>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?

Yes, I use object pools. No, I haven't tried gcj.

>
> (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?

This is tricky actually. Most of the time moving variables into a 'get'
method is the same speed as accessing the member variable directly. But
often in a profiler the cost of a method-call shows up, which is very
annoying and at times makes it a little harder to monitor optimizations.

In Java 'in principle' every method is equivalent to a pure virtual method.
Most of the time the compiler is smart enough though to recognise when it
can be optimised to a non-virtual method call. Sometimes, when the compiler
is stubborn, you can help it a little by declaring the method 'final' but I
find this makes less and less of a difference. I suppose the compilers are
getting better.

Lastly, no I don't think you understood Vincent correctly. He seems to think
memory allocation in Java is faster than in C (which is probably correct,
although I don't understand why it is) and that code that does NOT use
memory allocation at all runs 3 times faster in C (or C++?) than in Java.

On an altogether note: when running the same program in debugging mode, in
Java there's only a minor performance hit. In C++ the difference is more
like 10 times slower in debugging mode. Why is this? Not to mention of
course the difference in compilation-speed with all optimizations on. Are C
compilers one or two orders of magnitude slower?

> 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/
>

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