Java与GCJ

Question

我有一个用Java编写的速度测试的结果：

Java

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

GCJ

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

那么，GCJ的目的是什么呢？有了这个结果，我相信我不会用GCJ编译它！

我在Linux上测试过这个，在Windows中的结果可能比这更好吗？

这是应用程序的代码：

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!!!");
}

我用GCJ编译成这样：

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

然后像这样跑了：

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

Answer 1

GCJ已经过时了。它很久以前就开始了，因为人们想要一个替代Sun的开源替代方案，而且它从来都不是特别好。现在Sun开源了他们的JDK，完全没有理由使用GCJ (但它仍然潜伏在一些Linux发行版中)。

Answer 2

这是一个不公平的比较，当你做AOT (提前)编译很少优化(-O)。至少试试-O2吧。

在单一的人为测试中，它也不像一个比另一个更简单。AOT编译在某些情况下效果最好。JVM在其他方面工作得更好，它也在很大程度上取决于JVM的质量。在现实世界中，ecj在编译OpenJDK时比在JVM上运行要快得多。对于长期运行的应用程序来说，JVM很可能获胜，因为它可以利用不可能提前实现的动态优化。ecj受到了影响，因为它编译的时间很短，JVM仍然在解释代码。当HotSpot确定它是值得的(“热点”)时，它会编译和优化它。

顺便说一句，FAQ已经过时了。GCJ支持1.5的大部分，当然足以构建OpenJDK。如果没有GCJ仍然“潜伏在某些Linux发行版中”，就不可能从一开始就构建OpenJDK。

Answer 3

在x86和AMD64上，Hotspot只对浮点使用SSE，但我看到在x86上，gcj似乎不支持SSE，并且使用了更慢的387条指令：

gcj -O3 -mfpmath=sse --main=Bench Bench.java -o Bench
jc1: warning: SSE instruction set disabled, using 387 arithmetics
/tmp/ccRyR50H.i:1: warning: SSE instruction set disabled, using 387 arithmetics

所以这可以解释速度的差异。

请注意，当GCC确实使用SSE时，它在浮点上的性能大大优于Hotspot，因为GCC生成SIMD指令，Hotspot只使用未打包的SSE算法。