This is one of the most balanced analysis of the shootout I've read so far. Since google groups has not yet started displaying this thread over at comp.lang.c++.moderated (I was able to get it out of my news reader), I am copying it verbatim here:
glenlow at pixelglow dot com (Glen Low) wrote in message
news:<9215d7ac dot 0406151559 dot 2b45e595 at posting dot google dot com>...
> Another Java vs C++ performance shootout:
>
http://kano.net/javabench/ > Anyone care to comment about the appropriateness of his C++ code and
> compiler settings?
When I'm benchmarking for speed, I use -O3 with g++, not -O2. That's
definitly an error on his part.
I glanced at a few of the tests. For the most part, they are pretty low
level; it's hard to say what significance they have with regards to real
code.
The hash code tests actually test how good the hashing function is. The
default algorithm used by g++ is definitly bad for large numbers of
short strings (it will cluster near the front of the table), but I've
not done enough analysis to be able to say exactly what is too large or
too short.
It would be interesting to see what happens with more complex data
structures, like std::vector (and push_back) vs. java.util.Vector. Java
has a decided advantage in array handling, because of the absense of
aliasing. As soon as you use any data structure other than an Array of a
built-in type, however, you need to dynamically allocate each element in
the structure. Relocating garbage collection generally results in much
faster allocation than you can get with operator new in C++, but even
the fastest allocation can't compete with no allocation.
Note too that while garbage collection allocation is typically much
faster than manual allocation (perhaps an order of magnitude or so),
this is partitially offset by the time you spend collecting. His
programs allocate little enough that he probably never needs to collect.
The small size of the programs are a definite advantage for Java's
runtime optimizer. A run-time optimizer can't spend forever optimizing,
but it has access to actual run-time data, AND can specialize its
optimization for the specific processor. (G++, and most other C++
compilers, have flags to allow this as well.) Given the small size, a
complete analysis of the program is possible in the limited time
available, and given the other additional data, I would find it rather
worrisome if Java didn't do better. I'm more sceptical with regards to
real programs, however. If there really is one small critical loop,
Java should win; that's not the case for most of my programs, however.
And of course, g++ is far (very far) from state of the art optimizing,
especially (so I've been told) for Intel architectures.
All that said, however, for many applications, there will be little or
no difference in speed between Java and C++. Java has a number of
advantages which make life easier for the optimizer, and for most
applications, garbage collection will be faster than manual memory
management, but the fact that everything has to be dynamically allocated
can cost a lot.
In the end, of course, performance isn't necessarily the key argument.
For most of the work I do, safety is. And that is a criteria where C++
is a clear winner; it is very, very difficult to write correct programs
of any significant size in Java. (It's not really that easy in C++, but
at least the language never actively prevents you from doing the right
thing.)
--
James Kanze GABI Software
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
