Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
¿Vas a probar gcj?

Sí, libre mola más   25 votes - 28 %
Según te portes   12 votes - 13 %
No, uso Sun-VM   8 votes - 9 %
No, uso IBM-VM   0 votes - 0 %
No, uso blackdown   2 votes - 2 %
No uso Java   17 votes - 19 %
No me gusta Java   17 votes - 19 %
Sólo uso Rubia-VM   6 votes - 6 %
 
87 Total Votes
Ver: Modo: Orden:
Compilando código Java | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
Resultados más completos (5.00 / 1) (#1)
por man ls a las Tue May 11th, 2004 at 01:37:02 AM CET
(Información Usuario)

Para daros una visión más general del asunto, he hecho una comparativa un poco más a fondo entre la máquina virtual de Sun y el código compilado por gcj. Lo pongo en un comentario, para no distraer de la historia principal.

La primera comparativa es la "null": ejecuta los métodos de prueba pero sin nada dentro. Luego se sustrae a cada prueba el tiempo de esta primera. Todos los tiempos en segundos. Se miden siempre 1000000000 (10^9) iteraciones, excepto en append string donde sólo se realizan 200000 (2*10^5) (porque iba lentísimo en ambos).

El código de Sun se ejecuta así:
$ java -classpath "bin" Benchmarker
y el de gcj:
$ gcj -O5 --main=Benchmarker src/*.java -o benchmark
$ benchmark 
results for null benchmark
java        gcj
0.812       1.527

results for add int benchmark
java        gcj
2.66        0.082

results for add float benchmark
java        gcj
3.703       0.981

results for add double benchmark
java        gcj
2.649       0.985

results for method call benchmark
java        gcj
2.818       0.081

results for create object benchmark
java        gcj
3.081       10.02

results for append string benchmark, 1/5000
java        gcj
4.003       9.583


Mi impresión general es que gcj se porta de maravilla con las operaciones aritméticas y las llamadas a métodos. Sin embargo, la creación de objetos -- y, sobre todo, la recolección automática -- le cuesta más. En general, es bastante impresionante, considerando los años y el esfuerzo que ha dedicado Sun a optimizar tanto el intérprete como el compilador HotSpot.

Máquina de prueba: PIV a 2.4 GHz, 512 MB de RAM, Mandrake 9.2, disco duro a manta. JDK 1.4.2 (HotSpot), gcj 3.3.2. Suministro el código de prueba a cambio de un foskito.


Pueeeeesss.... (4.00 / 1) (#2)
por thuban a las Tue May 11th, 2004 at 09:47:26 AM CET
(Información Usuario)

¿No es un poco decepcionante? Si, esta bien que haya un compilador y un interprete libre, pero ¿creeis que alguien va a usar una maquina virtual que es 35 veces mas lenta que la maquina de Sun? Recordemos que los de Sun son los que inventaron el lenguaje, los que dictan el estandar... En fin. La apuesta segura. Y ademas, es gratis (no se de nadie que haya tenido que pagar por el) tambien.

Puede hacerse que vaya mas deprisa, pero para eso hay que compilarlo (y perder la portabilidad).

A mi se me ocurren tres escenarios en los que se usa java:

* aplicaciones que se escriben una vez con la idea de que se ejecuten en cualquier sitio.

* servidores de JSPs, EJBs y cosas de esas.

* cualquier cosa que se escribe en Java por la sencilla razon de que es lo que sabe el que lo programa.

En el tercer caso no hay mucho que discutir. Se usa Java porque no hay mas remedio. Punto.

En el primero, la ventaja principal es que es portable el binario. Por ejemplo, JEdit es un editor que nos viene muy bien a los que tenemos Linux y Windows en la misma maquina (o en otra que usamos a menudo, como la del trabajo) porque usamos la misma aplicacion en cualquier sitio.

Si se usa gij la aplicacion sera ¡35 veces mas lenta! (o mas, o menos, pero mas lenta). Si se compila para que sea casi ¡el triple! de rapida, se pierde la portabilidad, a parte de que podrian dejar de funcionar cosas como carga dinamica de clases (hablo por hablar, que no lo he probado).

Se pierde la ventaja de usar Java para estas aplicaciones.

En el caso de los servidores empresariales, esos que sirven JSPs, EJBs y similares, no estoy seguro de que funcionen sobre gij, y si lo hacen, como el propio servidor hace compilacion dinamica, pooles de objetos, creacion dinamica y mas cosas de esas que estan tan cerca del lenguaje, es mas que probable que no funcionen bien.

Si se usa el interprete ira muuuucho mas lento, que es algo que en la web no se puede permitir.

Resumiendo: ¿Quien va a preferir el gij al java de Sun?

A mi se me ocurre que en proyectos libres donde se tenga acceso a las fuentes (hay muchas aplicaciones Java por ahi que no tienen accesibles las fuentes) donde no haya que compartir las clases entre varios sistemas operativos tiene mucho sentido hacer el ejecutable nativo (¿cuanto tardara la Gentoo en tener esto?), pero en el caso general, no.





Otras opciones (none / 0) (#3)
por ch3m4 a las Tue May 11th, 2004 at 10:39:00 AM CET
(Información Usuario) http://zaralinux.org

Si se habla de alternativas a la máquina virtual java, vale la pena incluir también el mono y el portablenet (dotGNU). Microsoft ofrece compiladores y "traductores" para pasar código java al entorno .Net , pero en el lado libre existe un proyecto para compilar java a CIL (http://jilc.sourceforge.net/)

En otro orden de cosas, pensaba que el JBoss no tenía la certificación J2EE. Sun ofrece becas para que proyectos de software libre obtengan la certificación, y a JBoss no le han ofrecido estas becas por ser un proyecto perteneciente a una empresa. El único proyecto libre que conozco que ha conseguido una certificación J2EE con estas becas era JOnAS del ObjectWeb.


¿-O5? (none / 0) (#5)
por coder a las Tue May 11th, 2004 at 08:46:24 PM CET
(Información Usuario) http://fluzo.org/

Creo que esa opción no hace más que -O3. Que yo sepa GCC no optimiza más allá de -O3 (y haciendo demasiado "inlining", lo cual no es bueno). Todo lo que pongas a partir de -O4 (incluido) no tiene efecto sobre -O3. ¿O ha cambiado la cosa? ¿GCC 3.4?
atrapado por tu moda


Compilando código Java | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda