Java JRE vs GCJ

Question

Hi,

I have this results from a speed test I wrote in Java:

Java

real        0m20.626s
user        0m20.257s
sys         0m0.244s

GCJ

real        3m10.567s
user        3m5.168s
sys         0m0.676s

So, what is the but of GCJ then? With this results I'm sure I'm not going to compile it with GCJ!

I tested this on Linux, are the results in Windows maybe better than that?

This was the code from the application:

public static void main(String[] args) {
    String str = "";
    System.out.println("Start!!!");
    for (long i = 0; i < 5000000L; i++) {
        Math.sqrt((double) i);
        Math.pow((double) i, 2.56);
        long j = i * 745L;
        String string = new String(String.valueOf(i));
        string = string.concat(" kaka pipi"); // "Kaka pipi" is a kind of childly call in Dutch. 
        string = new String(string.toUpperCase());
        if (i % 300 == 0) {
            str = "";
        } else {
            str += Long.toHexString(i);
        }
    }
    System.out.println("Stop!!!");
}

I compiled with GCJ like this:

gcj -c -g -O Main.java
gcj --main=speedtest.Main -o Exec Main.o

And ran like this:

time ./Exec                     // For GCJ
time java -jar SpeedTest.jar    // For Java

Answer 1

You have stumbled onto another product of the "Software Freedom at any cost!" line of thinking. GCJ was created to allow compilation and execution of Java code without depending on anything deemed "non-free" by GNU project.

If you value software freedom enough to take a 12x performance hit, then by all means, go for it!

The rest of us will happily use Sun's (er, Oracle's) incredible HotSpot JVM.

See also: The GCJ FAQ: "I have just compiled and benchmarked my Java application and it seems to be running slower than than XXX JIT JVM. Is there anything I can do to make it go faster?"

Also: "It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions." So it's just a bit out of date as well.

Answer 2

GCJ is obsolete. It was started a long time ago because people wanted an open-source alternative to the Sun JDK, and it was never particularly good. Now that Sun open-sourced their JDK, there's absolutely no reason to use GCJ (but it still lurks in some Linux distros).

Answer 3

It's not a fair comparison when you do the AOT (Ahead-Of-Time) compile with little optimisation (-O). Try at least -O2.

It's also not as simple as one is faster than the other on a single contrived test. AOT compilation works best in some scenarios. JVMs work better in others, and it also depends heavily on the quality of the JVM. In the real world, ecj is noticeably faster at building OpenJDK when AOT-compiled rather than when running on the JVM. For long-running applications, the JVM is likely to win because it can make use of dynamic optimisations not possible ahead-of-time. ecj suffers because for the short period it's compiling, the JVM is still interpreting code. HotSpot compiles and optimises code when it determines it's worthwhile (a 'hot spot').

BTW, it's the FAQ that's out of date. GCJ supports most of 1.5, certainly enough to build OpenJDK. Without GCJ still 'lurking in some Linux distros', it wouldn't be possible to build OpenJDK in the first place.