linux.dsplabs.com.au/forums

[QuantumKnot]

In Fedora 8, there are various ways of compiling and running Java programs. I wrote a simple program (due to time constraints) to test raw speed and the results are consistent, though I'd prefer a more complex program than this

Code: Select all

public class Test {
    public static void main(String [] args) {
        long start = System.currentTimeMillis();
        int p = 0;
        for (int i = 0; i < 1000000000; i++) {
            p += i;
        }
        long end = System.currentTimeMillis();
        System.out.println(end - start + ":" + p);
    }
}

IcedTea JVM (default in Fedora 8)

Code: Select all

java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-b21)
IcedTea Server VM (build 1.7.0-b21, mixed mode)

This is a RedHat project to fill in the missing bits in Sun's OpenJDK project. It uses the same HotSpot mixed-mode interpreter as the Sun version.

Results:

Code: Select all

512:-1243309312

(So it took 512 milliseconds to do all that)

GIJ JVM

Code: Select all

java version "1.5.0"
gij (GNU libgcj) version 4.1.2 20070925 (Red Hat 4.1.2-33)

This appears to be just a bytecode interpreter with no 'Just-in-time' compiler.

Results:

Code: Select all

30042:-1243309312

It took 30 seconds, which confirms the lack of a JIT compiler.

Sun's JVM

Code: Select all

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Server VM (build 1.5.0-b64, mixed mode)

Results:

Code: Select all

509:-1243309312

GCJ Compiler

This is the GNU Java compiler that can compile either to bytecode or native code. I'll choose the native code option.

To compile this to native, I issue the following command:

Code: Select all

gcj -march=core2 -O3 --main=Test -o Test Test.java

Results:

Code: Select all

466:-1243309312

Looks like native code is quite a bit faster. But then, there's more. Remember to hold your bladder in

Code: Select all

gcj -march=core2 -funroll-loops -O3 --main=Test -o Test Test.java

Results:

Code: Select all

58:-1243309312

Of course there is nothing surprising here since this benchmark is a pure loop. But note that the bytecode-based JVMs aren't that efficient with loop optimisation. So if you have lots of loops, then native code is probably the way to go.

[kamil]

hahah I did not realize that there are so many java compiles/interpreters
for the ones not using the byte code, but compiled into native binaries, is there any performance difference between Java based binaries and C/C++ binaries. Or are they identical (gcj vs. gcc/g++), i.e. if you had that for loop example in both java and c, and compiled them using gcj and gcc with the same optimization switches, then would be be reasonable to expect very similar performance? Also, do you know how gcj works? Does it go 'java' -> 'machine code' directly?

[QuantumKnot]

gcj is based on the gcc so the optimisations are the same I think. What I'm not sure is how the garbage collection and dynamic memory is implemented. I might dig up my EM algorithm java code and run some benchmarks on that

I'll test the IBM JVM soon. It used to be the performance king since IBM had a very advanced mixed-mode JIT compiler.

Here's something to blow thou mind away

The Java Faster than C++ Benchmark

[QuantumKnot]

IBM's JVM

Code: Select all

java version "1.6.0"
Java(TM) SE Runtime Environment (build pxi3260-20071123_01)
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20071121_15015 (JIT enabled)
J9VM - 20071121_015015_lHdSMR
JIT  - r9_20071121_1330
GC   - 20071031_AA)
JCL  - 20071118_01

Results:

Code: Select all

569:-1243309312