Quote:
Original post by nullsquared
In fact, notice how most of the measurements for the C version were 0s. The last one in C was either a fluke, or their Java measurements were inaccurate.
So you reject the reality and substitute your own? Your statement means that both Java and C version fluked on same test, and they were both pair-wise correct on every other test.
Quote:
@ Sneftel: Not the point - the same code in Java won't JIT compile to something as efficient or more efficient than the same code in C. Though it'd be interesting to see proof that shows otherwise [smile].
Why not?
Since this is a trivial case, depending on how C code gets compiled, the Java version might put variables closer together, reducing number of cache misses. Just one or two cases as such and you've saved several hundred, perhaps even thousands of cycles.
Code hasn't been a bottleneck in a while now, memory is. And while it cannot be controlled, unless specifically managed in C, JVM might just result in slightly more optimal version, considering we're dealing with arrays, which Java can allocate in place, compared to List<> which requires instances of objects.
Quote:
The JVM is written in C++, therefore something written in Java can only be as fast or slower than the exact equivalent in C/C++.
So C or C++ application can never be faster than something written in assembly?
Some assembly code can be faster than compiled C/C++ code.
BTW, do not underestimate JVM's design. When it comes to large application (1MLOC+), JVM will offer considerably better run-time characteristics than equivalent-effort C++ application precisely due to memory management. I mean this seriously, the micro overhead starts mattering surprisingly little above certain size, without even mentioning the difference in development time.
The biggest problem with Java is its legacy-ridden standard library and abysmal quality of third-party libraries. JVM however is fine, as demonstrated by JRuby, Clojure, Scala, etc... They are a whole different beast.