23

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
4

6 に答える 6

36

GCJ は廃止されました。人々が Sun JDK に代わるオープンソースを望んでいたため、ずっと前に開始されましたが、特に優れたものではありませんでした。Sun が JDK をオープンソース化した今、GCJ を使用する理由はまったくありません (ただし、一部の Linux ディストリビューションにはまだ潜んでいます)。

于 2010-06-13T15:25:21.177 に答える
14

最適化をほとんど行わずに (-O) AOT (Ahead-Of-Time) コンパイルを行う場合、これは公正な比較ではありません。少なくとも -O2 を試してください。

また、1 つの不自然なテストで一方が他方よりも高速であるという単純なものでもありません。一部のシナリオでは、AOT コンパイルが最適に機能します。JVM は他の環境でうまく機能しますが、JVM の品質にも大きく依存します。現実の世界では、ecj は、JVM で実行する場合よりも AOT でコンパイルした場合に OpenJDK をビルドする方が著しく高速です。長時間実行されるアプリケーションの場合、事前に不可能な動的最適化を利用できるため、JVM が勝つ可能性があります。ecj は、コンパイル中の短い期間、JV​​M がまだコードを解釈しているため、問題を抱えています。HotSpot は、価値があると判断した場合 (「ホット スポット」) にコードをコンパイルして最適化します。

ところで、古くなっているのは FAQ です。GCJ は 1.5 のほとんどをサポートしており、OpenJDK を構築するには十分です。GCJ がまだ「一部の Linux ディストリビューションに潜んでいる」ことがなければ、そもそも OpenJDK をビルドすることはできません。

于 2010-06-14T15:37:34.917 に答える
9

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 はアンパックされた SSE 演算のみを使用するのに対し、GCC は SIMD 命令を生成するため、浮動小数点では Hotspot よりもはるかに優れていることに注意してください。

于 2011-02-24T14:23:15.330 に答える
5

OpenJDK のネイティブ Java コンパイラは、それ自体が Java で書かれています。そのため、新しいバージョンをビルドするには、動作する以前のバージョンの Java が必要です。

既存の JDK バイナリがすぐに利用できないプラットフォームでゼロから始める場合 (または、チャーターが独自のビルド依存関係の使用を禁止している特定のフリー ソフトウェア プロジェクトで作業している場合)、GCJ (またはその基礎となるいくつかのコンポーネント) は、より望ましい OpenJDK の構築に進むために、いくらか非効率的なブートストラップ Java を配置するという、ニワトリが先か卵が先かという問題に対する 1 つの潜在的な解決策になる可能性があります。

実際、OpenJDK が最初に発表されたとき、(IcedTea プロジェクトを介して) GCJ を修正するためにかなりの労力が費やされ、GCJ がタスクを実行できるようになりました。

于 2013-11-13T16:43:46.790 に答える
2

「では、GCJの目的は何ですか？」

あなたの「ベンチマーク」は公平ではないと指摘する人もいます。しかし、たとえそうであったとしても、GCJの使用法を見ることができます。Javaでカーネルを作成するとします。JVMを使用する場合は、VMをスタンドアロン環境に移植する必要があります。次に、Cでローレバーコードを記述する必要があります。AOTコンパイラを使用すると、グルーコードを使用してこの問題を回避し、ローレバーコードを実行できます。 Javaのレベルコードも。この場合、コンパイラを移植する必要はありません。

また、テクニックをベンチマークから分離する必要があります。おそらく、AOT手法は、十分な開発努力を投資すれば、JIT手法よりも強力になる可能性があります。

于 2012-02-23T14:11:56.947 に答える
1

「どんな犠牲を払ってもソフトウェアの自由を！」の別の製品に出くわしました。思考回路。GCJ は、GNU プロジェクトによって「非フリー」と見なされるものに依存することなく、Java コードのコンパイルと実行を可能にするために作成されました。

12 倍のパフォーマンス ヒットが発生するほどソフトウェアの自由度を高く評価している場合は、ぜひ試してみてください。

私たちの残りの部分は、Sun (または Oracle) の信じられないほどの HotSpot JVM を喜んで使用します。

参照: GCJ FAQ: 「Java アプリケーションをコンパイルしてベンチマークしたところ、XXX JIT JVM よりも実行速度が遅いようです。速度を上げるためにできることはありますか?」

また、「GNU Classpath と統合され、1.4 ライブラリのほとんどと 1.5 の追加機能をサポートしています。」そのため、これも少し古くなっています。

于 2010-06-13T15:24:15.060 に答える