🚀 go-pugleaf

Alberto Planas Dominguez wrote:
> 
> Jonathan Revusky wrote:
> 
> [Se comentaba que...]
> > > Hay una diferencia ESENCIAL  entre JAVA y C que claramenteproporciona portabilidad >frente a velocidad.
> >
> > La otra cosa que matizar�a es que creo que lo de arriba es un falso
> > paralelismo. Se puede decir de modo muy tajante que Java es m�s portable
> > que C. Pero no se puede decir lo mismo sobre la velocidad de C. Y de
> > hecho, la velocidad no es una prestaci�n de un lenguaje realmente. Es
> > una prestaci�n de una implementaci�n de un lenguaje. El �nico modo en
> > que se puede afirmar de modo tajante que C es mucho m�s r�pido que Java
> > -- y quiero decir como regla -- ser�a comparando el C compilado con Java
> > interpretado. Y esa es claramente una comparaci�n injusta.
> 
>   Una notilla sobre la �velocidad del lengiaje�. Creo que algunas ideas
> no se tienen muy claras respecto a lo que es un lenguaje. Es mucho mas
> util considerar el lenguaje como el conjunto de reglas lexicas,
> sintacticas y semanticas que nos permiten expresar un algoritmo. Los
> lenguajes incorporan en estas reglas facilidades para expresar y
> entender estos conceptos. Por esa misma razon un lenguaje no puede ser
> mas rapido que otro. La velocidad aqui seria responsabilidad del
> algoritmo utilizado.

Bueno, eso suena como un pasaje de un libro de texto de universidad. Lo
le� y me pareci� como uno de esas afirmaciones te�ricas que tiene alg�n
defecto y finalmente, me parece que lo he descubierto. Supongo que la
afirmaci�n es cierta, pero es que pasa por alto un aspecto de las cosas,
la noci�n del uso "idiom�tico" del lenguaje. Es decir, si coges un
programa en C y pasas el algor�tmo directamente a Java sin m�s, supongo
que acabas con una sola clase enorme con nada m�s que m�todos est�ticos.
En principio, lo podr�as compilar luego a un ejecutable nativo y supongo
que no tendr�a porque ejecutarse a una r�pidez muy distinta del programa
en C. El problema es que no ser�a Java idiom�tico. O Java de verdad,
como quieras.

En realidad, si hablamos de pasar del C a Java, eso normalmente
significa adoptar un enfoque de POO y usar clases e interfaces y
herencia. Y en la pr�ctica, el modelo de programaci�n orientada objetos
tiende a suponer alg�n coste de velocidad. Eso dicho, un compilador con
un optimizador muy sofisticado puede reducir dram�ticamente ese coste.
Pienso en cosas como inlining y lo que se llama returned-value
optimization.

Adem�s, se tendr�a que decir que, para los m�todos cruciales de punto de
vista eficacia, se puede prescindir de la invocaci�n virtual, declarando
los m�todos cr�ticos "final" o "static". De todas formas, para la
mayor�a de c�digo que uno escribe, el coste pr�ctico del model POO es
nulo, porque el c�digo no es cr�tico de punto de vista eficacia.
Entonces, en general, para la gran parte de lo que uno hace, me parece
que el enfoque POO es el enfoque correcto.

>   Pero claro, esto no tiene naada que ver con Java y C/C++. Estos
> lenguajes deben de implementarse en maquinas reales. Aqui si podemos
> hablar de lenguajes rapidos, ya que algunos permiten que la traduccion
> de codigo nativo (asm) sea mucho mas eficiente. En este caso tanto Java
> como C/C++ son perfectamente equiparables. Los dos tienen construcciones
> similares, y el problema de la herencia ya no supone carga alguna.
> 
>   La compilacion que Java se realiza para una maquina virtual, invitando
> a considerar la ejecucion del codigo como un paso intermedio entre la
> interpretacion y ejecucion nativa. Con la llegada de los JITs esta
> interpretacion se acerca aun mas a la ejecucion nativa del codigo, pero
> sigue suponiendo una carga para el procesamiento.

