Java JRE vs GCJ

Question

mam Wynika to z testu prędkości pisałem w Java:

Java 

real  0m20.626s 
user  0m20.257s 
sys   0m0.244s 

GCJ 

real  3m10.567s 
user  3m5.168s 
sys   0m0.676s 

Więc, co jest celem GCJ wtedy? Dzięki tym wynikom jestem pewien, że nie skompiluję go z GCJ!

Testowałem to na Linuksie, czy wyniki w Windows mogą być lepsze?

To był kod z aplikacji:

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!!!"); 
} 

skompilowany z GCJ tak:

gcj -c -g -O Main.java 
gcj --main=speedtest.Main -o Exec Main.o 

i pobiegł tak:

time ./Exec      // For GCJ 
time java -jar SpeedTest.jar // For Java 

Answer 1

GCJ jest przestarzały. Zaczęło się dawno temu, ponieważ ludzie chcieli mieć alternatywę dla JDK-a o otwartym kodzie źródłowym i nigdy nie było to szczególnie dobre. Teraz, kiedy Sun ma już open-source swojego JDK, nie ma absolutnie żadnego powodu, aby używać GCJ (ale nadal czai się w niektórych dystrybucjach Linuksa).

Answer 2

Natknąłeś na inny produkt "Software Freedom za wszelką cenę!" linia myślenia. GCJ został stworzony, aby umożliwić kompilację i wykonanie kodu Java bez zależności od niczego, co zostało uznane za "niewolne" przez projekt GNU.

Jeśli cenisz sobie wolność oprogramowania wystarczającą do uzyskania 12-krotnego trafienia, to na wszelki wypadek, idź do niego!

Reszta z nas chętnie użyje niewiarygodnej maszyny wirtualnej HotSpot JVM firmy Sun (er, Oracle).

Zobacz także: 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?"

również: "Zostało ono połączone z GNU Classpath i obsługuje większość bibliotek 1.4 plus kilka dodatków 1.5" Więc jest to po prostu nieaktualna wersja bit.

Answer 3

To nie jest uczciwe porównanie, gdy robisz AOT (naprzód-czas) kompilacji z małą optymalizacją (-O). Spróbuj co najmniej -O2.

Nie jest to również tak proste, jak jedno jest szybsze od drugiego na jednym wymyślonym teście. Kompilacja AOT działa najlepiej w niektórych scenariuszach. Maszyny JVM działają lepiej w innych, a także w dużej mierze zależą od jakości maszyny JVM. W świecie rzeczywistym, ecj jest zauważalnie szybszy przy budowaniu OpenJDK, gdy kompilowane są AOT, a nie podczas pracy na JVM. W przypadku długotrwałych aplikacji JVM może wygrać, ponieważ może wykorzystywać dynamiczne optymalizacje, które nie są możliwe z wyprzedzeniem. ecj cierpi, ponieważ przez krótki okres, który kompiluje, JVM wciąż interpretuje kod. HotSpot kompiluje i optymalizuje kod, gdy ustali, że warto ("gorący punkt").

BTW, najczęściej zadawane pytania są nieaktualne. GCJ obsługuje większość wersji 1.5, z pewnością wystarczającą do zbudowania OpenJDK. Bez GCJ wciąż "czającego się w niektórych dystrybucjach Linuksa", nie byłoby możliwe zbudowanie OpenJDK w pierwszej kolejności.

Answer 4

Na x86 i AMD64, tylko Hotspot używa SSE dla zmiennoprzecinkowych, ale widzę, że na x86 gcj nie wydaje się wspierać SSE i wykorzystuje znacznie wolniej 387 instrukcji:

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 

tak, że może wyjaśnić różnica prędkości.

Należy pamiętać, że gdy GCC używa SSE, znacznie przewyższa Hotspot na punkcie zmiennoprzecinkowym, ponieważ GCC generuje instrukcje SIMD, podczas gdy Hotspot używa tylko rozpakowanej arytmetyki SSE.

Answer 5

"Jaki jest zatem cel GCJ?"

Niektórzy wskazywali, że twój "poziom odniesienia" nie jest sprawiedliwy. Jednak nawet jeśli tak było, nadal widzę zastosowanie dla GCJ. Załóżmy, że chcesz napisać jądro w Javie. Przy maszynie JVM musisz przenieść maszynę wirtualną do samodzielnego środowiska, a następnie będziesz musiał napisać kod niskiej dźwigni w C. Dzięki kompilatorowi AOT możesz obejść ten problem z pewnym kodem kleju, a następnie możesz wykonać niski poziom. kod poziomu w Javie też. W tym przypadku nie trzeba przesyłać kompilatora.

Musimy również oddzielić technikę od benchmarków. Być może technika AOT może być silniejsza niż technika JIT pod warunkiem, że zainwestujemy w nią tyle wysiłku.

Answer 6

Natywny kompilator Java OpenJDK sam jest napisany w Javie; w związku z tym potrzebna jest działająca poprzednia wersja Java w celu zbudowania nowej wersji.

Jeśli zaczynasz od zera na platformie, dla której żadne pliki binarne JDK nie są łatwo dostępne (lub jeśli pracujesz w ramach niektórych projektów wolnego oprogramowania, których czartery zabraniają używania zależnych zależności budowania), to GCJ (lub niektóre z jego podstawowych składników) mogą stanowić potencjalne rozwiązanie problemu kurczaków i jaj, polegającego na uzyskaniu działającej, aczkolwiek nieco nieefektywnej Java do ładowania początkowego, w celu przejścia do budowy bardziej pożądanego OpenJDK.

W rzeczywistości, po pierwszym ogłoszeniu OpenJDK, znaczny wysiłek (za pośrednictwem projektu IcedTea) został poświęcony na naprawę GCJ, aby doprowadzić go do punktu, w którym to było do wykonania.