15

I realize the benefits of bytecode vs. native code (portability).

But say you always know that your code will run on a x86 architecture, why not then compile for x86 and get the performance benefit?

Note that I am assuming there is a performance gain to native code compilation. Some folks have answered that there could in fact be no gain which is news to me..

Community
  • 1
  • 1
Marcus Leon
  • 55,199
  • 118
  • 297
  • 429

9 Answers9

15

Because the performance gain (if any) is not worth the trouble.

Also, garbage collection is very important for performance. Chances are that the GC of the JVM is better than the one embedded in the compiled executable, say with GCJ.

And just in time compilation can even result in better performance because the JIT has more information are run-time available to optimize the compilation than the compiler at compile-time. See the wikipedia page on JIT.

ewernli
  • 38,045
  • 5
  • 92
  • 123
  • 2
    The second point is important. The JIT can produce better compilation because it has runtime information not available during static compilation. – Steve Kuo Feb 27 '10 at 21:28
  • 1
    It can, or it does? Implementing a highly optimizing dynamic compiler is way more difficult than a static one, especially if you are targeting devices with low computing power (mobile, embedded, etc.) Not all just apps run for months on high-end servers with abundance of CPU and RAM. – Dmitry Leskov Mar 09 '10 at 07:42
  • Another point is that static compilers can take profile information as input. Ours does that to optimize startup time. – Dmitry Leskov Mar 09 '10 at 07:44
  • What happens is not Just in time compilation, which means that code is compiled just before it is run. Hotspot is actually much more advanced and does some form of incremental optimization. Instead of running very fast at the last moment, it looks at the actually used code paths (hotspots) and optimizes those based on the actual runtime profile. Jit in general is not faster than static compilation because it has less time available for compilation. Hotspot and other compile and recompile as you go technologies can be faster. – Paul de Vrieze Apr 14 '10 at 15:17
11

"Solaris" is an operating system, not a CPU architecture. The JVM installed on the actual machine will compile to the native CPU instructions. Solaris could be SPARC, x86, or x86-64 architecture.

Also, the JIT compiler can make processor-specific optimisations depending on which actual CPU family you have. For example, different instruction sequences are faster on Intel CPUs than on AMD CPUs, and a JIT compiler for your exact platform can take advantage of this information to produce highly optimised code.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 1
    @Marcus Also note that the JIT compiler optimizes the code while running; frequently followed code paths can (and will) therefore be optimized. And as the JIT has more / higher level information it can optimize better that a CPU can optimize assembly. – extraneon Feb 27 '10 at 20:54
7

The bytecode runs in a Java Virtual Machine that is compiled for (example) Solaris. It will be optimised like heck for that operating system.

In real-world cases, you see often see equal or better performance from Java code at runtime, by virtue of building on the virtual machine's code for things like memory management - that code will have been evolving and maturing for years.

There's more benefits to building for the JVM than just portability - for example, every time a new JVM is released your compiled bytecode gets any optimisations, algorithmic improvements etc. that come from the best in the business. On the other hand, once you've compiled your C code, that's it.

brabster
  • 42,504
  • 27
  • 146
  • 186
5

Because with Just-In-Time compilation, there is trivial performance benefit.

Actually, many things JIT can actually do faster.

Reverend Gonzo
  • 39,701
  • 6
  • 59
  • 77
  • 1
    Why then so many desktop apps written in java seem to be slower? – Eugeniu Torica Feb 27 '10 at 20:34
  • 5
    UI (Swing) development is difficult to do correctly, and most programmers don't know what the hell they're doing. Swing apps -can- be made extremely responsive, but most programmers don't understand the Swing threading and event system, resulting in horribly inefficient code. – Reverend Gonzo Feb 27 '10 at 20:36
  • 2
    Well I disagree. Look here http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html. There was also another example with c# and c++. But even on this chart up to 100% difference in performance between managed and unmanaged. – Eugeniu Torica Feb 27 '10 at 21:10
4

It's already will be compiled by JIT into Solaris native code, after run. You can't receive any other benefits if you compile it before uploading at target site.

Igor Artamonov
  • 35,450
  • 10
  • 82
  • 113
4

You may, or may not get a performance benefit. But more likely you would get a performance penalty: JIT optimization is not possible with static compilation, so the performance would be only as good as the compiler can make it "blindfolded" (without actually profiling the program and optimizing it accordingly, which is what JIT compilers such as HotSpot does).

It's intuitively quite surprising how cheap (resource-wise) compiling is, and how much can be automatically optimized by just observing the running program. Black magic, but good for us :-)

Joonas Pulakka
  • 36,252
  • 29
  • 106
  • 169
1

All this talk of JITs is about seven years out of date BTW. The technology concerned now is called HotSpot and it isn't just a JIT.

user207421
  • 305,947
  • 44
  • 307
  • 483
1

"why not then compile for x86"

Because then you can't take advantage of the specific features of the particular cpu it gets run on. In particular, if we are to read "compile for x86" as "produce native code that can run on a 386 and its descendants", then the resulting code can't rely on even something as old as the mmx instructions.

As such, the end result is that you need to compile for every exact architecture it'll run on (what about those that does not exist yet), and have the installer select which executable to put into place. Or, I hear the intel C++ compiler will produce several versions of the same function, differing only on cpu features used, and pick the right one at run-time based on what the CPU reports as available.

On the other hand, you can view bytecode as a "half-compiled" source, similar to an intermediate format a native compiler will (unless asked) not actually write to disk. The runtime environment can then do the final compilation, knowing exactly what architecture will be used. This is the given reason why some C#/.net code could slightly outperform c++ code on some cpu-intensive tasks in some benchmarks a while ago.

The "final compilation" of bytecode can also make additional optimalization assumptions that are (from a static compilation perspective) distinctly unsafe*, and just recompile if those assumptions are found wrong later.

MaHuJa
  • 3,148
  • 1
  • 18
  • 6
0

I guess because JIT (just in time) compilation is very advanced.

fastcodejava
  • 39,895
  • 28
  • 133
  • 186