En el sentido de que, al momento de cargar la clase, se tiene que hacer
la compilaci�n de bytecode a c�digo nativo. Pero en realidad, eso puede
ser tan r�pido que no supone ning�n coste importante. Y es un coste que
se impone todo por adelantado. No tiene porque afectar la velocidad de
ejecuci�n. El problema actual es un problema de implementaci�n. Bajo
Win32, por lo menos, la compilaci�n JIT no s�lo compila tu programa sino
todas las clases de las librer�as empezando por java.lang.Object y
java.lang.Thread. Y eso s� que supone un coste. Pero l�gicamente,
deber�a haber un mecanismo de cache para esas clases. Creo que en el
futuro, sacar�n sistemas operativos que son "java-aware" y guardar�n un
cache para las clases m�s usadas.

Aun y as�, hay motivos por los cuales un compilador est�tico puede
producir c�digo m�s eficaz. En general, el compilador est�tico dispone
de m�s informaci�n. Por ejemplo, incluso si un m�todo es virtual, el
compilador est�tico podr�a prescindir de la b�squeda din�mica si sabe
que s�lo hay un m�todo que se puede invocar. Es decir, es un sistema
cerrado en que todas las clases que se pueden instanciar ya se conocen
por adelantado. En contraste, un runtime Java es un sistema abierto y se
puede cargar m�s clases durante la ejecuci�n del programa. Entonces, hay
optimizaciones que no son posibles. El otro motivo es que un compilador
est�tico puede pasar m�s tiempo analizando la informaci�n que tiene. 

>   Asi que cuando se habla de lenguajes veloces, �en que nivel nos
> referimos? :????
> 
> > Java tiene una sem�ntica distinta y el conjunto de optimizaciones
> > posibles es distinto. Te�ricamente hay factores que dar�an una ventaja
> > al C pero tambi�n hay factores que dar�an una ventaja a Java.
> 
>   :)))) No son tan distintos, 


Bueno, son m�s distintos de lo que pareces darte cuenta. Hasta se puede
decir que la semajanza entre Java y C++ es m�s bien superficial. Y es
enga�osa.

> solo que las optimizaciones de Java no
> pueden llegar a tener en cuenta el procesador sobre en que se ejecutara
> (reordenamiento de instruciones, uso de registros, prediccion de
> saltos).

Un poco confuso, lo que dices. Las optimizaciones indicadas depender�an
del procesador y el bytecode representa un formato �nico para cualquier
plataforma. Entonces, l�gicamente, la etapa de optimizaci�n tiene que
ser hecho a partir del bytecode de todas formas. Y es lo que hace un
compilador JIT. O un compilador est�tico que coge bytecode de entrada y
crea un ejecutable nativo de salida.

> Tengo entendido que algunos JIT realizan esta fase de la
> optimizacion.

S�, aunque hay ciertas limitaciones, ciertas optimizaciones que no
pueden hacer porque no pueden llevar a cabo una an�lisis global del
c�digo. (Despu�s de todo, se puede cargar m�s c�digo durante la
ejecuci�n, �no?) Y tambi�n hay una restricci�n de tiempo como cuesti�n
pragm�tico. Pero, de hecho, es sorprendente ver hasta qu� punto un
compilador JIT puede optimizar. Y el campo est� aun en su infancia.
 
> > Entonces, el falso paralelismo de portabilidad frente a velocidad es lo
> > siguiente:
> >
> > Java, como lenguaje, no tiene un problema *intr�nseco* de velocidad. Es
> > todo cuesti�n de implementaci�n.
> 
>  :)) Cherto, a ese nivel LISP, Java, Smalltalk, Eiffel y todos los
> lenguajes funcionales e imperativos son igualmente veloces. Occam y
> algunos otros para multiprocesadores y los logicos..... quizas sean los
> unicos capaces de situarse a distinto nivel de velocidad.

En la realidad, quiz�s el factor dominante es cu�nto esfuerzo se pone en
crear implementaciones muy optimizadas. Java, a diferencia de los otros
lenguajes que mencionas, parece tener una movida tal que, se puede decir
que si es posible crear una implementaci�n de Java optimizado hasta el
mismo nivel que el C compilado, se har�. Simplemente hay demasiado
armamento intelectual apuntado al problema.

>   Otra cosa que me gustaria comentar es que no se puede comparar la
> protabilidad de Java con C, como lenguajes su portabilidad esta
> asegurada siempre que usemos compiladores de versiones iguales. (Lease
> lo de versiones C K&R y ANSI, y Java como 1.0, 1.1 y 1.2)
> 
>   No hay que confunvir la portabilidad de Java con la portabilidad del
> lenguaje Java. Java no es solo un lenguaje. Java esta definido como una
> plataforma. Java, como lenguaje, no es gran cosa. Es bonito que no
> incorpore herencia multiple pero si interfaces multiples. Queda feo en
> la declaracion de clases internas.... Es solo un lenguaje mas. Algunos
> pensaran que Eiffel es mejor lenguaje, otros creeran que como Smalltalk
> ninguno...., po vale :)

