Java JRE 与 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 JDK 的开源替代品，但它从来都不是特别好。现在 Sun 开源了他们的 JDK，绝对没有理由使用 GCJ（但它仍然潜伏在一些 Linux 发行版中）。

Answer 2

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

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

顺便说一句，这是过时的常见问题解答。 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 算术。

Answer 4

OpenJDK 的本机 Java 编译器本身是用 Java 编写的；因此，您需要一个可以工作的旧版 Java 才能构建新版本。

如果您从头开始在一个没有现成的 JDK 二进制文件的平台上工作（或者如果您正在某些自由软件项目中工作，其章程禁止使用专有的构建依赖项），那么 GCJ（或其某些底层）组件）可能是解决先有鸡还是先有蛋问题的一种潜在解决方案，即获得一个可行的（尽管有些低效的）引导 Java，以便继续构建更理想的 OpenJDK。

事实上，早在 OpenJDK 首次发布时，就花费了大量精力（通过 IcedTea 项目）来修复 GCJ，以使其能够胜任任务。

Answer 5

“那么GCJ的目的是什么？”

有些人指出你的“基准”不公平。然而，即使是这样，我仍然可以看到 GCJ 的用途。假设您想用 Java 编写内核。使用 JVM，您必须将 VM 移植到独立环境，然后您必须用 C 编写低级代码。使用 AOT 编译器，您可以使用一些粘合代码解决此问题，然后可以执行低级代码Java 中的级别代码也是如此。在这种情况下不需要移植编译器。

此外，我们必须将技术与基准分开。如果我们投入足够的开发精力，也许 AOT 技术会比 JIT 技术更强大。

Answer 6

您偶然发现了“不惜任何代价的软件自由！”的另一个产品。的思路。创建 GCJ 是为了允许编译和执行 Java 代码，而不依赖于任何被 GNU 项目视为“非自由”的东西。

如果您重视软件自由度，足以承受 12 倍的性能损失，那么无论如何，就去吧！

我们其他人会很乐意使用 Sun（呃，Oracle）令人难以置信的 HotSpot JVM。

另请参阅：GCJ 常见问题解答：“我刚刚编译并测试了我的 Java 应用程序，它的运行速度似乎比 XXX JIT JVM 慢。我能做些什么来让它运行得更快吗？”

另外：“它已与 GNU 合并类路径并支持大多数 1.4 库以及一些 1.5 新增内容。”所以它也有点过时了。