[java] Java Speed and Native

Quote:

Original post by auric It seems like a good model for speed and portability would be that Sun incorporated and compiler element to virtual machine distributions.

Java hasn't been interpreted for a long time. Java and C# use JIT compiling: the bytecode is compiled to native machine code (and optimized for the particular platform) when the program is executed. This increases startup time on the first run, but improves performance from then on.

Quote:

Compilation could just be part of the install process, Are there any technical reasons that do not allow this to happen??

The absence of an install process prevents compiling as part of said non-existent install process.

Also, Java recompiles the program on-the-fly based on runtime profiling results, anyway.

Quote:

Original post by auric Can anyone fill me in to why native compilation seemed to drop out of the picture?? I can't find any information that's not dated at least 5 years back. It seems like a good model for speed and portability would be that Sun incorporated and compiler element to virtual machine distributions. Compilation could just be part of the install process, Are there any technical reasons that do not allow this to happen?? Is it even necessary? Thanks for any info. p.s. I guess another way to ask would be if a compiler in the C-sense has any memory/efficiency advantages over the JIT.

Well, first, as ToohrVyk said, the point in JIT is that the code *is* compiled to native. It just happens at application startup (or on the fly at runtime)

So your question really boils down to "compile during installation" vs "compile during app startup"

So what are the differences?
- At install time, we don't yet know the final hardware. What if I install a game, then upgrade my CPU? Now, a clever JIT compiler might take advantage of CPU-specific optimizations, but if it was compiled with a different CPU, that's not much use.

What when the game is patched? Then we have to remember to recompile everything during installation of the patch (which in turns makes the patch installer more complex)
If the compilation happens at runtime, we can simply compile from whatever bytecode we've got.

During installation, we don't really have access to much information we couldn't get during "traditional" compilation (as you do with C++). At runtime, we can get access to profiling information and all sorts of statistics on how the code is actually executed. So again, a clever JIT'er can, on the fly, recompile code to better exploit runtime information (such as which branches are usually taken)

So, by compiling during installation, we miss out on a lot of JIT-specific goodies. But we also miss out on the "traditional" offline compilation advantages. Primarily that we can't afford really complex optimizers (players get pissed off if the installer takes 2 hours to compile stuff)

Because the later features of Java, not to mention the advanced concepts of run-time byte-code definition, serialization and instantiation cannot be reasonably implemented using statically compiled code.

Keep in mind that Java's primary market is server-side. There, flexibility and portability outweighs the 10% you could squeeze extra out of static code.

Not to mention that Java VM allows run-time code swapping (change the implementation of an object, add a whole new subsystem, marshall entire implementation over the network, instantiate it, use it) makes development process considerably more flexible.

Add on top of that the virtualization (hey, here's a word you'll be hearing even more during the next year), where entire application is completely separated from the OS, and you get some pretty solid arguments against static compilation.

Quote:

I guess another way to ask would be if a compiler in the C-sense has any memory/efficiency advantages over the JIT

This is a two-edged sword. Yes, JVM has higher footprint for equivalent algorithm in C, plus the additional JVM cost itself.

On the other hand, the extremely elaborate generation garbage collection JVM provides will, in many cases, outperform any manual memory management that wasn't specifically tuned.

The benefits of static compilation are often mis-understood, partially due to requirements C++ imposes. In case of all other modern languages, compilation is just a legacy that completely destroys the progress of languages.

Consider this: Rather than typing in an SQL query, you (everything during run-time) create a new class, define its methods and implementation. Then this class definition gets sent to a remote cluster (50 machines), where new instances are created (they are running windows/linux/unix/osx/all versions). JVM then monitors how this new instance is used (which statements get called more, which ifs are performed more frequently), and then selectively compiles this code into native instructions (using SIMD if available, atomic primitives if supported, choosing optimal register use, ...).

Oh, did I mention all of the above happened in 1.5 seconds?

And all you need to pay is small performance hit on a single machine.

A better question is: Does static compilation really give any benefits over dynamic?

PS: The above example is from a real application that used agent-based approach to perform distributed data analysis queries, and was generating code on-the-fly to achieve optimal computational performance.

Quote:

Original post by auric Can anyone fill me in to why native compilation seemed to drop out of the picture??

That depends on the programming language and the amount of optimization performed by the compiler.

Quote:

Compilation could just be part of the install process, Are there any technical reasons that do not allow this to happen??

That is what Gentoo Linux does (although in a different context for normal executables). But you could run GCJ or another AOT compiler to create a native executable from java bytecode.

Quote:

Original post by ToohrVyk ... Java and C# use JIT compiling ...

No, Java uses HotSpot, not JIT anymore:
http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html

Quote:

Original post by Antheus Oh, did I mention all of the above happened in 1.5 seconds?

... once the JVM is running. But as you said, the primary market of Java is server-side.