Historias
Slashboxes
Comentarios

Login Barrapunto

Login

[ Crear nueva cuenta ]

Java versus C++, n-ésimo asalto

editada por rvr el 08 de Julio 2004, 15:24h   Printer-friendly   Email story
desde el dept. próximamente-java-vs-php
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.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • por Tei (4535) el Jueves, 08 Julio de 2004, 15:54h (#324072)
    ( http://barrapunto.com/ | Última bitácora: Miércoles, 07 Julio de 2010, 13:48h )
    Java es un lenguaje que no se compila en lenguaje maquina nativo, sino en un codigo maquina intermedio que luego hay que interpretarlo. Ademas es un lenguaje de muy alto nivel, con lo que un poco de codigo puede equivaler a muchisimo codigo maquina intermedia. Mientras que con C o C++ cuando miras en el debugger cuanto codigo genera cada linea en C, aparece unos pocos nemotecnicos por linea, aveces en una relacion 1:1 (Que seria la optima).

    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)
    por other (14473) el Jueves, 08 Julio de 2004, 16:05h (#324081)
    ( http://www.intelligenia.com/ )
    He visto varios artículso del estilo... lamayor parte de ellos antes o después estaban animados por sun.
    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...
  • por Xiriaco (5510) el Jueves, 08 Julio de 2004, 16:28h (#324098)
    ( Última bitácora: Miércoles, 09 Junio de 2004, 02:32h )
    Bueno Java no es el unico que puede ser tan rapido como C++. Existe un programa (su nombre es Psyco) que optimiza el codigo de Python para hacerlo tan rapido como C++ pueden saber mas de ello en esta pagina:

    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)
    por choutos (12486) el Jueves, 08 Julio de 2004, 17:21h (#324130)
    ( http://choutos.blogaliza.org/ )
    Compilando código Java [escomposlinux.org]
    --


    Em galego temos o Gildot [gildot.org]
  • XD cuentame otra

    (Puntos:1)
    por deepbit (14782) el Jueves, 08 Julio de 2004, 17:21h (#324131)
    hace tiempo ya que discuti estos temas con mis profesores de arquitectura de computadores... Cuando les pregunte su opinion sobre java me dijeron litaralmente que era una pu.. mie... Quizas eran un poco radicales aunque no dejaron muy bien a ningun lenguaje de programacion orientado a objetos, me dijeron que meten mucha mierda en el código. A lo que vamos, uno de los problemas mas grandes de un lenguaje interpretado como java es que la memoria cache es como si no existiera... los datos leidos por la lectura anticipada de la cache no se pueden ejecutar inmediatamente, siempre tienes que realizar traducciones de lo leido asi que todo ese maravilloso tiempo que nos ahorra la caché en un programa compilado, chufff!!!! se va a tomar x culo...... Así que no me creo que el Java le meta caña al c++, no es logico. Si quereis que algo vaya "muy" rapido es mejor programarlo en un lenguaje como C, ASM no lo recomiendo ya que no es portable pero bueno. c++ no es tan malo en verdad es bueno pero pensad que el manejo de los objetos y todo este tema de la POO conlleva un ejecutable de un peso considerable y si no probad a compilar un hola mundo el c y en otro en c++ y mirad la diferencia del tamaño ;D nos vemos! ;D deepbit
  • por samsaga2 (5886) el Jueves, 08 Julio de 2004, 17:24h (#324134)
    ( http://barrapunto.com/ )
    Java en si es rapido, lo que es lento son esas pedazos de GUI, ademas del problema de que consume demasiada memoria. Y que la gente se entere de una vez Java NO ES INTERPRETADO es compilado en tiempo de ejecucion, y ademas, se compila optimizado para tu CPU no como el C que se compila para que funcione en todas las CPU.
    --
    Pa que? Pa cagala?
  • Claro, claro

    (Puntos:1)
    por joxeanpiti (13551) el Jueves, 08 Julio de 2004, 18:36h (#324151)
    ( http://barrapunto.com/ | Última bitácora: Domingo, 14 Febrero de 2010, 23:49h )
    Java es mucho más rápido que C++, y que C y casi que ensamblador.

    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].
    • Eficiencia de jjga (Puntos:2) Jueves, 08 Julio de 2004, 23:18h
    • Es un caso muy extremo

      (Puntos:5, Divertido)
      por Penetrator (5932) el Jueves, 08 Julio de 2004, 20:41h (#324183)
      ( http://www.halftimerockband.net/ )
      Todo eso está muy bien, pero hay que tener en cuenta que eso es un caso extremo, de un programa que no hace nada útil. Java es más rápido que C cuando se trata de hacer... nada. ¡Bravo! ¡Qué gran invento esto del JIT, oye! Antes tardaba 10 veces más que ahora en hacer nada. Ahora sigo sin hacer nada, pero eso sí, 10 veces más rápido. Ningún programador con medio cerebro escribiría un programa así, a no ser que su único propósito sea afirmar que Java es más rápido que C. Yo también puedo decir que mi Renault 5 del 88 es más rápido que un Boeing 747... en caída libre. Las alas del Boeing 747 hacen que caiga más despacio, mientras que el R5 cae a plomo. Si llevamos las cosas a los extremos que nos interesan, cualquier estupidez es demostrable. Además, si el JIT se dedica a ir optimizando código sobre la marcha, eso consume ciclos de CPU. Lo cual significa que lo que gana por un lado lo pierde por el otro, y estamos en las mismas. Un mismo algoritmo, implementado de igual forma en C y en Java (en igualdad de condiciones), estoy convencido de que se ejecuta más rápido en C que en Java. -
      --
      La belleza está en el interior (Jack el Destripador)
      [ Padre ]
    • Re:Claro, claro de saboteur (Puntos:1) Jueves, 08 Julio de 2004, 21:32h
    • Re:Hostia que listo eres eh! de mr_mejor (Puntos:2) Viernes, 09 Julio de 2004, 10:09h
    • Re:Claro, claro de deepbit (Puntos:1) Lunes, 12 Julio de 2004, 10:06h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • Pros y contras

    (Puntos:2, Inspirado)
    por pobrecito hablador el Jueves, 08 Julio de 2004, 21:15h (#324186)
    Sin pararme mucho a pensar.

    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.

    • ¿Elegante? de JotaRP (Puntos:2) Viernes, 09 Julio de 2004, 07:23h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • el color del cristal.

    (Puntos:1, Interesante)
    por pobrecito hablador el Jueves, 08 Julio de 2004, 21:22h (#324188)
    Supongo que la mayoría de personas que han comentado lo lento que es java, estarán de acuerdo en la lentitud de un F18 si tienes que sacarlo del garaje para ir a comprar el pan a la panadería de la esquina. Probablemente dependiendo de para que vayas a usar java, el retardo inicial para cargar la máquina virtual, o el bajo tiempo de respuesta de un SWING algo pesado no de una sensación muy fluida al usuario habitual. Sobre el tema del JIT que se comentaba también(Denominando de esta forma a compiladores encargados de traducir a código nativo los bytecodes de cada método la primera vez que se invocan):
    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)
    [OT]: Me gustaría saber porqué hay tantos programadores en el mundo Unix/Linux que odian C++. No es que sea perfecto, pero para mí C es aún peor.
    --

    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

  • Pero piltrafilla!

    (Puntos:2)
    por samsaga2 (5886) el Viernes, 09 Julio de 2004, 06:07h (#324255)
    ( http://barrapunto.com/ )
    Pero de verdad tanto importa la velocidad de ejecucion de Java? Al final este lenguaje esta enfocado a servidores (J2EE) y a aplicaciones de gestion. El objetivo del lenguaje es ser facil y seguro cosa que consigue con creces. Si a la gente le preocupara tanto la velocidad seguiria programando en C (y no en C++ que es mas lento que el C). C es el lenguaje mas rapido (solo por debajo del ensamblador), el segundo mas rapido que conozco es OCaml y el tercero mas rapido es el C++.
    --
    Pa que? Pa cagala?
  • Michael Schumacher llega a casa después de un duro día de entrenos en el circuito.
    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)
    por Teleyinex (7668) el Viernes, 09 Julio de 2004, 07:41h (#324286)
    ( http://flickr.com/photos/teleyinex | Última bitácora: Lunes, 02 Marzo de 2009, 22:16h )
    Yo como comentario añado lo siguiente:
    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"
  • ... is the root of all evil" -- D. Knuth. El problema de estas flame wars Java vs C++ es que siempre se acaba en los cerros de úbeda. El problema no estriba en los lenguajes, sino en los compiladores. Con compiladores y optimizadores lo suficientemente buenos, C++ y Java podrian ser equiparables. Otra cosa es que con las plataformas de desarrollo a disposición de la mayoría, Java salga perdiendo por goleada.

    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)
    por Rafael (12568) el Sábado, 10 Julio de 2004, 05:40h (#324540)
    El siguiente código es en Java:

    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.

  • 7 respuestas por debajo de tu umbral de lectura actual.