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

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

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

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

Смотрите также: The GCJ FAQ: "I have just compiled and benchmarked my Java application and it seems to be running slower than than XXX JIT JVM. Is there anything I can do to make it go faster?"

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

Answer 3

Это не справедливое сравнение, когда вы делаете AOT (Ahead-Of-Time) с небольшой оптимизацией (-O). Попробуйте хотя бы -O2.

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

BTW, это часто задаваемые вопросы, которые устарели. GCJ поддерживает большую часть 1.5, что вполне достаточно для создания OpenJDK. Без GCJ, все еще «скрывающегося в некоторых дистрибутивах Linux», было бы невозможно создать OpenJDK в первую очередь.

Answer 4

На 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, он значительно превосходит точку доступа с плавающей точкой, поскольку GCC генерирует SIMD-команды, а Hotspot использует только распакованную SSE-арифметику.

Answer 5

«Итак, в чем же цель GCJ?»

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

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

Answer 6

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

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

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