FP vs Java Benchmark

[Jay]

I'm currently learning Java as well as FP & Lazarus and was curious about the performance of Java compared to FP so thought I'd compare the times to find 100,000 primes. Code for FP:

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

1.   for i := 1 to LIMIT do

Now the Java code (using version 1.8 of the JRE)

Code: Javascript  [Select][+][-]

1.     for(int i = 1; i < limit; i++)

Open your eyes, the bigger, the wider you can !!
After a while you'll see something funny...

oops. It makes very little difference to the results though.

[Jay]

Of course, but generally you would expect native code to out-perform a VM because a VM has an extra layer of abstraction. For the same reason you would expect assembly language to out-perform C.

Today's compilers (at least a few of the major ones) are pretty darn impressive with how they can produced performance ready code. As for your statement amount assembly language - that's highly dependent on the skills of the developer. If I had to try and write assembly now (haven't done so for a very long time), it will mist likely be crap.

https://benchmarksgame.alioth.debian.org/u64q/pascal.html
So because Java beats FP here on most algorithms, is it fair to conclude that Java is a "faster" language than FP? I don't think so.

But the proof is right there in the benchmark results, so how can you still have doubts? ;-)

Because we haven't seen the code, and we don't know which compiler switches were used. E.g. when I re-ran my code with -O3 optimisation it turned out that FP was faster after all.

BTW, I really like your fpGUI toolkit. 

[Thaddy]

If you want jvm, just use FPC for JVM.....Difference gone..... See my example code. Comparing apples and pears.

[guest58172]

I'm currently learning Java as well as FP & Lazarus and was curious about the performance of Java compared to FP so thought I'd compare the times to find 100,000 primes. Code for FP:

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

1.   for i := 1 to LIMIT do

Now the Java code (using version 1.8 of the JRE)

Code: Javascript  [Select][+][-]

1.     for(int i = 1; i < limit; i++)

Open your eyes, the bigger, the wider you can !!
After a while you'll see something funny...

oops. It makes very little difference to the results though.

halstead complexity for Pascal:
for, :=, to: 3 operators.
i, 1 , limit: 3 operands

halstead complexity for Java:
for, = , <, ++: 4 operators
i, 1, limit: 3 operands

Statistically speaking the Pascal for  in this case is less error prone.

But let's take a real case:

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

1.   for i := 0 to LIMIT-1 do

for this case, for, :=, to, - : 4 operators.
for this case, i, 0 , LiMIT, 1: 4 operands.

Code: Javascript  [Select][+][-]

1.     for(int i = 0; i < limit; i++)

for this case, for, =, < , ++: 4 operators too.
for this case, 0, i limit: 3 operands

 

Is it really more simple ?
 

When we remove the error we have Pascal more complex for a for.

[Nitorami]

Quote

https://benchmarksgame.alioth.debian.org/u64q/pascal.html
So because Java beats FP here on most algorithms, is it fair to conclude that Java is a "faster" language than FP? I don't think so.

But the proof is right there in the benchmark results, so how can you still have doubts? ;-)

Rather than simply comparing runtimes, it would be fair to consider the runtime per CPU used, and then FPC and Java appear pretty much on par for all tests, sometimes in favour of Java, sometimes FPC, with one exception, the Mandelbrot. I had a look into that and believe the reason is again (similar to the SDL "tunnel" program) that Java can benefit of SSE vectorization. When looking at the Java code, I wondered why the inner loop calculates two points at a time. This would have no benefit in Pascal, but the intent is probably to help the engine to vectorise it and perform the two calculations simultaneously.

            double nZr1=Zr1*Zr1-Zi1*Zi1+Crb[x+i];
            double nZi1=Zr1*Zi1+Zr1*Zi1+Cib[y];
            Zr1=nZr1;Zi1=nZi1;

            double nZr2=Zr2*Zr2-Zi2*Zi2+Crb[x+i+1];
            double nZi2=Zr2*Zi2+Zr2*Zi2+Cib[y];
            Zr2=nZr2;Zi2=nZi2;

Where vectorization is not possible, there is no big difference in performance relative to CPU performance.

[Thaddy]

Both a modern browser's javascript engine and a Oracle hotspot jvm can and will offload *a lot* to the GPU. Atm this is not always possible yet in pure Pascal written code. (It works with jvm target!)
Current FPC supports modern FPU's, though. In my experience you can achieve good results by tweaking algorithms and FPU settings on a per platform basis.
And be aware of optimizations that FPC currently does not perform yet, or partially. These are often well documented.

[argb32]

Both a modern browser's javascript engine and a Oracle hotspot jvm can and will offload *a lot* to the GPU.

Hotspot doesn't do any transparent use of GPU. Most likely browser Javascript engines too.

[Thaddy]

Hotspot doesn't do any transparent use of GPU. Most likely browser Javascript engines too.

Wrong: both do. Hotspot uses e.g. opencl on certain platforms. Google browsers do the same. OpenCL uses the GPU.
You'll need to have the cutting edge, but "project Sumatra" as this is called is already live on some platforms.
On Raspberry Pi, Google optimized Chrome and Oracle optimized Hotspot using similar technology to utilize the GPU for calculations.

And it is completely transparent to the high level language. No need to play with e.g. OpenCL calls yourself.

Quote from the Oracle employed project lead:
"The HotSpot compiler will now have the capability to compile code for the GPU," explains Frost. "We don't have to target a particular device because the JVM is making the decision at runtime."

It is just a compiler directive, not a language change.

[argb32]

You'll need to have the cutting edge, but "project Sumatra" as this is called is already live on some platforms.

It's interesting project but it seems abandoned now. And there is no any switches to turn on this optimization on current JVM implementations. May be some special builds from branches of OpenJDK.

"The HotSpot compiler will now have the capability to compile code for the GPU," explains Frost. "We don't have to target a particular device because the JVM is making the decision at runtime."

It was said years ago when people believed in bright future of massive-multicore PCs with appropriately designed software. Only such software can benefit from GPU. But that didn't happen for some reason.

[marcov]

Code: Javascript  [Select][+][-]

1.     for(int i = 0; i < limit; i++)

for this case, for, =, < , ++: 4 operators too.
for this case, 0, i limit: 3 operands

5 operands, i three times, and grammar accepts other values for i (so they are separate error possibilities)

Is it really more simple ?
 

Yes, toss javascript

[Thaddy]

It's interesting project but it seems abandoned now. And there is no any switches to turn on this optimization on current JVM implementations. May be some special builds from branches of OpenJDK.

It's not: current work - or spin-off thereof - has been used already. Wait for Java 9 to see it in production Hotspots (or test the special release of the Hotspot on a RaspberryPi 3: enabled by default on Raspbian)