Java JRE против 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 следующим образом:

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 (Ahead-Of-Time) с небольшой оптимизацией (-O). Попробуйте хотя бы -O2.

Это также не так просто, как одно быстрее, чем другое на одном опыте. Компиляция AOT лучше всего работает в некоторых сценариях. JVM работают лучше в других, и это также сильно зависит от качества JVM. В реальном мире ecj заметно быстрее при создании OpenJDK при компиляции AOT, а не при запуске на JVM. Для долгосрочных приложений JVM, скорее всего, выиграет, потому что она может использовать динамические оптимизации, которые не могут быть опережающими. ecj страдает, потому что за короткий период, который он компилирует, JVM все еще интерпретирует код. HotSpot компилирует и оптимизирует код, когда он определяет его ценность ( "горячая точка" ).

Кстати, это FAQ, устаревший. GCJ поддерживает большую часть 1.5, что вполне достаточно для создания OpenJDK. Если GCJ все еще "скрывается в некоторых дистрибутивах Linux", в первую очередь невозможно было бы создать OpenJDK.

Ответ 3

В x86 и AMD64 Hotspot использует SSE только для плавающей запятой, но я вижу, что на x86 gcj, похоже, не поддерживает SSE и использует гораздо более медленные инструкции:

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.

Ответ 4

Встроенный Java-компилятор OpenJDK сам, написанный на Java; как следствие, вам нужна рабочая версия Java для создания новой версии.

Если вы начинаете с нуля на платформе, для которой нет доступных двоичных файлов JDK (или если вы работаете в определенных проектах Free Software, чьи уставы запрещают использование зависимых зависимостей сборки), GCJ (или некоторые его базовых компонентов) может быть одним из возможных решений проблемы курица и яйца для получения рабочей, хотя и несколько неэффективной загрузочной Java-платформы, чтобы перейти к созданию более желаемого OpenJDK.

Фактически, когда OpenJDK был впервые анонсирован, значительные усилия (через проект IcedTea) были потрачены на исправление GCJ, чтобы довести его до такой степени, чтобы выполнить задачу.

Ответ 5

"Итак, какова же цель GCJ?"

Некоторые указали, что ваш "бенчмарк" несправедлив. Однако, даже если бы это было так, я все еще вижу использование GCJ. Предположим, вы хотите написать ядро в Java. С помощью JVM вам необходимо поместить виртуальную машину в автономную среду, а затем вам нужно будет написать код с низким рычагом в C. С помощью компилятора AOT вы можете обойти эту проблему с помощью некоторого кода клея, а затем можете сделать низкую код уровня в Java тоже. Нет необходимости переносить компилятор в этом случае.

Кроме того, мы должны отделить технику от тестов. Возможно, технология AOT может быть более мощной, чем технология JIT, при условии, что мы инвестируем в нее достаточно усилий для развития.

Ответ 6

Вы наткнулись на другой продукт "Software Freedom любой ценой!". линии мышления. GCJ был создан, чтобы разрешить компиляцию и выполнение Java-кода, не завися от чего-либо, считающегося "несвободным" проектом GNU.

Если вы цените свободу программного обеспечения, чтобы принять 12-кратное повышение производительности, то, во что бы то ни стало, пойдите для этого!

Остальные из нас будут счастливо использовать Sun (er, Oracle) невероятную JVM HotSpot.

См. также: Часто задаваемые вопросы по GCJ:" Я только что скомпилировал и сравнил свое приложение Java и, похоже, работает медленнее, чем XXX JIT JVM. что я могу сделать, чтобы ускорить его?

Также: "Он был объединен с GNU Classpath и поддерживает большинство из 1.4 библиотек плюс некоторые 1.5 дополнения". Так что это немного устарело.