Originally Posted by attila77

It's bull****, pardon my language. I have yet to see a benchmark that does not fall into the trap of the author being more proficient with one language than the other, and therefore skewing the results by his 'stronger' language getting a bias.

Originally Posted by zimon

Even with LLVM, you will suffer if you have used pointers in C++/C program. You just have to throw many of the optimization techniques down the drain when there is a pointer inside some basic block.

Originally Posted by Capt'n Corrupt

Where is this obvious in the post?

The post links to academic papers, rather than pure anecdote.

Originally Posted by attila77

Huh ? The guy explains fairly solidly in what way were the original C++ benchmarks inferior in terms of unoptimal code, i.e. things not done as one would if he was thinking with a 'C++ head' instead of just porting the Java code to C++.

Another, good link explaining why interpreted code can be faster than fully compiled one, beside the two I already mentioned and which may be too technical and theoretic, is this:
http://scribblethink.org/Computer/javaCbenchmark.html
(It is kind of "old" also, but the facts haven't changed since then.)

Here is a relatively fresh benchmark test between Java and C++:
It's a tie!

It's bull****, pardon my language. I have yet to see a benchmark that does not fall into the trap of the author being more proficient with one language than the other, and therefore skewing the results by his 'stronger' language getting a bias. Or you know, realizing that there are different C++ compilers in the world. 3 years ago, most of my Java apps beat my C++ apps speedwise, simply because I knew a lot better how Java works and what is expensive. Nowadays, my C++ runs circles around my Java. So there, there is only one language benchmark that is worth more than a dime - real life.

Originally Posted by Capt'n Corrupt

My question is: where is "all into the trap of the author being more proficient with one language than the other, and therefore skewing the results by his 'stronger' language getting a bias" in the link?

Originally Posted by attila77

I don't see what your issue with that is... "I have yet to see" clearly said that this is my personal impression. It certainly is anecdotal as it draws on my Java/C++ sw developer experience, which has not been published in any IEEE proceedings, but that is exactly the reason why I case-in-point listed and linked information that goes to demonstrate that the original benchmark in question is indeed in no way conclusive.

Originally Posted by attila77

Again, these are the little 'a-ha !' type of rhetorical battles. You say that, I say yeah, but C++ can do stack allocations which eat Java's heap allocation for breakfast, what about casting... And so forth. Each platform has a set of "I do this better than the other one !" and that's why it's so difficult (=impossible) to do a proper comparison.

Originally Posted by Capt'n Corrupt

But I'm not talking about future potential or speed comparisons. What I *am* implying is that there are many factors (eg. cultural) that stand in the way of development using VM. In the case of game development, game developers seem to love C++. And in my experience the most vocal of developers loath change.

But fast games *can* be coded in VM environments (see below). Hell even fast fully 3D games (w/ shaders) can be coded using Javascript (case and point: google's O3D). This was also before many of the fast optimizations to V8 (eg native compilation).

1) the latest Dalvik implementation compiles often used traces into native code with little memory penalty -- ~96-98% computed cycles are native including jumps at around 80KB memory penalty; put another way, very little time is actually spent in the interpreter and the memory consumption is negligible.

2) GC is largely controllable by the developer -- don't allocate new objects/temporary objects -- also, I think in Android the collector can be triggered by the developer (could be wrong). Bottom line, optimization is still a very active process regardless of the environment.

3) Core libraries are natively compiled and VM code (JIT or interpreted) simply calls them.

These are available today. I'm not saying that these optimizations are faster than native. What I *am* saying is that they are fast enough for most tasks -- even the intensive ones: games.

As the JIT trace compile optimizations become more mature, this will improve still, and I suspect the differences between compiled C/C++ and .dex to be negligible.

Bottom line? In this test, non-recursive code is as fast as native compiled code. Recursive is another story altogether, but again, recursive code can be unrolled in the optimization step of development.