Portada
mis comunidades
otras secciones
#1:
No cuela. Nadie se cree que Java sea más eficiente ni que una locomotora quemando aceite de ballena.
#8:
Un amigo informático me dijo que los programadores de verdad solo necesitan tres teclas: "0","1" e "Intro". Todo lo demás son cosas de flojeras.
#2:
Lenguage C, "Hello world", 256k
Java, "Hello world", 56MB
Java, "Hello world", 56MB
Comentarios
No cuela. Nadie se cree que Java sea más eficiente ni que una locomotora quemando aceite de ballena.
#1 es que hay mucha gente juzgando a Java sin conocer realmente cómo funciona su máquina virtual.
Luego te encuentras que las empresas acaban gastando dinerales en migrar sus sistemas a Java o .Net porque el jakercilli de turno leyó en Menéame que Django o Rails eran las opciones más eficientes
#26 Mira, ni con GraalVM se le acerca a C o C++.
Avisame cuando JPCSP se le acerque siquiera a PPSSPP.
He probado JPCSP bajo OpenJDK pelado y con GraalVM (los ultimos OpenJDK tienen un switch para ello) y no con los juegos mas simples es capaz de ser igualmente comparable C++.
Y de hecho estas obsoleto. Hoy Golang puede hacer mucho de lo que hacia Java con un rendimiento bastante superior. Rails? Ya sabemos que Ruby es horrorosamente lento, incluso Perl con Mojolicious es mucho mas rapido.
Pero amigo, compara Java contra Go. Si quieres usar la peor mierda en rendimiento que haya inventado Sun, adelante. Y lo gracioso es que en los 90 existian cosas como Inferno pero literalmente hasta 200 veces mas rapidas que la JWM. Y con menus, ventanas y toda la pesca iguales en cualquier SO.
https://en.wikipedia.org/wiki/Inferno_(operating_system)
#37 he trabajado 4 años para un "hyperscaler" (de esos que requieren miles de instancias para correr sus servicios) y en su momento se decidió dejar de usar Go para los nuevos microservicios, en favor de Java.
Pues en unos pocos servicios críticos que se tuvieron que migrar de Go a Java, ganamos alrededor de un 15% de mejora en el rendimiento (medido como tiempo por transacción y como transacciones/segundo).
Por muy compilado que sea Go, al final el ejecutable tiene que arrastrar su propio runtime y hacer verificaciones en tiempo de ejecución, con la desventaja de no tener un optimizador en tiempo de ejecución, como el compilador JIT de Java. También la gestión de memoria de Go está un par de generaciones por detrás de la JVM.
Y por todos es sabido que GraalVM no es más rápido que la compilación JIT. Su única ventaja ahora mismo es que arranca más rápidamente y no necesita "warmup" para optimizarse
#40 Sobre la memoria, te puedo dar la razon, pero ten en cuenta que el ultimo Go esta muy optimizado para eso, los binarios ocupan bastante menos en disco y se nota que el uso de memoria es bastante menor.
Probado con el cliente Gemini Amfora en un armv7l con 512mb de RAM, se nota desde versiones antiguas a las nuevas (pude compilar amfora para ARM cruzadamente claro esta).
#41 https://discord.com/blog/why-discord-is-switching-from-go-to-rust
#64 El ultimo Go ha cambiado bastante, son viejas noticias respecto al de 2020.
#40 Pero para cosas serias:
https://concertio.com/blog/optimizing-the-go-garbage-collector-and-concurrency/
#43 ese enlace muestra como optimizar el rendimiento del GC de Go. En ningún momento demuestra que sea más eficiente que el de la JVM
#44 Lo que quiero decir es que muchas veces se necesita tunear la GC a mano. Y si en Java no pasa, el que diga eso miente, puesto que hasta para escritorio muchas veces son necesarios ajustes para que el software se desempenye de forma fluida.
#45 Claro que en Java pasa. No creo que jamás se haya dicho lo contrario en este hilo de mensajes.
#37 Avisame cuando JPCSP se le acerque siquiera a PPSSPP.
#37 Uff en la asignatura de sistemas operativos tuve que programar en limbo, la experiencia hizo honor al nombre del sistema operativo.
#60 Pues de Limbo a Go no hay mucho cambio.
#26 #28 #32 Java es un puto desastre.
Paper mostrando que las maquinas virtuales basadas en registros son mas eficientes que las basadas en pila.
https://arxiv.org/pdf/1611.00467.pdf
Si en vez de Java las empresas hubieran escogido Interno ahora tendriamos maravillas hasta en una ESP32.
Y por supuesto los moviles con Android irian muy follados ya que Plan9/Inferno y Golang son primos hermanos en disenyo, asi que la interfaz seria mucho mas fluida, no habria tantos petes en Android cuando la E/S es elevada (escribir a la NAND se hace eterno y no digamos esperar E/S en un proceso, te puedes morir para forzar el terminar una aplicacion por un proceso "zombie").
#39 me pones un paper académico en el que no siquiera se comparan los resultados con una JVM...
#26 Yo tengo una idea de cómo van los bytecodes, y llevo 10 años desinstalando de todos los sitios donde lo encuentro como parte de mi trabajo.
#46 deduzco que te refieres a Java de escritorio, cuya distribución de Oracle roza el malware.
Tan ignorantes y atrevidos fueron los que en su día decían que Java era una bala de plata que servía para todo y debía estar en todas partes, como los que hoy creen que es una especie de plaga que se debe evitar en todos los ámbitos.
#1 En verdad los .class de Java junto con la JVM hacen verdaderas virguerías para mejorar el rendimiento. No va a ser lo mismo que picarte algo a bajo nivel, evidentemente, pero en general es más duro de programar que de ejecutar.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3565912/order/1">#1 Hombre pero piensa que se está comparando con Ruby. Ruby no es precisamente ligero.
Subo aquí la tabla completa a la que se referencia
Java funciona bastante bien en backends, yo diría que el problema viene cuando se hacen aplicaciones gráficas para usuario en Java, que al ser un lenguaje diseñado para ser portable tiene muchas capas de abstracción que no son fáciles de optimizar para Windows, donde a lo mejor lenguajes de Microsoft como Visual Basic o C# están mejor integrados.
Lenguage C, "Hello world", 256k
Java, "Hello world", 56MB
#2 Hacen falta 256k?
#2 256k? Eso en C++ y me paso.
En C, Linux 64 bits, -O2 y con los simbolos eliminados:
vlinux$ ls -lah hello
rwxrxr-x 1 void void 15K oct 6 12:55 hello#17 Y porque el hello world mete toda la librería de io para imprimir una solo frase. Si no ocuparía bytes,
#20 Yo creo que el compilador quita la morralla que no se use en la fase de optimización cuando está compilado estáticamente. Puede que lo que haya sea mucho código "boilerplate" metido para cargar librerías dinámicas si la libreria standard se carga dinámicamente.
También usando -Oz creo recordar que optimiza en espacio.
#50 #20 Oops, era -Os no -Oz
#2 256k.... joder poco scene has visto o participado
con 256k se pueden hacer maravillas
#2 Si al "hello world" de java le estás sumando lo que ocupa su máquina virtual, ¿al de C no habría que sumarle lo que ocupa el sistema operativo? Porque también es un requisito imprescindible.
#23 Solo libc.
Java es la jwm + libc.
#36 No, no llega sólo con la libc para que un programa en C compilado en mi ordenador funcione en el tuyo, necesariamente. Hay muchas más dependencias, por lo que esa comparación de tamaño, aunque ya sé que es de coña y tal, no tiene mucha base.
#53 Bueno, pues comparalo con Go donde todas las compilaciones son estaticas y los binarios se pueden generar desde cualquier plataforma a otra.
#36 Mas el Sistema Operativo.
#57
Y la CPU traduciendo instrucciones por debajo
Se sobreentiende.
#23 ¿Java funciona sin operativo?
#62 No, yo no he dicho eso. Pero cuando lo sumes a ambos, los 56mb de diferencia son chocolate del loro.
#2 muy bien, has demostrado que Java no es la opción más eficiente para desplegar un Hello World.
Ya verás cuando descubras que un trailer de doble remolque no es la mejor opción para ir a la esquina a comprar una barra de pan.
El más eficiente energéticamente es sin duda PHP: te dan ganas de ahorcarte con el cargador del portátil, y una vez muerto, reduces un montón tu huella ecológica.
Un amigo informático me dijo que los programadores de verdad solo necesitan tres teclas: "0","1" e "Intro". Todo lo demás son cosas de flojeras.
#8 Usar "Intro" es de cobardes cuando puedes simplemente escribir 00001101 https://www.rapidtables.com/code/text/ascii/ascii-enter.html
#8 No tiene ni idea, los programadores de verdad usan mariposas https://xkcd.com/378/
Buen articulo. Son más las ganas de meter el foco de la retórica política en algo con calzador. Para sacarle rédito.
El artículo habla de estudios, otra vez pasa lo mismo, sesgados para hacer un discurso político con otras intenciones. que de lo que en principio trata el tema, que se puede abordar de otras formas. Independientemente del lenguaje.
#9 Mmmmmm... pero saltar a la vez no quiere decir que salten a la vez una vez. Pueden saltar a la vez varias veces. Si la cadencia de los saltos es la que se corresponde con la frecuencia de resonancia del planeta (o uno de sus múltiplos) entonces la energía se acumula hasta que llegan a desintegrarla, como ocurre con el sonido cuando rompe cristales a pesar de la enorme diferencia de masa.
Ahora en serio, no creo que los datacenters, minado, etc consuman una parte importante de la energía global. Quizás parte importante de la energía eléctrica, pero la global incluye carbón, gas, petróleo... habría que hacer números. Y muchos de los que más consumen ya están perfectamente optimizados: minado, enrutadores... nada de energía que se pueda disminuir ahí (por optimizar su software). Lo mismo ocurre con el sw que funciona sobre hw funcionando a batería, está altamente optimizado como parte del proceso industrial que hace uso de ese tipo de dispositivos.
En resumen, una curiosidad sin trascendencia ninguna como bien dice el artículo.
#12 No. Si quieres te lo explico, pero te convendría estudiar el movimiento armónico amortiguado y esas cosas. Da igual el número de veces, la cadencia o cualquier otra cosa que se te ocurra, la masa conjunta de toda la humanidad no es suficiente como para producir un cambio apreciable en ningún parámetro macroscópico de la Tierra. Ya no digamos poner en peligro su integridad.
https://www.datacenterdynamics.com/es/features/eficiencia-energ%C3%A9tica-reto-de-los-data-centers-del-futuro/
Los centros de datos hoy consumen más del 2% de toda la electricidad global, y también tendrá un crecimiento exponencial. Con la tasa de crecimiento actual, los centros de datos podrían consumir el seis por ciento de la energía mundial para 2025.
No sé qué consideras importante, pero un 2% con potencial de llegar al 6%, y estamos hablando sólo de los data centers, no es despreciable en absoluto. Que ya estén optimizados es otro asunto, pero no es lo que dijiste en tu comentario.
#13 Paso de lo de La Tierra, la verdad es que me la puedo cargar yo sólo el día que me de la gana. Respecto a los CPD, de acuerdo pero no se sigue que el grueso de ese consumo provenga de la ejecución de código, y sospecho que más bien será por los sistemas de almacenamiento, refrigeración, redundancias... Y del porcentaje del porcentaje que provenga del código, hay que restar el que ya está optimizado, que será la mayor parte por motivos obvios, ya que la optimización suele formar parte del proceso de desarrollo industrial del software.
Así que sigo en la mía, la existencia de software ineficiente es un problema del ámbito del usuario que lo ha de sufrir, no del planeta.
Se nos va la pinza midiendo la eficiencia energética por lenguajes. Si nos ponemos exquisitos, el menos eficiente energéticamente hablando si contamos las horas de programación.
También se puede tener en cuenta el tipo de aplicación, una UWP es mucho más eficiente que una Win32 y mucho más que una PWA.
#22 Lo comentan en el artículo.
"Lo que parece que los investigadores no han tenido en cuenta es que —fuera del laboratorio— es imposible determinar qué lenguaje de programación es más eficientemente energeticamente sin considerar el factor humano, las horas que empleará un programador en desarrollar y mantener el código. De nada sirve medir que el acceso indexado a una secuencia de 12 números enteros consume 309 julios con Lisp y 414 en JavaScript sin tener en cuenta el tiempo que emplearán los programadores en implementarlo con cada uno... y la eficiencia con la que lo harán."
#34 el coste de programarlo una vez en tu dispositivo es despreciable comparado con el coste de ejecutarlo múltiples veces en decenas, miles o millones de dispositivos
...y venga a meter frameworks sobre frameworks... Fue algo que me alucino de la programacion J2EE, que vale que te libera mucho de escribir tu esa funcionalidad a la que querias acceder, pero oye, no valia con una sola libreria en vez de tropecientas mil?
La mayor parte de la eficiencia viene del diseño, reutilización, ambición de meter mierdas, reutilización de código, etc.
El software se expande hasta ocupar todo el hardware y volverlo obsoleto.
Me parece horrible cuando no es necesario (muchas veces) pero a veces es necesario conforme se complica la lógica, la reutilización de mas y mas librerías, lo que esas lento y pesado.
#3 >la reutilización de mas y mas librerías, lo que esas lento y pesado.
Que dices, si son librerias dinamicas, en teoria ahorra espacio en memoria.
A no ser que uses plan9.
#18 Normalmente cargas una librería para utilizar una fracción de sus posibilidades.
Imagina que quieres crear un CSV pero cargas una librería que te permite generar ficheros Excel, Csv, etc. Esta librería te permite hacer el trabajo de una manera mas limpia, con menos errores, pero usarás muchos mas recursos. Adicionalmente esta librería se añade a dependencias, con el tiempo puede variar (crecer normalmente).
#48 Un csv por lo general se puede hacer hasta a pelo. No siempre se requieren librerias.
Pero estas manejan excepciones y posibles errores a la hora de generar y leer CSV's.
Y lo digo como usuario de AWK y jTCL.
#49 A eso me refiero. Era un ejemplo.
El uso de librerías está muy bien, disminuyes errores y simplificas código, pero hace también engordar el software y recursos consumidos asi como a veces dependencias.
Y la decisión depende del caso. Si el hardware no es problema, se usa la librería. Por estas cosas y por otras el software se expande como el aire conforme el hardware mejora, ralentizando las aplicaciones de nuevo.
#3 Eficiencia en que sentido... hace años que trabajo a alto nivel y la eficiencia es lo que comentas, antes trabajaba en otros curros donde la eficiencia eran ciclos maquina de los microcontroladores y hacer una exponenciacion modular de 1k en un micro de 8bits, importa mucho mas los ciclos consumidos que el que el codigo se entienda (que ya te digo que lo vi un par de años mas tarde y me costo lo mio entenderlo
)
Edito... si estaba comentado, pero aun asi
Es siempre se ha dicho que "sale más barato el kilo de hierro que el kilo de carne" por eso no se optimiza nada.
Si con eso consiguen que la batería de mi móvil aguante un día entero, a tope con ello.
¿En serio no parece relevante el consumo de energia con la que está cayendo? Puede que resulte irrelevante para un programa en un PC, pero esto es como la anécdota del que decidió quitar una aceituna de las ensaladas en los vuelos de American Airlines, y ahorró millones a la compañía, pero sin el aspecto cutre capitalista.
#4 si es irrelevante ya que la diferencia de consumo energetico en el mundo si todo desarrollo fuese hecho con el lenguaje mas eficiente seria un ahorro demasiado pequeño como para ser interesante, hay otras cosas como los envios por mar o mil otras cosas donde se puede mirar antes
si hay sitios donde el consumo es super importante si no que se lo digan a la NASA por poner un ejemplo o el electronica alimentada por RF (por ejemplo tags pasivos smart)
Edito... Lo que ahorraron fueron 40.000 USD en el 87 por lo que he visto asi que no ahorro millones ni con la inflaccion.
Edito2...
#9 Bueno vale si metemos el minado de cryptos te compro que si es importante ... en ese caso si
Curioso, aunque no creo que el hecho en sí sorprenda a nadie. El tope teórico (inalcanzable) de ahorro energético por optimizar todo el software del planeta es exactamente el porcentaje de energía que todo el software en ejecución consume respecto al consumo energético global de todo el planeta. Y este porcentaje es tan insignificante que dudo incluso que se pueda calcular. Datos absolutos muy impactantes, que pasan a 0.0 cuando se convierten en relativos. Y caso de no ser así, para cuantificarlos más correctamente y como dice el artículo, habría que contabilizar también el factor humano y qué porcentaje se ejecuta en hardware obsoleto (ineficiente). Es decir, una curiosidad en la linea de que si todos los chinos saltaran a la vez, la Tierra se desintegraría. Verdadero a la par que imposible.
#5 La Tierra no se desintegraría porque los chinos, o incluso toda la humanidad, saltaran a la vez. La Tierra, incluso sólo a nivel biosfera, apenas lo notaría ( https://what-if.xkcd.com/8/ ). Del mismo modo, la energía que consume todo el software en ejecución no es en absoluto despreciable. Los grandes data centers, el minado de criptomonedas, todos los enrutadores de comunicaciones... Consumen una parte importante de la energía global. El consumo de software en mi casa, con luces LED, te puedo asegurar que no es despreciable. Pero es que además ese no es sólo el problema, hay mucho hardware funcionando con batería que tiene otras limitaciones energéticas.
Quizás la diferencia de consumo dentro de un equipo no sea relevante, pero si ese software va a correr en millones de equipos ( como un sistema operativo, un navegador de moda...), el consumo de energía sí es relevante.
Aquí los abuelos cebolleta que recuerdan sus prácticas en la universidad en Ensamblador...
Joer, que nos picamos en una práctica semanal un editor de texto que buscaba palíndromos y comprobaba además si el texto entero era palíndromo... Ni recuerdo cuántas etiquetas le metimos para los goto
En el enlace no dicen nada ni remotamente parecido a lo que pone en el titular del meneo.
#0 Ya está bien de meter vuestras opiniones en los meneos. Envía las cosas íntegras o no las envíes.
#24 Es el título que me propuso Menéame, ni me fije que no era el mismo que aparece en la noticia.
Debió ser un titulo inicial y por el código se quedó
#33 Vale, disculpa entonces.