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

Это также не так просто, так как один быстрее, чем другой в одном надуманном тесте.Компиляция AOT работает лучше всего в некоторых сценариях.JVM лучше работают в других, и это также сильно зависит от качества JVM.В реальном мире ecj заметно быстрее создает OpenJDK при компиляции AOT, а не при работе на 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

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

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

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

Answer 5

«Итак, какова цель GCJ тогда?»

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

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

Answer 6

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

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

Остальные из нас с радостью будут использовать невероятную виртуальную виртуальную машину Sun (или Oracle).

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

Также:" Оно было объединено с GNU Classpath и поддерживает большинствоиз библиотек 1,4 плюс некоторые дополнения 1,5 ".Так что это просто бит устаревший.