🚀 go-pugleaf

Alvaro Fuentes wrote:

> Los defensores de C++ ya s�lo pueden acogerse a la mayor rapidez de C++ en
> ejecuci�n, algo en lo que Java no puede competir.

Bueno, es cierto que ahora mismo, C++ tiende a ser m�s r�pido que Java,
pero, en el fondo, eso no es sorprendente. Est�s comparando algo que
lleva muchos a�os en el mercado y muchos esfuerzos se han hecho para que
C++ corra r�pido. A�os de ingenier�a. 

Mira, si, hace un siglo, al ver el primer prototipo de un autom�vil,
cuando los proponentes de esa tecnolog�a dec�an que �sta iba a remplazar
el transporte a base de caballo, muchos pensaban seguramente que eran
locos, porque los primeros prototipos eran muy lentos y muy poco
fiables. Adem�s, esa impresi�n fue acuentuada por el hecho de que las
carreteras del tiempo no fueron dise�ados con los automoviles en mente.
Razonar que ese autom�vil era m�s lento que un hombre montado a caballo,
y por lo tanto, los autom�viles son *intr�nsecamente m�s lentos* que un
caballo es un gran salto de razonamiento. Sabemos ahora que ocurre
exactamente lo contrario. Lo que quiero decir es que criticar el
*potencial* de una nueva tecnolog�a a base de los problemas con los
primeros prototipos que salen es casi siempre un error.

Notar�s que mucha gente dice que C++ debe ser m�s r�pido que Java pero
nunca te explican realmente bien porque. �Incluso ofrecen motivos que, a
mi juicio, tienden a favorecer el Java a largo plazo!

T�picamente, se ofrece los motivos siguientes:

(1) C y C++ van a ser m�s r�pidos porque le ofrecen al programador la
posibilidad de manipular punteros directamente sin restricciones.

(2) Java tiende a ser m�s lento porque tiene un sistema de recolecci�n
de basura. Eso tiene un gran coste en eficacia comparado con la gesti�n
manual de memoria.

Las dos afirmaciones *pueden* ser ciertas (puntualmente) pero se tienen
que matizar much�simo. En el caso de afirmaci�n (2) me parece que se
tiene que matizarla tanto que probablemente as� como as�, yo dir�a que
la afirmaci�n es totalmente falsa. Bueno, la afirmaci�n (1) es casi
totalmente falsa tambi�n.

Lo que pasa con (1) es que es cierto que, puntualmente, hay truquillos
que puedes hacer con aritm�tica de punteros para conseguir m�s rapidez
en C o C++. Las matices son que: (a) Ese tipo de cosa es peligrosa y muy
propensa al error. (b) El c�digo resultante tiende a ser muy poco
mantenible. (c) Es muy posible que el "truquillo" tenga el efecto
contrario -- que incluso ralentiza el c�digo en cuesti�n.

O, y por supuesto (d) incluso cuando funciona, con ese tipo de truco
sueles ganar muy poco y en realidad, no vale la vela.

Con aritm�tica de punteros, t�, el programador, puedes optimizar m�s a
la mano, pero paradojicamente, la m�quina, quiero decir el generador de
c�digo, tiene las manos atadas. En el t�pico programa C o C++, el
compilador no puede mover los datos o reordenar un conjunto de objetos
en memoria porque hay "punteros sueltos por ahi" que incluso apuntan a
direcciones dentro de las propias estructuras. Mover y/o reordenar los
objetos siempre puede tener efectos secundarios. Uno o m�s punteros
podr�an quedar apuntando al vac�o.

Todo ese problema nefasto que en C se llama el problema de "pointer
aliasing" no existe en java. No puedes tener un puntero que indica una
ubicaci�n dentro del espacio de memoria de otro objeto.

Es decir que C o C++ deja m�s grados de libertad al programador para
optimizar a mano, mientras el Java deja m�s margen al sistema, al
generador de c�digo, para optimizar el c�digo que genera. Lo consigue
imponiendo cieras restricciones a lo que el programador puede hacer.

Demos un paso atr�s. Si se trata de apostar a largo plazo, �para qu�
sistema vas a apostar -- en cuanto a generar c�digo eficaz? �El sistema
que requiere que un experto humano optimice a la mano, o el sistema
basado en la �dea de optimizaci�n automatizada?

Bueno, y si adjuntas el hecho de que las optimizaciones que el humano
lleva a cabo en C s�lo se aplican a un procesador determinado. Algo que
resulta una optimizaci�n en la arquitectura x86 puede no serlo con otro
procesador. Y considera que las optimizaciones que un generador de
c�digo de Java puede llevar a cabo desde el bytecode neutro son
optimizaciones espec�ficas para la plataforma en cuesti�n....

Todo el argumento de que Java tiene una desventaja comparada con C++ en
cuanto a eficacia -- y quiero decir una deventaja intr�nseca -- es muy
muy dudoso.

Y en cuanto a la afirmaci�n (2) arriba sobre la recogida de basura,
estamos hablando con C++ de un sistema que te obliga a liberar memoria
"sobre la marcha". En Java, el sistema puede dejar que la basura se
acumule y con el esquema del "generational garbage collector" puede
liberarlo todo de golpe y adem�s puede hacer esas gestiones en un
momento de baja cuando la m�quina no tiene nada mejor que hacer. Pero,
bueno, en general, la idea de que la gesti�n manual de memoria por parte
del programador tender� a ser m�s eficaz que un sistema automatizado es
muy dudosa si lo piensas. Toda la situaci�n es sacar conclusiones
generales a partir de una situaci�n muy espec�fica. Es decir, las
implementaciones actuales de Java son lentas, entonces, Java *es* lento.

Bueno, hay bastantes motivos para creer que, en su proceso de maduraci�n
como tecnolog�a, Java incluso va a superar en la mayor�a de casos la
eficacia de C y C++.

En todo caso, una comparaci�n de Java con C++ no es especialmente
interesante. Java tiene sus defectos, pero es un lenguaje moderno. Si
enumeras las prestaciones que deber�amos querer en un lenguaje moderno a
estas alturas, yo creo que C++ re�ne tan pocas que... bueno, �qu� decir?
En cierto sentido, siento inc�modo que los defensores de Java quieran
concentrarse tanto en comparar Java con C++, ya que el resultado de la
comparaci�n es devastador. Demasiado f�cil, �no? Tengo la impresi�n de
que hay muchas m�s comparaciones interesantes que hacer con lenguajes
como Eiffel o Smalltalk. 

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