How things change if you just measure loop time? What was optimization level with c++?

If I exclude the array allocation part in the benchmark, Java wins even more (before it was 1.623s s vs 1.514s, now it becomes 1.624s vs 1.414s, it looks like dynamic array allocation in c++ takes virtually no time)

The java version is running under server VM. The c++ version is compiled with g++ and without any flags. I am using windows7 64bits by the way.

Having said that, an aggressive compiler would remove the entire array, as each element is written into, then directly read from, never to be used again, so it could just as well be a register read/write.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I was half listening to someone talking here, and scanned the code very quickly. Seeing a local array of small, static dimension, I must have skipped past the "new". It would never have occurred to me to use "new" in such a case.

Gad's not this again.1) Writing benchmarks that mean anything is a skill and quite difficult to get right when you know what you're doing.2) Never draw generalized conclusion from a well written benchmark.3) Ignore poorly written benchmarks.

I can't comment on the C code, but with java I wouldn't be using System.currentTimeMillis for benchmarking. The resolution of this timer on some systems is notoriously low, with Windows being somewhere around 16ms. When you're looking at result around 1 - 2 seconds, this is significant.

Which would save time because there is no need to allocate the array, write to memory inside the loop, and because comparing registers to zero after doing an arithmetic operation is free.

You should write the contents of numbers to a file. (This does not need to be timed.) It would make optimizing it away impossible. You could also compare the binary values of the double precision numbers. The C++ code may be doing something different and thus produce slightly different numbers.

Edit: Ignore the reverse order optimization I mentioned. It is something Java would probably do that C++ wouldn't if your numbers were integral types, but Java is not allowed to do so for floating point numbers because it would produce different end results.

Would anyone else be surprised if Java was slower than C++ for code fragments that were just plain number crunching? It's almost as if there is a persistent myth that Java is slow or people don't understand that the Hotspot JRE contains an optimizing compiler that produces native machine code.

I'm not surprised by this benchmark. Java can be a bit faster than C/C++ since 2004 except with some specific kinds of algorithm, for example those benefiting the most of the vectorization (SIMD) but the shader language compiler Decora (JavaFX) uses SSE

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org