javajre与GCJ

我用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 -c -g -O Main.java
gcj --main=speedtest.Main -o Exec Main.o

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

---

你偶然发现了另一种“不惜一切代价实现软件自由”的想法。GCJ的创建是为了允许编译和执行Java代码，而不依赖GNU项目认为“非免费”的任何东西

如果你对软件自由的重视程度足以让你在性能上获得12倍的成功，那就千方百计去争取吧

我们中的其他人将乐于使用Sun（呃，Oracle）令人难以置信的HotSpot JVM

另见：

---

另外：“它已经与GNU类路径合并，支持大多数1.4库和一些1.5添加。”因此它也有点过时。

GCJ已经过时。它在很久以前就开始了，因为人们想要一个开源的替代品来代替sunjdk，而且它从来都不是特别好。既然Sun已经开放了JDK的源代码，那么绝对没有理由使用GCJ（但它仍然潜伏在一些Linux发行版中）。

当您（提前）进行AOT编译时，很少进行优化（-O），这不是一个公平的比较。至少试试-O2

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

---

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

在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算法。

“那么，GCJ的用途是什么？”

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

---

此外，我们必须将技术与基准分离。如果我们在AOT技术上投入足够的开发精力，那么AOT技术可能比JIT技术更强大。

OpenJDK的原生Java编译器本身就是用Java编写的；因此，为了构建新版本，您需要一个可用的Java早期版本

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

---

事实上，早在OpenJDK第一次发布时，就花了大量精力（通过IcedTea项目）来修复GCJ，使其达到可以完成任务的程度。

但是没有JVM的环境又如何呢？比如说iPad？啊。好了，故事结束了。我还不知道。并不是说我自己就想买iPad……Sun的JDK/JRE不需要EULA吗？这使得它在大多数发行版标准下都是非免费的，这也是许多人不使用它的原因。我相信OpenJDK是为了取代OpenJDK。是的，OpenJDK就是我的意思。（顺便问一下，有人理解OpenJDK和Sun JDK之间的区别吗？它们不是完全由相同的源代码构建的吗？@Mike，还没有，因为Sun JDK包含一些第三方专有代码。然而，OpenJDK是未来开发的重点，他们正试图摆脱所有与GPL不兼容的代码。为什么要启用调试（-g）进行编译？@Matthew:我在论坛上发现了这种情况。但我认为，这并不会改变它的性能。如果重新启动该项目，并将目标更多地放在性能上，那将是非常棒的。因为Java语言很棒，但我不喜欢虚拟机的必要性。@你很有趣：没有虚拟机，Java是不可能的。即使将类编译为本机二进制文件，它们仍然需要Java内存管理、垃圾收集、线程、JNI等。除非你的Java应用程序在复杂度上与“Hello world”相差一个数量级，否则你无法将其自动转换为功能上等价的C程序，而不会产生所有的“开销”。“Kaka pipi”在我听来像古德语，可以追溯到罗马时代，当时他们正在与他们战斗，并且在战斗中经常尖叫。它不仅过时，而且完全不受欢迎。OpenJDK现在正在使用。我从未说过任何反对软件自由的话，我很高兴OpenJDK的存在。我很抱歉，如果我的回答有点愤世嫉俗，我会尽可能地使用和贡献自由软件，但如果需要，我会选择现实的解决方案