Login Barrapunto
Java versus C++, n-ésimo asalto
pobrecito hablador nos cuenta: «Para aquellos que aún no estén convencidos de que Java puede ser más rápido que C, incluso en operaciones matemáticas, hay un
estudio que discute el mito de que Java es lento. El estudio estaba originalmente referenciado en
OSNews».
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

Bienvenido a Mundo Bizarro, donde java es + Rapido
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Miércoles, 07 Julio de 2010, 13:48h )
Por tanto, todos debemos esperar que Java no solo sea lento, sino mucho mas lento que C o C++.
Ahora bien, tambien debemos aceptar que hay distintos algoritmos, y que estar en alto nivel puede permitir ver mejor el conjunto y saber dar una mejor solucion al problema. Asi que Java podria permitir escribir algoritmos ligeramente mejores que los de C++ en algun caso.
Java permite escribir mejor codigo, lo que esta muy bien, y deberia dejarle la especialidad de velocidad a C, que esta para lo que esta.
No me convencen
(Puntos:1)( http://www.intelligenia.com/ )
En cualquier caso lo que he observado es que se ha programado al estilo Java al desarrollar los programas para las pruebas.
Por ejemplo la STL en muchas ocasiones es extremadamente lenta... y también se nota la optimización de ciertas compilaciones que a veces no hacen en las pruebas.
Utilizan algoritmos que si se programasen de otros modos en C++ darían muchos mejores resultados, utilizan en ocasiones funciones especialmente lentas en C++ a pesar de que existen otras alternativas más rápidas.
Tal vez la librería de clases de java sea mejor que la de C++, esté más optimizada... pero estoy convencido de que los programas que se usan en lso ejemplos se podrían hacer de otro modo en C++ y conseguir así más velocidad que con java.
No he podido mirar detenidamente el artículo, y creo que no incluye enlaces a los programas utilizados, pero en general todos los que he visto antes cumplian más o menos lo que he dicho...
intelligenia::Ingenieria Inteligente [intelligenia.com]
Python tan rapido como C++
(Puntos:2)( Última bitácora: Miércoles, 09 Junio de 2004, 02:32h )
http://psyco.sourceforge.net/introduction.html
P.D: No me como ese cuento que Java es mas rapido que C++ primero porque Java es codigo interpretado mientras que C++ es codigo binario nativo, la unica forma de que Java sea tan rapido como C++ tendria que ser codigo binario y Java no lo es.
Java nativo
(Puntos:1)( http://choutos.blogaliza.org/ )
Em galego temos o Gildot [gildot.org]
XD cuentame otra
(Puntos:1)Reitero lo de siempre
(Puntos:2)( http://barrapunto.com/ )
Pa que? Pa cagala?
Claro, claro
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Domingo, 14 Febrero de 2010, 23:49h )
Si comparamos Java en un Pentium IV y un programa C/C++ o ensamblador en un Spectrum, una tostadora, etc...
Me meo con las comparativas esas de ¡Programadores! ¡Están Ustedes equivocados, Java es rápido! ¡El problema son sus put.. algoritmos no optimizados!
Mañana : Basic es más eficiente que C
FreeBatasuna [blogspot.com].
Es un caso muy extremo
(Puntos:5, Divertido)( http://www.halftimerockband.net/ )
La belleza está en el interior (Jack el Destripador)
Pros y contras
(Puntos:2, Inspirado)Ventajas de Java:
Es un lenguaje elegante.
Es fácil de aprender.
Tiene muchas librerías para muchas aplicaciones.
Los errores de escritura fuera de límite causan una excepción que te dice dónde está el fallo, que ayuda en la depuración.
El ejecutable funciona en varias arquitecturas diferentes.
Tiene comprobaciones de seguridad estrictas y se puede controlar a qué recursos acceden los componentes.
Al tener gestión de memoria automática es más difícil (aunque no imposible) cometer errores de pérdida de memoria por olvido de liberación de los bloques no usados.
Inconvenientes de Java:
Necesita una máquina virtual. Se puede distribuir de forma que lleve incluída la máquina virtual y el bytecode en un sólo ejecutable, pero ello lo hace dependiente de la plataforma.
La máquina virtual tarda mucho en arrancar. Esto en un servidor web no importa, porque ya está arrancada, pero en una aplicación de escritorio sí, (a menos que el escritorio esté escrito en Java)
Utiliza cantidades ingentes de memoria.
Algunas aplicaciones necesitan un control preciso de la gestión de memoria, esto no es posible en Java. La recolección de basura automática no se puede controlar, el comportamiento depende de la aplicación.
Para aplicaciones de cálculo intensivas es ineficiente. Aunque parte del bytecode sea recompilado a código nativo las llamadas entre métodos siguen un protocolo muy gravoso, también influyen considerablemente las salvaguardas de límites. Por poner un ejemplo: hacer un ray-tracing render en Java no es una buena idea.
No se puede usar para acceder a los recursos a bajo nivel. Por motivos de seguridad y por estar mediatizado por la máquina virtual no puede acceder a posiciones de memoria física concreta o a registros del hardware, lo que lo hace inadecuado para muchas aplicaciones de sistema.
Por su elevada latencia en los cambios de contexto, no es apto para usarlo en aplicaciones de tiempo real duro. Esto, tal vez, pudiera subsanarse con una implementacióin especial de la máquina virtual. Ignoro si existe.
Inconvenientes de C++.
Es difícil, por su extrema libertad, heredadada de C. Es necesaria una gran disciplina para no cometer errores que son difíciles de depurar.
Carece de salvaguardas en tiempo de ejecución. Con lo que una escritura fuera de límites puede originar comportamientos insospechados.
La gestión de memoria la debe de planificar el programador, y los errores en ese tema suelen ser graves.
Ventajas de C++.
Todas las de C, bajo nivel, eficiencia, interacción fácil con ensamblador y otros lenguajes.
Todas las de un lenguaje avanzado orientado a objeto: herencia múltiple, patrones, sobrecarga de operadores ...
Gestión precisa de la memoria.
Libertad, mucha libertad.
el color del cristal.
(Puntos:1, Interesante)Hace tiempo que al menos en implementaciones como la hotspot de Sun, se empezó a hablar de compiladores adaptativos para mejorar el rendimiento de java, para diferenciarlos de los llamados JIT,teniendo en cuenta que éstos presentaban serios problemas para competir en rendimiento con compiladores nativos de C/C++:
-Las comprobaciones que realiza java en tiempo de ejecución(dinamically safe).
-Java coloca todos los objetos en el heap, al contrario que C++ que puede ubicarlos en la pila.
-La mayoría de las invocaciones a métodos java son virtuales, lo que hace más difícil optimizar estáticamente, sobre todo optimizaciones globales como inlining.
En general el caracter dinámico de java, y la posibilidad de cargar dinámicamente clases en tiempo de ejecución choca bastante con las posibilidades de optimización con la compilación estática tradicional.. por lo que los esfuerzos para mejorar el rendimiento de java se han ido centrando en otros aspectos, como la capacidad para adaptar las optimizaciones realizadas a cuellos de botella localizados dependientes de variables no conocidas en tiempo de compilación pero sí de ejecución, e inyectar el código nativo a ejecutarse en función de la evolución del programa. De esa forma, pese a que la compilación estática, y las características intrínsecas de la plataforma hagan el código más lento que el similar generado desde otros lenguajes, java puede aprovechar su adaptatividad para hacer que la optimización se guíe teniendo en cuenta que el perfilador interno ha determinado que en un determinado método el bucle externo se está llamando 5 veces y el interno 10000, por un determinado flujo de entrada, no determinable en tiempo de compilación.
Está característica da muy buenos resultados en servidores atendiendo continuamente peticiones, donde la adaptación suele ofrecer unos beneficios mayores que los retardos impuestos para llevarla a cabo. Para las aplicaciones cliente, sobre todo los entornos gráficos en los que la principal medida de velocidad que tiene en cuenta el usuario es el tiempo de respuesta, al arrancar la aplicación, y al pulsar un botón.. sigo sin tener muy claro porque java en su máquina virtual hotspot client no implementa una cache de código precompilado, una vez ejecutado en una determinada plataforma, o al menos dar opción a ello.. El problema de los "microbenchmarks" es que creo que a la mayoría de la gente le resultan más útiles para comparar CPUs, que compiladores, teniendo en cuenta que la velocidad de aplicaciones habituales suele depender mucho más de otros factores que los puramente de cálculo.
¿C++?
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Viernes, 17 Noviembre de 2006, 23:39h )
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!
Pero piltrafilla!
(Puntos:2)( http://barrapunto.com/ )
Pa que? Pa cagala?
Humor para quitar hierro al asunto
(Puntos:1)( http://barrapunto.com/~jakare/bitacora | Última bitácora: Lunes, 28 Junio de 2004, 05:17h )
Su mujer le recibe con un beso y le pregunta:
- Como ha ido hoy el día, cariño?
- Bueno, cuando he llegado al circuito, he ido a boxes y el F1 no estaba en su sitio. En su lugar había un burro.
- Como? - se sorprende la mujer.
- Si, así es. Le he preguntado al jefe de equipo y me ha confirmado que habían cambiado el monoplaza por el burro.
- Y tu que le has contestado?
- Pues yo le he dicho que quizás no seria tan rápido como el F1, el ha dicho que ciertamente es así, pero que ahora tenemos una ventaja y es que podremos correr en todo tipo de circuito: F1, rally, motocross, trail sin... Y bueno, al menos hoy he podido venir montado en el hasta casa, cosa que no podía hacer con el F1.
- Ya, pero si tu solo corres en F1, para que quieres poder correr en otros circuitos?
- Pues no lo se. Además, después de montarme en el burro le he dicho al jefe de equipo que no era ni la mitad de cómodo que el monoplaza.
- Que ha respondido el?
- Simplemente ha dicho que eso no importa porque ahora podemos correr en todo tipo de circuito.
- Ay Señor! Y no corres mas riesgo de hacerte daño si caes?
- En realidad no, porque le han puesto al burro las mismas protecciones que tiene la cabina del F1. A pesar de que hace que todavía vaya un poco mas lento. Según el jefe eso ya no tiene tanta importancia, porque ahora podemos correr en todo tipo de circuito.
- Esta bien, enséñame el burro.
Tras salir al jardín y quedarse estupefacta con la imagen de un burro pintado de rojo, con el escudo de Ferrari pegado en la frente y una protección de F1 encima de la silla de montar, la mujer le pregunta a Michael:
- Y como se llama el animal?
- Se llama Java
Y ahora mi opinion:
Yo he trabajado varios años con java, y muy poquito con C, pero haciendo pruebas y tal C es mas rapido pero.. con las supermaquinas actuales... ¿que importa eso?? ;)
--------
JJ. [barrapunto.com]
La lentitud
(Puntos:1)( http://flickr.com/photos/teleyinex | Última bitácora: Lunes, 02 Marzo de 2009, 22:16h )
He estado usando el g2-gui para el mldonkey. Este programa está hecho en java y usa la JVM. Cuando lo arranco mi micro se vuelve loco, consume la ostia de procesador. Como esto no podía ser busqué otra opción y encontré Sancho.
Sancho está hecho en Java, pero compilado a binario y no consume nada de procesador. Es increíble como mejora el rendimiento de una aplicación compilandola a binario.
El micro es un p3 a 800 MHz y 256 de RAM.
Por otro lado mi escritorio GNOME corre más rápido siempre que cualquier aplicación java sin compilar a binario.
Taluek!
"Podréis meter mi cuerpo en una cárcel, pero mi mente siempre libre siempre arde porque es inarrestable"
"Premature optimization ...
(Puntos:2)( http://www.jmcresearch.com/ )
Para los detractores de C++, diré que el "problema de rendimiento" es mas bien un problema de conocimiento. C++ es complejo y además Object Oriented. Ser OO hace que para programar en C++, sea necesario saber "alguna cosa mas" que class, public y tal. algunas de las features avanzadas de C++ llevan al compilador al límite de sus posibilidades: por ejemplo, los templates. Asi que si tienes un compilador malo, utilizas mal la STL, y no tienes muy claro como funcionan algunas cosas básicas, normal que te salgan programas lentos.
La flexibilidad y la potencia de C++ es un arma de doble filo; lo que está claro es que si aprendes los usos (y abusos) puedes sacarle muchísimo partido.
Rompiendo una lanza a favor de los lenguajes interpretados, diré que si Java tuviese una máquina virtual optimizada de verdad
(mas o menos lo que le sucede a python) y respetando algunas normas impuestas implicitamente por el lenguaje, se pueden desarrollar verdaderos F1's ;)
<your quote here> --Bjarne Stroustrup
Pruebas
(Puntos:2)class Velocidad
{
public static void main(String argv[])
{
int iCont1, iCont2, iCont3, iCont4;
float fValorX, fValorY, fValorZ=(float)0;
for (iCont1=15; iCont1 menor 400; iCont1++)
{
fValorX = (float) (iCont1 / 12.4);
for (iCont2=10; iCont2 menor iCont1; iCont2++)
{
fValorY = (float) (fValorX * 2.178 + iCont2);
for (iCont3=10; iCont3 menor iCont2+iCont1; iCont3++)
{
fValorY = (float) fValorY / (iCont3-iCont1);
for (iCont4=3; iCont4 menor iCont1; iCont4++)
{
fValorZ += (float) fValorX-fValorY;
}}}}}}
El siguiente es código en C++:
void main()
{
int iCont1, iCont2, iCont3, iCont4;
float fValorX, fValorY, fValorZ=(float)0;
for (iCont1=15; iCont1 menor 400; iCont1++)
{
fValorX = (float) (iCont1 / 12.4);
for (iCont2=10; iCont2 menor iCont1; iCont2++)
{
fValorY = (float) (fValorX * 2.178 + iCont2);
for (iCont3=10; iCont3 menor iCont2+iCont1; iCont3++)
{
fValorY = (float) fValorY / (iCont3-iCont1);
for (iCont4=3; iCont4 menor iCont1; iCont4++)
{
fValorZ += (float) fValorX-fValorY;
}}}}}}
Estamos hablando exclusivamente de la velocidad. El primer programa ejecutado con JDK 1.4.2_01 tardó en completarse: 1 minuto 14 segundos
El segundo programa compilado con Visual C++ 6.0 tardó en completarse: 26 segundos
En el mismo equipo.
Disculpen que se pierda la identación en los programas pero no se como colocar código fuente en los comentarios de barrapunto. Además el símbolo "menor que" no aparece y por eso tuve que colocarlo en letras.