Hace tiempo escribí una entrada donde comparaba el rendimiento de C y C++ en un proyecto real. Hoy he migrado ese proyecto a D y he hecho los mismos tests. Estos son los resultados.
#3 Claro, porque nunca nadie, jamás, ha sufrido pérdidas de memoria en C, ni desbordamientos de buffer, ni deferrenciaciones de punteros incorrectos, ni nada por el estilo.
¿Que C es un lenguaje muy eficiente y flexible? Pues sí, pero a estas alturas ya tenía que estar enterrado.
#5 Igual lo que hay que hacer es enterrar a los que van de programadores y no saben programar
Veo cada vez ver con más horror la tendencia a usar lenguajes y frameworks poco eficientes para toda clase de proyectos. Slack mismamente es un maldito monstruo traga recursos, cuando tienes el PC con mucha carga le cuesta reaccionar, ¡y es un puto chat! Manda huevos. A este paso pronto veremos Sistemas Operativos hechos en JavaScript...
Lo malo es que se te pega, porque al final como todo el mundo lo usa acaba siendo más fácil seguir la corriente...
#7 Estás hablando con alguien que lo mismo te programa en Haskell que en VHDL, y que en su día a día elige C++ siempre que puede (y que se caga en todo lo cagable teniendo que tocar PHP )
Y sí, la mierda de Electron (que es en lo que está basado Slack) es una puta aberración, y los programadores que lo usan se merecen una temporada en un gulag
#3 En realidad no es ningún patán programando, sino que eso se hace deliberadamente.
pkg-config es un programa de consola cuyo funcionamiento es empezar, hacer, parar (vamos, como cualquier página web :P). Es decir, no es que arranque, haga cosas, siga arrancado, espere interacción del usuario… no. Simplemente hace su trabajo y para. Por lo tanto, una de las formas que tiene C (y C++) de mejorar la velocidad de velocidad de ejecución es no hacer las liberaciones de memoria, sino que estas se hacen cuando acabe el programa por parte del sistema operativo. En C se evita llamar a free() y en C++ se reimplementa el operador delete para que no haga nada.
Por ejemplo, eso es lo que hace el compilador dmd para compilar D mucho más rápido que otros compiladores (o lo que hacía cuando estaba escrito en C++, claro, que ahora ya está escrito en D y usa el recolector de basura).
#22 Tienes razón, hay programas de ese tipo en los que se pierde memoria a propósito, porque total, si la ejecución va a durar menos de un segundo, ya se encargará el kernel...
Otra cosa es que sí quieres liberar la memoria y se te olvide llamar a free, o hagas alguna burrada con un puntero, que en C no es nada infrecuente.
#20 Pues acabo de mirar en mi sistema y lo que es la máquina virtual en sí ocupa una mierda, lo que sí ocupa una barbaridad son todos los JAR con la biblioteca de clases.
Pero vuelvo a repetir, ¿qué tiene que ver Java en todo esto?
"Memory consumption is where things get interesting. D uses a garbage collector by default whereas C and C++ don't, requiring explicit deallocation either manually or with RAII instead. The difference is clear in the number of allocations done by each language. Both C and C++ have allocation counts in the thousands whereas D only does 151 of them. Even more amazingly it manages to beat the competition by using the least amount of memory of any of the tested languages."
#8 Teniendo en cuenta que el que menos gasta son 48 kB y el que más 53, tampoco creo que sea muy representativo. Que pruebe con un programa grande que tarde varios minutos en ejecutarse y entonces hablamos.
#14 Sí es muy representativo. Con Java, un programa que teóricamente está consumiendo 70MB puede estar fácilmente consumiendo 200 debido al código extra que realiza, entre otras cosas, la recolección de basura. No sé cómo funciona en D, entiendo que no es algo tan exagerado como en Java, pero podría ser algo relevante.
#c-15" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2871381/order/15">#15 Si para ti un programa diminuto es representativo...
Por otra parte lo que consume memoria extra no es el código para la recolección de basura, es la expansión del heap Pero sí, se suele decir que para que un lenguaje con GC funcione bien necesita el doble de memoria que el tamaño del working set. De todas maneras el gran problema de Java no es la recolección de basura, si no la carencia de tipos por valor. C# los tiene desde hace años, y a Java parece que no terminan de llegar.
![Comparando el rendimiento de C, C++ y D con un proyecto real [ENG]](https://cdn.mnmstatic.net/cache/2b/d0/media_thumb_2x-link-2871381.jpeg?1512669126)
Comentarios
"memory leaks" en C >1000
¡Este tío es un patán programando!
#3 Claro, porque nunca nadie, jamás, ha sufrido pérdidas de memoria en C, ni desbordamientos de buffer, ni deferrenciaciones de punteros incorrectos, ni nada por el estilo.
¿Que C es un lenguaje muy eficiente y flexible? Pues sí, pero a estas alturas ya tenía que estar enterrado.
#5 Igual lo que hay que hacer es enterrar a los que van de programadores y no saben programar
Veo cada vez ver con más horror la tendencia a usar lenguajes y frameworks poco eficientes para toda clase de proyectos. Slack mismamente es un maldito monstruo traga recursos, cuando tienes el PC con mucha carga le cuesta reaccionar, ¡y es un puto chat! Manda huevos. A este paso pronto veremos Sistemas Operativos hechos en JavaScript...
Lo malo es que se te pega, porque al final como todo el mundo lo usa acaba siendo más fácil seguir la corriente...
#7
>>>A este paso pronto veremos Sistemas Operativos hechos en JavaScript...
https://node-os.com/
https://www.os-js.org/
Y alguno más...
#7 Estás hablando con alguien que lo mismo te programa en Haskell que en VHDL, y que en su día a día elige C++ siempre que puede (y que se caga en todo lo cagable teniendo que tocar PHP
)
Y sí, la mierda de Electron (que es en lo que está basado Slack) es una puta aberración, y los programadores que lo usan se merecen una temporada en un gulag
#3 En realidad no es ningún patán programando, sino que eso se hace deliberadamente.
pkg-config es un programa de consola cuyo funcionamiento es empezar, hacer, parar (vamos, como cualquier página web :P). Es decir, no es que arranque, haga cosas, siga arrancado, espere interacción del usuario… no. Simplemente hace su trabajo y para. Por lo tanto, una de las formas que tiene C (y C++) de mejorar la velocidad de velocidad de ejecución es no hacer las liberaciones de memoria, sino que estas se hacen cuando acabe el programa por parte del sistema operativo. En C se evita llamar a free() y en C++ se reimplementa el operador delete para que no haga nada.
Por ejemplo, eso es lo que hace el compilador dmd para compilar D mucho más rápido que otros compiladores (o lo que hacía cuando estaba escrito en C++, claro, que ahora ya está escrito en D y usa el recolector de basura).
/cc #5 #7
#22 Tienes razón, hay programas de ese tipo en los que se pierde memoria a propósito, porque total, si la ejecución va a durar menos de un segundo, ya se encargará el kernel...
Otra cosa es que sí quieres liberar la memoria y se te olvide llamar a free, o hagas alguna burrada con un puntero, que en C no es nada infrecuente.
#5 ¿Enterrado y sustituido por?
#11 C++ mismamente evita muchos de los problemas de C, pero introduce otros...
Ada supongo que valdría, pero nunca llegó a calar, así que habrá que esperar a ver si despega alguno de los nuevos lenguajes como Rust...
#3 En 3388 líneas de código
Enlace directo al proyecto de GitHub: Convert pkg-config to build with Meson.
Y Rust, ¿donde quedaría?
Gana java.
Interpreto que como término medio C++ sale mejor parado.
#18 De todas maneras no sé que hacemos hablando de Java, cuando el artículo original trataba de C, C++ y D
#20 Pues acabo de mirar en mi sistema y lo que es la máquina virtual en sí ocupa una mierda, lo que sí ocupa una barbaridad son todos los JAR con la biblioteca de clases.
Pero vuelvo a repetir, ¿qué tiene que ver Java en todo esto?
"Memory consumption is where things get interesting. D uses a garbage collector by default whereas C and C++ don't, requiring explicit deallocation either manually or with RAII instead. The difference is clear in the number of allocations done by each language. Both C and C++ have allocation counts in the thousands whereas D only does 151 of them. Even more amazingly it manages to beat the competition by using the least amount of memory of any of the tested languages."
¿Y cuánta memoria usa el recolector de basura?
#8 Teniendo en cuenta que el que menos gasta son 48 kB y el que más 53, tampoco creo que sea muy representativo. Que pruebe con un programa grande que tarde varios minutos en ejecutarse y entonces hablamos.
#14 Sí es muy representativo. Con Java, un programa que teóricamente está consumiendo 70MB puede estar fácilmente consumiendo 200 debido al código extra que realiza, entre otras cosas, la recolección de basura. No sé cómo funciona en D, entiendo que no es algo tan exagerado como en Java, pero podría ser algo relevante.
#c-15" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2871381/order/15">#15 Si para ti un programa diminuto es representativo...
Por otra parte lo que consume memoria extra no es el código para la recolección de basura, es la expansión del heap Pero sí, se suele decir que para que un lenguaje con GC funcione bien necesita el doble de memoria que el tamaño del working set. De todas maneras el gran problema de Java no es la recolección de basura, si no la carencia de tipos por valor. C# los tiene desde hace años, y a Java parece que no terminan de llegar.
#16 Java también traga mucha memoria por la JVM y el JIT. De hecho desactivando el JIT (-xint) traga un puñado menos de MB, pero va lento de cojones
.
#17 ¿Qué entendemos por JVM? ¿La biblioteca de clases estándar u otra cosa?
#18 La máquina virtual que ejecuta el bytecode.