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
3 ответа
GCJ устарело. Он был начат очень давно, потому что людям нужна была альтернатива Sun JDK с открытым исходным кодом, и она никогда не была особенно хороша. Теперь, когда Sun открыла исходный код своего JDK, нет абсолютно никаких причин использовать GCJ (но он все еще скрывается в некоторых дистрибутивах Linux).
Это нечестное сравнение, когда вы делаете компиляцию AOT (Ahead-Of-Time) с небольшой оптимизацией (-O). Попробуйте хотя бы -O2.
Это также не так просто, что один быстрее другого на одном надуманном тесте. AOT-компиляция лучше работает в некоторых сценариях. JVM работают лучше в других, и это также сильно зависит от качества JVM. В реальном мире ecj заметно быстрее собирает OpenJDK при AOT-компиляции, чем при работе на JVM. Для долго работающих приложений JVM, скорее всего, выиграет, потому что она может использовать динамические оптимизации, которые невозможны заранее. ecj страдает, потому что в течение короткого периода компиляции JVM все еще интерпретирует код. HotSpot компилирует и оптимизирует код, когда считает это целесообразным ("горячая точка").
BTW, это FAQ устарел. GCJ поддерживает большую часть 1.5, безусловно, достаточную для создания OpenJDK. Без GCJ, все еще "скрывающегося в некоторых дистрибутивах Linux", было бы невозможно собрать OpenJDK в первую очередь.
Вы наткнулись на другой продукт «Свободы программного обеспечения любой ценой!» образ мышления. GCJ был создан, чтобы позволить компиляцию и выполнение кода Java независимо от того, что проект GNU считает «несвободным».
Если вы цените свободу программного обеспечения настолько, чтобы снизить производительность в 12 раз, то дерзайте во что бы то ни стало!
Остальные с радостью воспользуются невероятной JVM HotSpot от Sun (ну, Oracle).
Также: «Он был объединен с GNU Classpath и поддерживает большинство библиотек 1.4 плюс некоторые дополнения 1.5». Так что это просто бит тоже устарел.