Java JRE vs GCJ

Tengo esto es resultado de una prueba de velocidad he escrito en Java:Java JRE vs GCJ

Java 

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

GCJ 

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

Así que, ¿cuál es el propósito de GCJ entonces? ¡Con estos resultados estoy seguro de que no voy a compilarlo con GCJ!

He probado esto en Linux, ¿los resultados en Windows pueden ser mejores que eso?

Este fue el código de la aplicación:

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

I compilado con GCJ así:

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

Y corrió como esto:

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

Fuente

2010-06-13 Martijn Courteaux

¿Por qué está compilando con la depuración (-g) habilitada? –

@Matthew: Lo encontré así en un foro. Pero eso no cambia nada el rendimiento de la misma, creo. –

Sería increíble si el proyecto se reiniciara y tuviera como objetivo más el rendimiento como [jet] (http://mindprod.com/jgloss/jet.html). Porque el lenguaje Java es maravilloso, pero no me gusta la necesidad de una VM. – Youarefunny

GCJ está obsoleto. Comenzó hace mucho tiempo porque la gente quería una alternativa de código abierto para Sun JDK, y nunca fue particularmente buena. Ahora que Sun tiene su JDK de fuente abierta, no hay absolutamente ninguna razón para usar GCJ (pero aún acecha en algunas distribuciones de Linux).

Fuente

2010-06-13 15:25:21

Pero, ¿qué pasa con los entornos sin una JVM? iPad, por ejemplo? –

Ah. OK, fin de la historia. Aún no estaba enterado de eso. No es que esté saltando para un iPad yo mismo ... –

¿El JDK/JRE de Sun no requiere un EULA? Eso lo hace no libre en la mayoría de los estándares de distros, que es una razón para que muchos no lo usen. Creo que OpenJDK está destinado a ser el reemplazo abierto. – detly

Usted ha tropezado con otro producto de la "Libertad del software a cualquier precio" línea de pensamiento. GCJ fue creado para permitir la compilación y ejecución de código Java sin depender de nada considerado "no libre" por el proyecto GNU.

Si valora la libertad del software lo suficiente como para obtener un rendimiento de 12x, entonces, por supuesto, ¡adelante!

El resto de nosotros con gusto utilizaremos el increíble HotSpot JVM de Sun (es decir, Oracle).

Consulte también: 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?"

también: "Se ha fusionado con GNU Classpath y es compatible con la mayoría de las bibliotecas 1.4 1.5 más algunas adiciones." Por lo tanto, también está fuera de fecha el bit.

Fuente

2010-06-13 15:24:15

No está desactualizado, está completamente obsoleto. OpenJDK es lo que está en uso ahora. – detly

Nunca dije nada en contra del software Freedom, y me alegra que OpenJDK exista. Lamento si mi respuesta fue un poco cínica, intento usar y contribuir al software libre cuando puedo, pero elijo soluciones realistas cuando es necesario. –

Estoy contigo, Mark. No veo nada desinformado aquí. Lo que está en cuestión aquí es la idea de GNU de 'gratis', no tuya o mía o de Sun; también la idea de Java de GNU francamente. GCJ y GNU CLASSPATH no son compatibles con todos los 1.2, y mucho menos con todos los lanzamientos posteriores. En cualquier caso, la 'franqueza' de Sun Java ha cambiado radicalmente desde que se iniciaron GCJ y GNU CLASSPATH. – EJP

No es una comparación justa cuando haces la compilación AOT (Ahead-Of-Time) con poca optimización (-O). Pruebe al menos -O2.

Tampoco es tan simple como uno es más rápido que el otro en una sola prueba ideada. La compilación AOT funciona mejor en algunos escenarios. Las JVM funcionan mejor en otras, y también depende en gran medida de la calidad de la JVM. En el mundo real, ecj es notablemente más rápido en la construcción de OpenJDK cuando se compila en AOT que cuando se ejecuta en la JVM. Para aplicaciones de larga ejecución, es probable que la JVM gane porque puede hacer uso de optimizaciones dinámicas que no son posibles antes de tiempo. ecj sufre porque durante el corto período de tiempo que está compilando, la JVM todavía está interpretando el código. HotSpot compila y optimiza el código cuando determina que vale la pena (un "punto caliente").

Por cierto, son las preguntas frecuentes las que están desactualizadas. GCJ es compatible con la mayoría de 1.5, sin duda suficiente para construir OpenJDK. Sin GCJ todavía 'al acecho en algunas distribuciones Linux', no sería posible construir OpenJDK en primer lugar.

Fuente

2010-06-14 15:37:34

en x86 y AMD64, sólo se utiliza hotspot SSE de punto flotante, pero veo que en x86 no parece gcj para apoyar SSE y utiliza las más lentas 387 instrucciones:

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

por lo que podría explicar la diferencia de velocidad.

Tenga en cuenta que cuando GCC usa SSE, supera en gran medida a Hotspot en punto flotante, ya que GCC genera instrucciones SIMD mientras que Hotspot solo usa la aritmética SSE desempaquetada.

Fuente

2011-02-24 14:23:15 damjan

"Entonces, ¿cuál es el propósito de GCJ entonces?"

Algunos han señalado que su "punto de referencia" no es justo. Sin embargo, incluso si lo fuera, aún puedo ver un uso para GCJ. Supongamos que quiere escribir un kernel en Java. Con una JVM, debe trasladar la máquina virtual a un entorno independiente, y luego debería escribir el código de la palanca baja en C. Con un compilador de AOT, puede solucionar este problema con un código de cola y luego puede hacer la baja código de nivel en Java también. No es necesario portar el compilador en este caso.

Además, tenemos que separar la técnica de los puntos de referencia. Tal vez la técnica AOT puede ser más poderosa que la técnica JIT siempre que invirtamos el suficiente esfuerzo de desarrollo en ella.

Fuente

2012-02-23 14:11:56

El compilador de Java nativo de OpenJDK está, en sí mismo, escrito en Java; como consecuencia, necesita una versión anterior de Java para construir una nueva versión.

Si está empezando desde cero en una plataforma para la que no existen binarios JDK disponibles (o si está trabajando dentro de ciertos proyectos de software libre cuyos charters prohíben el uso de dependencias de compilación propietarias), entonces GCJ (o algunos de sus componentes subyacentes) pueden ser una posible solución al problema del huevo y la gallina de poner en marcha un Java bootstrap de trabajo, aunque algo ineficaz, para avanzar y construir el OpenJDK más deseable.

De hecho, cuando se anunció por primera vez OpenJDK, se dedicó un gran esfuerzo (a través del proyecto IcedTea) en la reparación de GCJ para llegar al punto en que estaba a la altura de la tarea.

Fuente

2013-11-13 16:43:46

Java JRE vs GCJ

Respuesta

Cuestiones relacionadas