Comments on: Another Reason Java is Faster than C (maybe)

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Wed, 14 Nov 2007 12:31:14 +0000

For many applications, yes. However for any long-running application the JIT overhead is negligible. JIT compilation time is fixed and finite. A long-running app like a server amortizes this over a long enough period that you won’t notice it.

By: Robert Dinse

Robert Dinse — Tue, 13 Nov 2007 13:22:14 +0000

Just-in-time compilers have the overhead of compiling prior to executing the code; a binary object doesn’t have that overhead. For many applications, the compilation overhead is going to outweigh any microcode tuning advantage. More often than not where x86 architecture is concerned, you’re talking about specialized instructions for video decoding or 3d graphics and not real general purpose functions that will be used by code designed to be platform independent like Java. With respect to Linux, grab the source and compile it yourself, optimized for the platform you’re compiling on. Yes, most distributions are going to compile for the lowest common denominator, truth be told in most areas that won’t matter. But for the kernel and critical code, anything floating point or graphics intensive; compile yourself for the platform for best performance.

By: Frank Berger

Frank Berger — Tue, 20 Mar 2007 07:47:34 +0000

@Lawrence A Java program would be little compiled (JIT) and most interpreted by a jvm.
How do you get that idea? Hotspot compiles often used code and interprets the rest…. What percentage this is depends on the programm

On linux this jvm would be probably compiled for 386 to support all platform, or not ? Why should a Java compiler currently running, let’s say on an X64 stay compatible with an 386? It’s compiled at runtime and thrown away at the end of the program. The compiled code has never to run on an 386. It will compile code for a genuine 386 only if it runs on a 386

By: Jonathan

Jonathan — Thu, 15 Mar 2007 16:51:26 +0000

IBM’s JITC is supposed to have been doing that since at least 1999. E.g., “Simple code scheduling within a basic block is applied to reorder the instructions so that they best fit the requirements of the underlying machine. The JIT compiler has a potential advantage over the traditional compilation technique in that it can identify the type of machine it is running on, and we make use of this information in both code generation and code scheduling.” and
“Different machine instructions are selected, depending on the underlying processor type for some bytecode instructions.” (http://www.research.ibm.com/journal/sj/391/suganuma.html)

I’ve always presumed that Sun’s HotSpot works similar magic; emphasizing SPARC architectures until they started getting serious about selling x86 based machines. They do have at least one related patent anyway (http://www.patentstorm.us/patents/6139199-description.html)

Given the awareness that a JVM can have of the characteristics of the actual hardware it is running on I’ve always been surprised that Java hasn’t beaten C more frequently.

By: Lawrence

Lawrence — Wed, 14 Mar 2007 23:51:22 +0000

Well wait. A Java program would be little compiled (JIT) and most interpreted by a jvm.
On linux this jvm would be probably compiled for 386 to support all platform, or not ?

By: Nicolás Lichtmaier

Nicolás Lichtmaier — Wed, 14 Mar 2007 00:35:15 +0000

Indeed… doesn’t some media players include optimized versions of some some parts of their code for different x86 variants?

By: Xan Gregg

Xan Gregg — Tue, 13 Mar 2007 20:08:49 +0000

When I did some Java vs. C benchmarks a couple years ago (http://www.forthgo.com/blog/java-vs-c-vs-c-at-finding-primes/), I noticed in passing that moving from 64-bit integers to 32-bit integers gave C a big improvement but hardly affected the Java times. I assumed that the JVM noticed that I was running on a 64-bit machine and customized the code for it, but the C compiler had to lock-in early on 32-bit instructions and couldn’t use 64-bit instructions directly. Thus 64-bit integers were costly for C even on a 64-bit machine.

Now, if only they’d get the Range Check Elimination Optimization to be useful (by adding static analysis), they’d be able to really compete on speed.

By: bob

bob — Tue, 13 Mar 2007 16:36:16 +0000

C is only hobbled in this regard when a compiled program is limited to a single architecture.

Fat Mach-O executables can contain any number of architectures or micro-architectures.

In other words, this isn’t a C vs. Java problem, it’s an object-file problem.