Java vs C. It's not like one would think.

[OliverBr]

Dear Community,
when I was migrating my chess engine Olithink, written in C, (http://brausch.org/home/chess/) to Java about a decade ago, I didn't expect much.
The more I was surprised about the fact, that the Java version had about 50% if the speed of "C".

If it's not enough, the numbers shifted again. Analyzing this tactical position, with Qd3 winning:
[d]6k1/5p1p/P1pb1nq1/6p1/3P4/1BP2PP1/1P1Nb2P/R1B3K1 b - - 9 9

OliThink 5.4.5, both Java and C, found the move on ply 16 with about 190 million nodes:

C:

Code: Select all

16   282   4003 190190289  g6d3 g1f2 e2f3 d2f3 f6e4 f2e1 e4c3 b2c3 d3c3 e1f2 c3a1 c1g5 a1a6 g5f4 d6f4 g3f4 a6d3 b3a2

Java:

Code: Select all

16   282   5232 190190289  g6d3 g1f2 e2f3 d2f3 f6e4 f2e1 e4c3 b2c3 d3c3 e1f2 c3a1 c1g5 a1a6 g5f4 d6f4 g3f4 a6d3 b3a2

The third number is the time used in cs (1/100 seconds).
Thus Java is hardly faster than C.

Isn't this surprising?

[mar]

Who told you Java should be faster than C?

30% slower is actually an excellent result for Java and I'm impressed and shocked
(I can confirm ~31% on my machine as well - latest 64-bit hotspot vs 64-bit gcc O3).

Hotspot is very good and from what I've seen it produces faster code than C# (.NET)

I wonder if your Java version could be ported to C# and then compare that to the rest as well.
OliThink is the first engine I know of where we have 1:1 conversion by the author himself using two different languages, which is awesome, thanks.

Actually using real programs that behave the same to compare languages is the way to go, some people think that recursive fibonacci is an excellent benchmark, which is sad...

You could probably do better by using some intrinsics (gcc differs from msc and so on, so that would be ugly/nonportable but fast).
Perhaps Java has some bit intrinsics as well?

[OliverBr]

Who told you Java should be faster than C?

It looks that my statements were ambiguous. Of course, C is supposed to be faster than any other language, because it is translated easily 1:1 into machine code.
My "Thus Java is hardly faster than C." was meant to be "hardly slower". Perhaps an admin can change this? Thx!

30% slower is actually an excellent result for Java and I'm impressed and shocked
(I can confirm ~31% on my machine as well - latest 64-bit hotspot vs 64-bit gcc O3).
...
You could probably do better by using some intrinsics (gcc differs from msc and so on, so that would be ugly/nonportable but fast).
Perhaps Java has some bit intrinsics as well?

There aren't such tricks in Java (at least not known to me). Java works completely different, compiles the code into platform independent binary code, which is interpreted during execution.

And this is the amazing part! An interpreted language is only 30% slower. I think, this is the result of a great runtime-optimization, something a rigid machine code cannot do.

[Bo Persson]

There aren't such tricks in Java (at least not known to me). Java works completely different, compiles the code into platform independent binary code, which is interpreted during execution.

And this is the amazing part! An interpreted language is only 30% slower. I think, this is the result of a great runtime-optimization, something a rigid machine code cannot do.

Maybe this is the misunderstanding?

Even though Java initially compiles into some bytecode, the good runtime result is due to its "Just In Time"-compiler that actually produces machine code anyway. It only does it at runtime, instead of in advance.

And, BTW, Oracle's Java Hotspot system is written in C++, so perhaps that language should be attributed for some of the performace.

https://en.wikipedia.org/wiki/HotSpot

[AndrewGrant]

And this is the amazing part! An interpreted language is only 30% slower. I think, this is the result of a great runtime-optimization, something a rigid machine code cannot do.

I find it more likely that slow-java practices translated themselves directly to C, and that the "small" speedgain is hindered entirely by the way you wrote the C version. The JIT can do some cool things, but it cannot recover the disgusting overhead that the JVM requires. Even if you turn off all of Java's safety mechanisms, in an attempt to lay out the same amount of rope for yourself as you would with C, you still outperform a decades old version of GCC.

[nnnnnnnn]

I tried Java a long time ago (long before the Oracle takeover), but I found it awkward at the time to write high-performance code because of all the object wrapping of primitive types that was necessary to get abstraction. At the time there were not even typedefs of primitive types. For instance, if one wanted a 64-bit mask type, one would either have to use some particular primitive type everywhere, like long, or else wrap the mask in an object, which seemed very wasteful. In C++, I can abstract over very lightweight data types like enums, light structs, masks, which makes code much easier to develop.

I also looked at Java very briefly not long after Oracle took it over, but it was a pain to keep the JVM on my machine because it constantly demanded updates (like twice a week if I remember right).

Obviously my experience is absurdly out of date, but I am curious what things are like now: not just whether one can get high-performance Java (one always could if one wrote everything in terms of primitives and arrays) but whether one can write at a high level of abstract and still get good performance.

That said, your experience is interesting!

[mar]

Of course, C is supposed to be faster than any other language, because it is translated easily 1:1 into machine code.

umm, producing optimized machine code is incredibly hard, there's a reason why LLVM is 1M SLOC.

An interpreted language is only 30% slower. I think, this is the result of a great runtime-optimization, something a rigid machine code cannot do.

no interpreter can ever get close to native optimized machine code, slower by a factor of 10-100, YMMV. of course Java bytecode gets translated to machine code.

[jdart]

Obviously my experience is absurdly out of date, but I am curious what things are like now: not just whether one can get high-performance Java (one always could if one wrote everything in terms of primitives and arrays) but whether one can write at a high level of abstract and still get good performance.

Oracle's business applications are written in Java, at least some of them are. This is not something that requires super-high performance. It is "good enough" and the type safety, memory management, etc. features are useful.

--Jno

[jswaff]

OliThink is the first engine I know of where we have 1:1 conversion by the author himself using two different languages, which is awesome, thanks.

Actually I've done the same with chess4j and Prophet. Not only that but there is a JNI layer for the Java code (chess4j) to call the native code (Prophet). It's still a work in progress but you can read about it here : http://www.jamesswafford.com/

In my case the native code is nearly twice as fast.

[OliverBr]

no interpreter can ever get close to native optimized machine code, slower by a factor of 10-100, YMMV. of course Java bytecode gets translated to machine code.

The interpreter named "JVM 64Bit" is only about a factor 1.25 slower than compiled C-Code in terms of my chess engine.
For me: This is quite surprising.