Originally Posted by Radu

FFS... When you plan to buy a house, do you look at what is available on the market now, or do you look at futuristic designs that MIGHT come in 30 years?
When you buy a car, do you look at the cars there are now on the market, or the cars that will fly?

The Java/VM/JIT being faster than native code with the right tweaks is the biggest bunch of crap ever. How can someone sane believe that compiled code can't do the same stuff that VM/JIT code does? You never heard of stuff such as:
if(platform)do_platform_optimized_stuff();?
Or: If(have_sse)do_sse(); else do_non_sse();

There is NOTHING faster than native code (preferably well written ASM code). When you have the runtime code doing stupid stuff like garbage collection or enforcing array limits, there is a big speed penalty. Remember, the fastest code is the code that is not executed.
There is absolutely no reason for garbage collection, except to accommodate lazy/newbie programmers. Same with not using pointers because omfg, they are evil.

Originally Posted by attila77

Two (well, three) problems.

1. The predictions are based on how native compilers worked ten years ago and assume that they won't *qualitatively* be different in the future. From .NET and LLVM implementation we already know this is not true, so your baseline what you need to get better than IS moving upwards.

2. Occam's razor works against you. You know that the Java-ish VM approach has both advantages and disadvantages. There has been a tanker-loads of money sunk into optimizing it by Sun, IBM and Google. Where this turns into occam's razor is that 5-10 years later, it's still objectively slower, so either the perceived benefits are not as huge or as easily implementable as thought 10 years ago, or everybody at Sun/IBM/Google is an idiot. Your pick.

3. This 'compiler/VM/interpreter technology advances will make all current languages obsolete' is a repeating thing. I remember when lisp/prolog were the next big thing. Just imagine, you don't need to define procedures how tasks are done, so in theory a good interpreter can make a better native code path than a human programmer ever could ! The key here is - in theory. Academic papers will be happy to point out corner cases in which alternative approaches beat out the incumbent one, but we're not in the business of academic papers - software development is engineering, and engineers have the tools of today to build the applications of today.


Disclaimer (again): I was a Java guy, but nowadays I do C++ (w Qt) by day and Python by night.

Unless your application has distinctly non-repetitive usage patterns, the JVM (or CLR, for that matter) will be on-par with C for a good many tasks. I wrote a video decoder in Java for a proprietary codec last year, and surprised the developer of the codec by outperforming his reference C implementation and being easily as fast (maybe a little faster) than his drop-to-MMX optimised version. Why? Because a JVM with a JIT can analyse how your code is running, not just how you or your compiler envisioned it running when the pre-optimised blob was written to disk. The JIT can also decide to use architecture-specific acceleration features (MMX, SSE) without you ever even knowing assembler; if you want to compete with that in C you'll need to cut-off all users below a certain CPU capability threshold and have a *very* good compiler. Frequently called methods that are not overridden in subclasses generally have monomorphic rather than polymorphic dispatch, avoiding a vtable lookup that a virtual method in C++ hard-codes at compilation. Small methods are often inlined into their callers when the running system demonstrates that it is required.

As for developer time: he spent a non-trivial amount of time writing and tweaking the assembler for the block transforms used by the codec. I just translated the vanilla C versions.

The downside? Memory, of course. While my decoder was as fast as the optimised C version, it consumed far more memory, even after a several passes through the code minimising the number of allocations (all that did was give me a very shallow memory growth curve and fewer garbage collects). Also, not all JITs are equal. Just because Dalvik now has a JIT doesn't necessarily put it on a par with modern HotSpot implementations.

There's also the lack of control. You can't shave cycles off of a tight loop by hand-crafting some assembler that takes advantage of some high-level knowledge that you, the programmer, have.

As to your last point, on battery life: the JIT will help here. Code that tries to run as fast as possible will accomplish what it's trying to do sooner; code that's task driven will accomplish those tasks with less load on the CPU. Both mean less of a drain on battery.

Originally Posted by attila77

Zimon, theory is one thing, reality is another (otherwise we'd be using lisp or prolog ). 5-10 years after the papers you mention and a few million (billion?) $ thrown at it by Sun and Google, it's still 'not there yet'. Android giving in to the pressure and being polluted by native code tells the story pretty well. And people wanting to earn their bread and/or geek creds writing code are doing it today - we're talking about *today's* technologies, not the hypothetical performance in some unclear point in the future.

PS. As for time critical - in mobile space 'slow' translates into 'power-hungry' (because it goes against race-to-idle, etc).

Originally Posted by zimon

http://scribblethink.org/Computer/javaCbenchmark.html
(It is kind of "old" also, but the facts haven't changed since then.)

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article.

.......

Two of the most interesting observations regarding this issue are that:

• there is a similar "garbage collection is slow" myth that persists despite decades of evidence to the contrary, and
• that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.

Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject. Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology.

Originally Posted by daperl

Until there's some clarification, I call FUD.

From this link off the same page I see this:

Code:

[keith@leak bench]$ time cpp/nestedloop 45; time cpp/nestedloop-386 45; time java -server -cp java nestedloop 45
-286168967
 
real    0m15.323s
user    0m15.080s
sys     0m0.020s
-286168967
 
real    0m12.915s
user    0m12.630s
sys     0m0.050s
-286168967
 
real    0m23.853s
user    0m23.420s
sys     0m0.040s
[keith@leak bench]$ time java -cp java nestedloop 45
-286168967
 
real    0m32.779s
user    0m32.570s
sys     0m0.080s

Either the graph is wrong, or the above is wrong; I'm guessing the former.

Originally Posted by Capt'n Corrupt

Sorry I don't understand this post -- but would like to. What are you referring to?

Java VM is still getting better and faster. C++ optimizations are pretty much used already and not much else to do

Originally Posted by zimon

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!

There are only two kinds of programming languages: those people always ***** about and those nobody uses.

Originally Posted by attila77

And *I* get fingers pointed at me for dismissing future performance gains Want an example ? Say hello to LLVMs or to the CLR.

In C, consider the code

x = y + 2 * (...)
*p = ...
arr[j] = ...
z = x + ...

Because p could be pointing at x, a C compiler cannot keep x in a register and instead has to write it to cache and read it back -- unless it can figure out where p is pointing at compile time. And because arrays act like pointers in C/C++, the same is true for assignment to array elements: arr[j] could also modify x.