Java JRE vs GCJ

2022-09-01 21:42:33

我从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

答案 1

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


答案 2

当您进行AOT(提前)编译时,几乎没有优化(-O),这不是一个公平的比较。至少尝试 -O2。

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

顺便说一句,这是过时的常见问题解答。GCJ支持大部分1.5,当然足以构建OpenJDK。如果没有GCJ仍然“潜伏在一些Linux发行版中”,那么首先就不可能构建OpenJDK。


推荐