[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Pattern Matcher

Mark,

You wrote:


...memory allocation in Java is faster than in C (which is probably correct, although I don't understand why it is)...

There is a very clever set of strategies used to minimize memory management overhead in Sun's Hotspot JVM:
http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

What I think is novel is how so much advantage is gained by having "free" operations essentially become so low cost as to be essentially immeasurable. And then having no search (through a fragmented memory block availability set) on allocations, just hand back the next available chunk at exactly the right size.

It all comes down to a better "higher level design" as opposed to the "over-optimization" of the status-quo. Sun's claim (backed by studies they performed - clearly biased) is that this one area accounts for some fantastic code speed execution benefits as it "parallelizes" something in Java that is "serialized" in most C/C++ implementations. That, and the amount of time spent managing memory is now even smaller than the time spent in C/C++ memory management implementations, in some cases pretty substantially.


Jim


Mark Boon wrote:


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


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