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

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, bob, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mar
Posts: 2184
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

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

Post by mar » Wed Jun 24, 2020 1:40 am

OliverBr wrote:
Tue Jun 23, 2020 11:57 pm
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.
You seem to misunderstand what an interpreter is. JVM compiles bytecode to machine code, it may interpret, but that would be horrendlously slow (just try interpreted Python). An interpreter is basically a giant switch/jumptable on virtual opcodes, I stand by my numbers. 10-100 times slower than native code, depending on what you do. Obviously you can't get 1.25 factor with any interpreter vs native code.
Even the worst generated machine code (like in my scripting language) will beat the best interpreters easily by a significant amount.
Martin Sedlak

Dann Corbit
Posts: 11621
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

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

Post by Dann Corbit » Wed Jun 24, 2020 9:37 am

That is because with a JIT compiler, it is compiled on the fly.
So the difference of compiled/interpreted is nearly vanished.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
hgm
Posts: 24911
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

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

Post by hgm » Wed Jun 24, 2020 11:05 am

It depends on how powerful the 'instructions' of the interpreted language are. If it would take hundreds of machine instructions to perform the action of a typical interpreted instruction (like you would have in a language that describes large vector or matrix operations) you would only waste a few percent on fetching and decoding. But if your instructions represent loads and stores of integer data to memory, or simple ALU operations, yes, the you would at least lose a factor 10.
Get rid of the shit: vote for SHID!

mar
Posts: 2184
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

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

Post by mar » Wed Jun 24, 2020 3:35 pm

Right, except that such super-instructions have to be useful in the first place. For large vector/matrix operations, it would be better to simply implement these in optimized C/C++/... (or even offload to a GPU) and expose them as functions to the (scripting) language (this is what Python does, binding to optimized C libraries).

both Lua and Python already have power instructions, like table/dictionary lookups, Lua even has a support opcodes to speed up the for loops etc.

One could expose something like vector instructions (SSE/AVX, I believe WebAssembly has a proposal for those) but then you need a compiler than can auto-vectorize your code, which is no easy task. And let's not forget that you still need control flow instructions to do something useful (like playing chess :)

I saw a nice trick in the 32-bit days, where bytecode (32-bit instructions) was interleaved with a 32-bit pointer containing the address to handle the next opcode, bypassing the cost of decoding the opcode and dispatching via indirect jump table, but that doesn't change the fact that interpreters are very slow in general.

My point is that no interpreter can ever get close to optimized native code and so far I've found nothing that would get even remotely close in general case in terms of performance. And performance always matters, contrary to popular belief that it doesn't.

And of course that a JIT compiler is not an interpreter... in fact I believe that it should be called JIT optimizer rather than compiler
Martin Sedlak

Post Reply