Tienes raz�n. Java es m�s que el lenguaje. Pero todo se dise�o junto, el
lenguaje, el bytecode, las librer�as. No es tan f�cil definir una l�nea
fina donde una cosa empieza y otro acaba. Como lenguaje, es un lenguaje
m�s, y tiene sus defectos. Pero me recuerda algo que dijo Alan Kay, me
parece. El dijo que el Macintosh era el primer ordenador lo
suficientemente bueno como para criticarlo. Es que para que sea
interesante criticar algo, tiene que llegar a un cierto nivel. Me parece
que, como lenguaje, Java es bastante bueno para que sea interesante
criticarlo. Eiffel y Smalltalk, los cuales conozco poco, sospecho que
tambi�n merecen una cr�tica. C y C++, muy francamente, no llegan a ese
nivel. Esos lenguajes son tan obviamente malos que no vale la pena
criticarlos. Bueno, el C tiene una virtud. Es muy sencillo. Es lo que
es. Muy primitivo y limitado, un denominador com�n al cual siempre se
puede recurrir cuando hace falta hacer programaci�n de bajo nivel. Lo
aprendes y es otra herramienta que tienes. Pero realmente no veo ninguna
justificaci�n para el C++, el esfuerzo intelectual que hace falta para
aprender todos sus rincones. Alguien me dijo (no cualquiera, alguien que
estaba en el comit� de normalizaci�n) que Bjarne Stroustrup dijo en
alg�n momento que consideraba que la sintaxis del C++ era un experimento
que hab�a fracasado. Supongo que quer�a decir el experimento de agregar
toda una sintaxis de POO encima de un viejo lenguaje procedural
manteniendo una casi completa compatibilidad hacia atr�s. Pero no estoy
100% seguro que lo dijo de verdad. O a lo mejor estaba borracho y lo
reconoci� en un momento de debilidad. Los escandinavos beben mucho
despu�s de todo. Pero me gustar�a encontrar la referencia.

> 
>   La plataforma Java si es un sue�o que tiene trazas de realidad, Y eso
> me encanta. Saber que puedo programar con INDEPENDENCIA del sistema
> operativo subyacente.... Java nos abre muchas puertas a los que adoramos
> la programacion distribuida. Pero nos cierra otras. Estas puertas son
> las que, precisamente, tienen que ver con las opciones que la plataforma
> Java no recoje, pero si oferta el sistema operativo. Quizas, para
> solucionar esto, la libreria de clases de Java tengan que crecer en otra
> direccion. Mi opinion es que SUN hace lo correcto al hacer crecer Java
> solo hacia la programacion distribuida, ya que acercarse a la maquina
> supondria crear una plataforma equivalente a un sistema operativo.

Est�n enfatizando los aspectos din�micos de Java, es decir, los que
tienen que ver con el ClassLoader y el SecurityManager, el hecho de
poder cargar clases y objetos indistintamente del disco local o la red
-- los applets, los servlets, servidores de aplicaciones...  Lo que pasa
es que un modelo de compilaci�n din�mica puede tener un cierto coste de
eficacia (que, como vemos, no tiene que ver con el lenguaje en s�) pero
lo que pasa es que son los aspectos din�micos de Java que lo hacen tan
especial. Y en esos dominios, Java tiende a ser suficientemente r�pido
de todas formas. As� que, bueno, estoy de acuerdo que ellos tienen raz�n
al enfatizar esos aspectos. No obstante, no est�n desanimando a nadie de
implementar Java como lenguaje compilado est�ticamente y hay empresas
entrando en ese vac�o tambi�n. Y bueno, como dije antes, no veo
especialmente porque Java compilado est�ticamente tiene porque ser m�s
lento que C++ o incluso C compilado est�ticamente. Hay expertos que
dicen que incluso tender� a ser� m�s r�pido.

El argumento de la forma "Java es lento y C es r�pido" no me impresiona
especialmente. Me parece probable que es una situaci�n m�s bien
temporal.

Saludos,

Jonathan Revusky
-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions