Raytracing: FPC vs Java

[Ñuño_Martínez]

Also try out ppcjvm. FPC is a jvm language too.. With sometimes indeed much faster results compared to true native code.

This puzzled me a lot.  How is it possible an interpreted/virtual machine program is faster than native code?  It should be slightly slower.  Even using "Just in time compile" mode.

[Leledumbo]

Also try out ppcjvm. FPC is a jvm language too.. With sometimes indeed much faster results compared to true native code.

This puzzled me a lot.  How is it possible an interpreted/virtual machine program is faster than native code?  It should be slightly slower.  Even using "Just in time compile" mode.

JIT could win in tight loops or complex calculations, as the VM can decide the best instruction sequence to use at runtime according to the machine where it runs.

[Thaddy]

This puzzled me a lot.  How is it possible an interpreted/virtual machine program is faster than native code?  It should be slightly slower.  Even using "Just in time compile" mode.

http://forum.lazarus.freepascal.org/index.php/topic,35022.msg230871.html#msg230871
Well in this thread I wrote an example that compiled with ppcjvm on a Raspberry pi 3 on Oracle hotspot runs twice as fast as ppcarm compiled armhf-vppv4 code with all proper optimizations.

[lainz]

I need to benchmark V8. I'm using Electron to make small desktop web based applications. It's pretty fast even with large DOM.

I can use Type Script for the classes but I didn't needed it too much.

Java also can have a web browser, also FPC, but I didn't find a way to use them like in Electron.

I'm not used to node.js so I'm not using any third party library, pure JS.

Edit: sorry is not directly related to raycasting, but with benchmarks is.

[marcov]

JIT could win in tight loops or complex calculations, as the VM can decide the best instruction sequence to use at runtime according to the machine where it runs.

Theoretically yes, in practice that barely happens for x86. The codegenerator of JVM is simply better. If you don't have dynamic allocation, the problem of codegeneration is the same as for C and Pascal.

I regularly test against Delphi (which is not really know to be a speedmonster either), and usually FPC lags there, though there are exceptions.

[lainz]

According to this tool, https://github.com/mrdoob/stats.js/

The JavaScript version http://jsrun.it/notch/dB1E, runs constantly at 60 fps. I didn't change the resolution, is the original one.

If I change that to 640x400 it runs at 31-33fps. (of course you need to save the website, edit the sources, width and height in css, width and height in canvas and width and height in code, then run in a local server with this script in the console:

Code: Pascal  [Select][+][-]

1. javascript:(function(){var script=document.createElement('script');script.onload=function(){var stats=new Stats();document.body.appendChild(stats.dom);requestAnimationFrame(function loop(){stats.update();requestAnimationFrame(loop)});};script.src='//rawgit.com/mrdoob/stats.js/master/build/stats.min.js';document.head.appendChild(script);})()

).

Java version runs at 28-31 fps on my machine. (Latest Java 64 bit).

I have 2 theories:
- Notch is really a good programmer, even in javascript he did the best code?
- JavaScript in Chrome is really faster than FPC and Java?
- I need to try with Java 32 bit?

[Leledumbo]

JIT could win in tight loops or complex calculations, as the VM can decide the best instruction sequence to use at runtime according to the machine where it runs.

Theoretically yes, in practice that barely happens for x86. The codegenerator of JVM is simply better. If you don't have dynamic allocation, the problem of codegeneration is the same as for C and Pascal.

I regularly test against Delphi (which is not really know to be a speedmonster either), and usually FPC lags there, though there are exceptions.

Right, as GCC/Clang still wins against Oracle JVM even in microbenchmarks.

[Akira1364]

According to this tool, https://github.com/mrdoob/stats.js/

The JavaScript version http://jsrun.it/notch/dB1E, runs constantly at 60 fps. I didn't change the resolution, is the original one.

If I change that to 640x400 it runs at 31-33fps. (of course you need to save the website, edit the sources, width and height in css, width and height in canvas and width and height in code, then run in a local server with this script in the console:

Code: Pascal  [Select][+][-]

1. javascript:(function(){var script=document.createElement('script');script.onload=function(){var stats=new Stats();document.body.appendChild(stats.dom);requestAnimationFrame(function loop(){stats.update();requestAnimationFrame(loop)});};script.src='//rawgit.com/mrdoob/stats.js/master/build/stats.min.js';document.head.appendChild(script);})()

).

Java version runs at 28-31 fps on my machine. (Latest Java 64 bit).

I have 2 theories:
- Notch is really a good programmer, even in javascript he did the best code?
- JavaScript in Chrome is really faster than FPC and Java?
- I need to try with Java 32 bit?

I think most people in this thread are forgetting that the HTML5 Canvas element is hardware accelerated, and any JavaScript code passed to it is likely optimized behind the scenes and compiled into some kind of GPU-friendly data structure. It's important to keep in mind that Chrome (and all other major browsers) are in fact "native" desktop applications written in C++. This is in contrast to the SDL-based ports we've seen here, which are explicitly not hardware accelerated (even though they're also native applications and easily could be), and simply blit each individual pixel to the SDL surface one by one. The same applies to the Java version: hardware acceleration is not enabled by default in the Java "Graphics" API.

[argb32]

I have 2 theories:
- JavaScript in Chrome is really faster than FPC and Java?

JavaScript in general should be slower than Java or FPC due to language features.
The JS version is not identical to my versions which identical to each other.

[marcov]

I have 2 theories:
- JavaScript in Chrome is really faster than FPC and Java?

JavaScript in general should be slower than Java or FPC due to language features.

What happens here might be the same as the principle for asm.js:  if you only use a certain optimizable subset that is highly optimizable, what ends up at the codegenerator is the same as it would be from a Java, pascal or C/C++ program.

Then it is just codegenerator vs codegenerator, and the language doesn't really matter much.

[lainz]

Good to know.