Portada
mis comunidades
otras secciones
![¿Qué lenguajes de programación consumen menos electricidad? [ENG]](https://cdn.mnmstatic.net/cache/2f/64/media_thumb_2x-link-3105808.jpeg?1553978826)
#1:
cuánto más bajo sea su nivel mejor, assembler seguro que gana. Eso sí ta jubilas antes de acabar de programar algo mínimamente complejo.
#12:
#1 Eso sí ta jubilas antes de acabar de programar algo mínimamente complejo.
¿Por qué? en su día los programadores de juegos se compraban un libro en inglés, sin tener ni papa, y con un poco de práctica y haciendo ellos sus propios gráficos sacaban juegos que las distribuidoras vendían muy bien.
Es más complicado, claro. Pero tampoco hay que exagerar.
¿Por qué? en su día los programadores de juegos se compraban un libro en inglés, sin tener ni papa, y con un poco de práctica y haciendo ellos sus propios gráficos sacaban juegos que las distribuidoras vendían muy bien.
Es más complicado, claro. Pero tampoco hay que exagerar.
#11:
#7 Realmente, los compiladores siguen generando bastante porqueria. Pero es una porqueria que las CPU saben paralelizar de forma mejor que hace años, por lo tanto es cierto que si programas en ensamblador tu programa va a ser menos eficiente, pero es debido a que el microcodigo de los procesadores actuales se diseña pensando en que la mayoria del codigo que se va a ejecutar viene de un compilador, o mejor dicho de un backend de un compilador. Los backends los crean los fabricantes de micros, los frontend, poquisimos fabricantes ya que son sistemas muy complicados y dependen mucho de las decisiones de las comisiones ISO que crean los estandares.
Comentarios
cuánto más bajo sea su nivel mejor, assembler seguro que gana. Eso sí ta jubilas antes de acabar de programar algo mínimamente complejo.
#1 Esto le parece mucho más relevante que el cuanto gaste el ordenador. Si al final gastas más energía en el desarrollo.
#1 Al contrario, es una creencia común pero no es cierto. Es mucho más probable que escribas código más ineficiente en asm que por ejemplo en C. Los compiladores optimizan muchísimo la generación de código máquina hoy en día (ya hace muchísimos años de hecho).
#7 Realmente, los compiladores siguen generando bastante porqueria. Pero es una porqueria que las CPU saben paralelizar de forma mejor que hace años, por lo tanto es cierto que si programas en ensamblador tu programa va a ser menos eficiente, pero es debido a que el microcodigo de los procesadores actuales se diseña pensando en que la mayoria del codigo que se va a ejecutar viene de un compilador, o mejor dicho de un backend de un compilador. Los backends los crean los fabricantes de micros, los frontend, poquisimos fabricantes ya que son sistemas muy complicados y dependen mucho de las decisiones de las comisiones ISO que crean los estandares.
#7 es una creencia común porque es cierta. Si los compiladores optimizan muchisimo porque se programa en python y luego se pasa a C las partes que requieren velocidad? Es cierto que han mejorado mucho pero siempre se podrán optimizar más aún siempre. #11 tiene mucha razón también, pero por muchas piezas de lego que hagan nunca podrás hacer el David de Miguel ángel con legos.. Otra cosa es q no merezca la pena.. Con el hardware actual
#13 Pues porque python es un lenguaje interpretado no compilado, por lo que no hay compilador que óptimice
#21 no se hace ningún tipo de compilación? En PHP, por ejemplo, desde hace bastantes versiones se deja el Byte Code compilado para que las siguientes veces no tenga que parsearse el Script y, de hecho, el salto el velocidad y rendimiento de PHP7 debe mucho a cambios y optimizaciones en ese proceso...
En Python no tengo idea, por eso pregunto.
#67 Python cuando usas un script por primera vez genera archivos .pyc (o pyo si lo indicas) que son una version bytecode del mismo, creo recordar.
#33 no me conoces... no tienes capacidad lectora antes de que me contestes la chorrada del #21 leete la respuesta que le he hecho. El python se puede compilar (te lo resumo).
En año 90 yo programaba en ensamblador para el Z80 en un amstrad 464 cargadpres para pokear juegos o simplemente cacharrear, en mis años de Universidad me presentaba a consursos de demos grafias en la categoria de 4kb (demos graficas de menos de 4kbytes de tamaño nada que ver con 4k de resolución) las hacía en C y no compilaba exe sino que generaba el assembler que luego optimizaba para luego generar el exe con un ensamblador y luego usaba un compresor de exes. En el 94-95 anaba concursos de programación en a revista PC Actual programando en C++ siendo ganador por usar los mejores algoritmos, en el... 2002 aprox cree Exeware (si mi nick) un bot para la red p2p Edonkey que fue lider de descargas en Softonic varios meses... actualemente trabajo de programador en una multinacional que conoces de sobra y es muy probable que hayas usado algun software mio sin saberlo.
Y si todo esto lo consegui aposta!
#74 goto #81
La primera vez que la sentencia GOTO fue con el basic del 464 es una sentencia que tiene una traducción directa a ensamblador que es "jmp " no hay mucho margen de mejora en esta instrución. Un IF en cambio se suele compilar en el codigo que calcula condición booleana y al final suele haber una instrucción de JMP condicional suele ser un JNZ que quiere decir salto si no es ZERO es decir si el FLAG ZERO del procesador no esta activo, esta FLAG se activa tras una operacion que da como resultado cero, de ahí que en C el cero sea el falso y el resto sea true por que se compila a un JNZ.
Pero tu eso ya lo sabes yo lo acabo de aprender me gustaría que tu me expicaras como afecta alpreceso de convertir a ensamblador instruciones como:
- operadores ++
- el uso de asignación multiple del tipo a=b=c=d=5;
- como afecta la anterior en caso de ser esa en una subrutina o ser en el main.
Demuestrame que sabes... sino sigue tu norma sino sabes o entiendes NO HABLES.
#48 goto #80 y tb visita #81 lo siento pero Bolonia para mi solo es una ciudad de Italia para la epoca del plan Bolonia yo ya era programador profesional. Sé que el python no se compila pero pretendía dar un ejemplo de como lenguajes modernos como el python precisan de lenguajes de mas bajo nivel para conseguir mas rendimiento, que si que es inerpretado pero no por ello no puede ser muy iptimizado como ha pasado con con el motor V8 para javascript que desarrollo Google.
Tu segunda frase no consigo compilarla... me da sintax error, no consigo interpretarla tampoco.
#81 Tenemos vidas paralelas, yo aprendí ensamblador, pasacal, cpm y BASIC 1.1 a los 6 años con un Amstrad 6128, y estuve un poco en el mundo de la demoscene pero creo que las demos de 4k iban en .com normalmente, a lo mejor me falla la memoria.
#90 ya ha llovido y probablemente tengas razón la diferencia entre un COM y un EXE es que el COM no tenia header info por que por implicito todo se cargaba en el mismo segmento de memoria o era para un solo segmento para codigo, pila y datos, creo recordar y eso eran unos preciosos bytes ganados con respecto a un EXE que tenia un heder para informar al ms dos de como cargar en memoria todo el fichero.
#90 excedi tiempo de edición solo queria añadir que aún así mi recuerdo es de usar exes por que podias gastar mucha mas memoria y las demos en 4k no podías gastar espacio en tener sprites prehechos lo que solias hacer es generar mucho grafico en forma fractal en tiempo real y necesitabas mucha memoria y ademas el empaquetador tenia margen para desempaquetar el otro sector de memoria pero lo del COM tb me suena...
#13 Es curioso como en una frase has dejado claro que no tienes ni idea de C, ni de python, ni de ensamblador ni de como funciona un ordenador con un poco de detalle.
Lo haces aposta y no te sale.
#33 tú eres muy listo y sabes mucho de tó.
#39 No se de to, pero intento no hablar de lo que no se.
#33 no me queda claro por qué no tiene ni idea, danos una justificación que el resto también le fustiguemos
#71 "Si los compiladores optimizan muchisimo porque se programa en python y luego se pasa a C las partes que requieren velocidad?"
Compilador para python? C como no compilado? Estamos locos?
#73 joder, sí que es gorda. Lo había leído rápido y no había caído
#73 GOTO #80 spoiler el python si se puede compilar y sorprendete el Javascript tb!!!
#83 Todo el rollo que has metido no invalida que la chorrada que has soltado es una gilipollez tan grande que se ve desde saturno.
#91 gracias por argumentarlo se te ve que solo trolleas desde "Icarus".
#93 Lo he argumentado claramente en este mismo hilo en #73. No pienso repetir comentarios porque a ti no te de la gana leertelos.
#96 reconozco que con nula capacidad comprensiva (mi perro lo interpretó como tu) puede interpretarse como afirmas pero yo escribi:
"Si los compiladores optimizan muchisimo porque se programa en python y luego se pasa a C las partes que requieren velocidad?"
lo que no has querido entender es que pregunto por que se programa en python y no se usa otro lenguaje compilado que no sea el C para las partes veloces? si son tan buenos los compiladores por que no usar otro lenguaje compilado mas comodo que el C? lo entiendes así? pero es que aun que fuera como tu has malinterpretado crees que un lenguaje que tiene compilador es imposible que sea interpretado y viceversa y eso es falso. Crees también que decir compilar sólo se aplica a lenguajes compilados cosa también falsa en los lenguajes interpretados existe una compilación, aúnque sea sólo in time (JIT), y es suceptible de ser optimizada el motor de javascript V8 hasido una recolución y es para javascript!!
Interprete de C:
http://www.softintegration.com/products/chprofessional/ te presento un interprete de C
Compilador de Python usando compilación JIT:(observa que dicen compilador en su descrición estan loquísimos)
https://pypy.org/
https://en.wikipedia.org/wiki/MicroPython
https://en.wikipedia.org/wiki/Numba
#99 Anda a pastar picateclas! Lo que te pasa es que no tienes ni puta idea de programacion y mucho menos de expresarte. Como mucho llegas a ser un aprendiz de picacodigos.
Se te ya visto el culo y intentas taparlo sin darte cuenta que solo haces que el ridiculo.
#100 eres tan engreído que cuando lees algo sin sentido en lugar de buscárselo, por si has podido ser tú quién ha leído mal, o por si ha sido tu interlocutor el que no se ha expresado bien... Crees, directamente, que tu interlocutor es tonto, porque así, tú (que si lo eres) te crees listo por un momento.
Te lo pongo fácil, esto es lo que (aplicando un poco de lógica y asumiendo que no se caga encima) se entiende del mensaje del otro meneante:
Si los compiladores optimizan muchisimo:
¿Por qué se programa en python y luego se pasan a C las partes que requieren velocidad?
Habla de que muchas veces hay procesos críticos en un sistema que tienes que delegar a un lenguaje compilado (puede ser para una VM, también) porque los interpretados no "dan la talla" en ese tipo de tarea.
Parece que tienes complejo de picateclas
#100 he de reconocer que eres muy buen troll
#71 gracias!! hay por aqui una panda de hienas que creen oler sangre, pero ya los fustigo yo mismo.
#21No me digas? quien lo hubiera imaginado sueltas esa gran tonteria y te votan 11 personas!!! y tan ancho!! son tu familia? dales saludos, y si no lo son en serio? lo de interpretado no compilado puedo entenderlo... pero lo de no hay optimización.
Pues porque python es un lenguaje interpretado cierto! pero no tanto como tu crees tengo cosas que aclararte sobre por el hecho de que sea interpretado no invalida lo que pretendo decir pero te lo explico mas adelante. Un link de intro:
https://nedbatchelder.com/blog/201803/is_python_interpreted_or_compiled_yes.html
no compilado, esto es falso te paso unos link para que te culturices:
https://www.wikihow.com/Compile-Python-Script
https://stackoverflow.com/questions/471191/why-compile-python-code
si puede ser compilado, no es lo usual lo se! pero lo siento si puede ser compilado sorry!!
por lo que no hay compilador que óptimice bueno esto es la traca final la tonteria tienes alguna ligera idea de la burrada que acabas de decir? que por que es interpretado no es optimizable? really? si bien es cierto que no tengo el mismo ejemplo para python te pongo el ejemplo del javascript que es un lenguaje interpretado pero que los lerdos de google pensaron que tú no tenias razon y desarrollanron el V8 engine el cual compila (siiiiiii compila) el javascript, crearon un JIT (just in time compiler) para Javascript consiguiendo un rendimiento para el Javascript similar al de un lenguaje compilado haciendo que el javascript se conviertiera en la base para crear nodejs y cientos de cosas mas que hoy en día se hacen en javascript que sin el motor V8 desarrollado por los tontos ingenieros de Google. Referencias:
https://blog.sessionstack.com/how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e
https://en.wikipedia.org/wiki/Chrome_V8 lee la parte donde dice:
"V8 compiles JavaScript directly to native machine code before executing it, instead of more traditional techniques such as interpreting bytecode or compiling the whole program to machine code and executing it from a filesystem. The compiled code is additionally optimized (and re-optimized) dynamically at runtime, based on heuristics of the code's execution profile. Optimization techniques used include inlining, elision of expensive runtime properties, and inline caching. The garbage collector is a generational incremental collector.[7]
V8 can compile to x86, ARM or MIPS instruction set architectures in both their 32- and 64-bit editions; as well, it has been ported to PowerPC[8] and IBM s390[9][10] for use in servers.[3][11]"
Asi que resumiendo ir a tomarle el pelo a otro por que el python si se compila y si puede ser optimizado al compilar que no se haya generado un JIT para él no quiere decir que no pueda haber una buena optimización del código máquina que se genera al interpretarlo... si quieres coger mi respuesta entre pinzas y ser mas papista que el papa eres libre, pero creo que lo que quiero decir esta bien claro, no hace falta ser tan prejigueros por que te pueden dar un zasca epico como el que te acabo de dar.
#33 y #48 voy con vostros ahora mismo pero por si acaso tomar nota.
#13 lo que dices de Python demuestra que Bolonia ha hecho mucho daño...
Y que reciclar código es bien... aunque luego pase lo que pasa en cuanto a seguridad... Pip!
#32 exacto! esto he tratado de decir en #13 y la peña se lo ha flipado, esas instruciones de mas son las piezas de lego que me refiero el C compilado genera bloques muy infimos pero bloques prehechos que son optimizables. Otra cosa es que salga rentable tanta optimización.... por suerte el hardware actual elimina esa necesitadad de optimizar tanto. No sale rentable.
#86 Gracias por molestarte en las aclaraciones por aquí. Por cierto, me sorprende que java sea tan eficiente en tiempo y gasto de energía. Pensaba que su compilación a bytecode y de este al de la máquina no estaría tan optimizado.
#88 contaron el tiempo de pasar a byte code? creo que no... bueno... java es casi el doble de lento que el C, no es que sea tan rápido es que los otros son mas malos (algunos de estos lenguajes no estan pensados para estos algoritmos quizas? y su optimización no se dirija en ese sentido), y que resuelve muchas cosas a base de gastar memoria, mientras se usa la memoria el procesador (la parte que se calienta que consume energia, esta ocioso) y por lo tanto es muy rentable en terminos de energía. Creo que esta comparativa sólo es interesante para escoger lenguaje para un aparato que vaya a tener muy poca alimantacion de energia algun tipo satelite o asi... que necesite funcionar con una autonomia bestial con muy poca energia pero si no... es una comparativa muy esteril... el claro ganador es el C que es primero en energía y tiempo y sólo tercero en uso memoria pero siendo tercero con un 17% mas de uso de memoria, no un 59% mas de tiempo siendo tercero del C++. He de admitir que no conocía el Rust pero que parece ser muy bueno... pero claro si uno mira que su sintaxis es muy similar al C y que es muy bueno en concurrencia seguramente haya sacado buen jugo del procesador y sin embargo el consumo es muy equilibrado.
#11 Lo de que los backends de los compiladores los crean los fabricantes de micros... No me consta... Osea, no digo que no colaboren, que sí, pero tanto CLANG como GCC como Visual Studio que yo sepa no tienen backends hechos por AMD o Intel para x86-64, por ejemplo... Otra cosa es que Intel tenga su propio compilador, por ejemplo.
#11 No, el código que generan los compiladores no es ninguna porquería. Prueba a compilar con todas las optimizaciones al máximo y mira el ensamblador que genera, eso no lo escribes tú ni de coña. Y es así por una sencilla razón, el compilador puede considerar posible optimizaciones para las cuales ningún humano tiene cerebro suficiente.
En cuanto a la diferencia entre frontend y backend, ¿qué tienen que ver aquí las comisiones ISO? No todos los lenguajes pasan por ese proceso.
#51 lo has hecho? Yo si lo he hecho, con icc de intel y optimizaciones a tope. Es codigo feo y a veces redundante, con poco uso de instrucciones de alto nivel tipo rep pero que se entienden bien con la pipeline del procesador. Prueba un for con cuatro o cinco iteraciones y me cuentas. En arms, gcc y -Ospeed es muchisimo peor, pero el codigo vuela. Las tecnicas de optimizacion tipo pephole tienen un cierto impacto pero es bastante limitado. Lo que suele ser mas efectivo es la reordenacion, vectorizacion y loop unrolling. Esto ultimo genera mucha porqueria para los humanos. Hay que esperar que la IA va a jugar un papel importante aqui en el futuro, pero no aun.
En cuanto a tu pregunta, mirate por aqui https://isocpp.org
#87 Sí, lo he hecho, por eso he escrito mi comentario. No entiendo muy bien tu comentario, al final estás reconociendo que el código del compilador es más rápido.
Y en cuanto al estándar ISO, muy bien, pero ni GCC ni LLVM son sólo compiladores de C++. Es más, LLVM es una plataforma independiente del lenguaje, por eso hoy en día se utiliza tanto para implementar todo tipo de compiladores.
#103 "al final estás reconociendo que el código del compilador es más rápido." al final y al principio, leete mi primer comentario en #11. Los compiladores generan basura, pero mas rapida que asm escrito a mano.
#7 No lo creo, la verdad. Yo he hecho mis pinitos con asm y C, compilando con diferentes modos de optimización y siempre el código es más reducido que el que puedes obtener al descompilar el mismo programa en C. De hecho, en cosas muy básicas como una simple llamada a una syscall el GCC siempre mete alguna instrucción de más.
#27 Y lo que le queda. Es la base de la mayoría de los sistemas operativos.
#32 concluímos que para un Hello World, ASM es lo mas óptimo
#32 hubo una época en la que programaba en C para Pic... y un puto for me petaba el micro... así que no quedaba más remedio que el puto for hacerlo en ensamblador (sobre todo por la condición) y volver a C para el contenido del bucle...
#32 Que el código sea más corto no significa que sea más eficiente, el compilador puede estar usando instrucciones "mejores" u ordenándolas de tal manera que haya menos dependencias de datos. Hablas de syscalls, ¿estás seguro de que has cumplido al 100% con la ABI y no te has olvidado de pasar nada?
#7 A ver, no es realmente cierto ni lo uno ni lo otro...
Harás código más eficiente en ensamblador si sabes lo que estás haciendo, si no no
Claro que cuanto más bajo es el nivel del lenguaje de programación más difícil es saber realmente lo que estás haciendo
#7 No hay que generalizar, dependiendo de lo que estés implementando, de los conocimientos y experiencia del programador, y también de la iSA en cuestión (Con un CISC sería más fácil que con un RISC) el código ensamblador puede ser más eficiente que C, que sería lo más cercano a ensamblador en alto nivel. Una de las razones, por ejemplo, es que normalmente el código ensamblador es muchísimo más compacto que el genera los compiladores, eso significa que hay muchas más posibilidades de que entre todo en las caches, y en los procesadores actuales traer datos desde la memoria principal es muy costoso debido a las diferencias de velocidad entre las CPUs y estas.
#7. Estoy de acuerdo, pero no creo que tenga que ver tanto con la optimización del código de los compiladores de C (los compiladores no hacen milagros) como con las buenas prácticas y el marco mental que te ofrece la estructura de un buen lenguaje de programación como es el C.
El caso del lenguaje Haskell en la gráfica es muy llamativo, pues al ser intrínsecamente un lenguaje recursivo consume tanta memoria como energía. Y sin embargo lo que he planteado en el primer párrafo es totalmetne aplicable también a Hasckell, el marco mental y de estructura que ofrecen los lenguajes funcionales te 'obliga' a pensar y estructurar la programación en un grado desconocido para quienes nunca lo han probado antes. La programación funcional es un mundo a descubrir que vale la pena y ofrece posibilidades en formas insospechadas a la hora de resolver algoritmos.
(CC #1)
#1 leer los enlaces está sobrevalorado, ¿verdad?
#9 Leído está. ¿Dónde mencionan assembler o código máquina?
#1 Eso sí ta jubilas antes de acabar de programar algo mínimamente complejo.
¿Por qué? en su día los programadores de juegos se compraban un libro en inglés, sin tener ni papa, y con un poco de práctica y haciendo ellos sus propios gráficos sacaban juegos que las distribuidoras vendían muy bien.
Es más complicado, claro. Pero tampoco hay que exagerar.
#12 En su época programaba virus complejos, muy buenos recuerdos.
#12 En su día (prehistoria) muchos homo sapiens construían chozas con paja y excremento de vaca, no sé por qué el Burj Kalifha no se construye exclusivamente a mano y entre 2 o 3.
#22 Aún se sigue haciendo en varios países:
https://www.globalcitizen.org/en/content/who-uses-sht-to-build-a-house/
#22 Sí, pero no "se jubilaban antes de poder hacer una choza"
Eran más difícil, pero tampoco es que fuera imposible . No hay que exagerar
#12 me va a usted comparar la ISA del z80 con la de un moderno x86
#12 ¿Estás comparando un juego de Spectrum o C64 con un triple A actual?
#55 no
#12 no me compares el nivel gráfico del abu simbel profanation y su complejidad técnica con los triple A de hoy en día. Se han creado máquinas con más memoria y más potencia, precisamente para evitarnos tener que programar a tan bajo nivel. Si ya cuesta encontrar programadores senior de lenguajes de alto nivel, no quiero pensar lo que puede costar encontrar uno que sea bueno con ensamblador.
#1 Programar escribiendo 0 y 1 es lento pero proporciona códigos muy eficientes.
#14 eso es binario...
#14 Si tu cerebro es eficiente si. En caso contrario lo dudo.
A mínimamente complejo que sea el programa, en compilador vas a hacer cagadas monumentales.
#1 me acuerdo una vez que programé algo relativamente simple para código máquina (ya ni siquiera ensamblador) y aquello era como vaciar una montaña con una cucharilla (ya me entiendes)
#1: Depende, el Roller Coaster Tycoon está programado en ensamblador en su mayor parte.
#16 no me lo puedo creer! A ese juego jugaba yo de chica y me encantaba. Vaya curro se dio
#38: Puedes creértelo: https://en.wikipedia.org/wiki/RollerCoaster_Tycoon_2#Development
Y el Locomotion y el Transport Tycoon, igual, fueron hechos en ensamblador.
#estudiochorra
#2 A mi me da igual que mi coche consuma 4, 40 o 400 litros cada 100km, total la mayor parte del tiempo está parado. Pero para los que tienen millones de coches funcionando 24h al día puede ser interesante tratar de que gasten lo menos posible.
#5 Difícilmente te de lo mismo que un auto consuma 4 o 400 litros cada 100km, solo porque la mayor parte del tiempo esta parado.
No es realista ese planteo, aunque me digas que realmente a ti te da lo mismo.
#29 al chico Le da lo mismo que un video de YouTube Le tarde en cargar 4ms 40ms o 4s, si total, se ve un par de vídeos al día...a eso se refiere, a que para algunos puede parecer una tontería pero 4ms por búsqueda de Google o Amazon son muchos miles de euros de diferencia.
#5 ¿Es un coche ornamental?
#2 No.
A mí lo que me parece sorprendente que un lenguaje tan "antiguo" como C siga ahí en la brecha como el primer día, el primero en todos los supuestos combinados que mencionan. Creo que no hay monumentos suficientes para Dennis Ritchie.
#27 $deity lo tengo en su gloria, no se ha hecho ni se hará justicia jamás al trabajo de ese hombre.
#27 Básicamente porque se han invertido cantidades inmensas de tiempo y dinero en optimizarlo al máximo, no es que tenga un diseño particularmente "eficiente". Sorprendente es que un lenguaje recién llegado como Rust esté casi a la par de rendimiento (aunque en esto tiene mucho que ver LLVM).
La verdad es que este estudio solo sirve como referencia muy básica. Lo he leído por encima, y al parecer solo se refiere a implementación de ciertos algoritmos, pero habría que ver otras cosas como la cantidad de fugas de memoria de promedio por línea de código que se suelen producir, y en proyectos grandes, otras cosas como los sistemas de cacheo o la capacidad de paralelización.
Por ejemplo, a bote pronto, me extraña que Haskell de tan pobre rendimiento, cuando su capacidad de paralelización en un mundo lleno de núcleos e hilos es altísima.
También me extraña el pobre rendimiento en memoria de Java, que es cierto que tienes que cargar la máquina virtual, pero en servidores, dónde más se usa, su capacidad de compartir recursos entre muchísimas peticiones es buenísima.
Es decir, en mi opinión han tomado ciertos algoritmos, los han implementado a pelo sin tener en cuenta las particularidades/optimizaciones de cada lenguaje/plataforma y se han puesto a tomar datos sin más.
#34 Haskell no da pobre rendimiento, está entorno a 3x el coste de C en las tres métricas consideradas. En cambio los lenguajes dinámicos multiplican ese coste por 30 ó 40. Si en la primera gráfica hubieran puesto todos los lenguajes se vería más claro.
#58 He tenido una cruzada de cables terrible entre Haskell y Erlang.
#65 Ah, eso es otra cosa. Por lo que yo tengo entendido, BEAM (la máquina virtual de Erlang), no está enfocada en obtener el máximo rendimiento, si no en una muy alta escalabilidad y tolerancia a errores, dos cosas que alcanza de manera notable. Sencillamente, sus criterios de diseño son otros.
#34 tu puedes paralelizar todo lo que quieras, pero si en lugar de un hilo ejecutada dos tratando la mitad de tiempo pero usando dos CPU en lugar de una, terminas consumiendo lo mismo. Solo que has tardado menos.
Otro tema es si en lugar de medir el consumo para realizar la tarea lo que mides es el tiempo.
Lo curioso es que no tiene en cuenta el programador medio, me refiero, según el lenguaje se usa un ordenador o otro típico, donde se debería ver cual es el consumo medio y con sus costumbres diferentes.
¿y cuál compilador?
Contra que el compilador FreePascal (que es el por defecto del IDE Lazarus) es una cosa y el de la Borland ahora de Embarcadero (que es el de Delphi/Kylix) es otra radicalmente diferente (tanto en velocidad de compilación como peso de los ejecutables uno al otro extremo del otro en esto. Lástima que sea privativo un compilador más rápido que el gcc y frene la evolución del ObjectPascal )
Bueno. Pues ¿los demás?
Y una vez más se demuestra que JavaScript es mejor que Phyton.
#17 Puestos a comparar lenguajes de mierda...
#17 Ni de coña. JavaScript es un cáncer, cada vez tardan más en cargar las putas webs.
#59: Pues imagínate si fuera Phyton.
Hace poco leí que dado que ahora que los ordenadores son muy rápidos, y el recurso más caro en el desarrollo de software no es la hora de proceso y ejecución de los programas sino el tiempo de programación (sueldo del programador), se está pasando a lenguajes de alto nivel más accesibles como Python porque si con él haces un programa en 20 minutos que tarda en ejecutarse 16s cada vez, te va a dar igual que uno en C que se haya programado en 45 minutos y se ejecute en 7s.
No puedo encontrar el artículo pero esta era la idea.
#35 jajajaja sí, tú pásate a Python o cualquier otro lenguaje no tipado y ya verás qué rápido avanza tu proyecto a la que tome cierta dimensión.
#35 Depende del sector. ¿La tienda online de una pequeña empresa que recibe 10 pedidos al día? Hazla en el lenguaje que quieras. ¿Un código de simulación física del carajo? Más te vale optimizarlo al máximo y usar el lenguaje más eficiente posible.
#60 pues es uso principal de Python es en los sistemas de información geográfica, estadística y simulaciones.
#76 Porque en esos ámbitos Python se usa como "cola" para enlazar librerías sesudas escritas en lenguajes más eficientes. Algo que python hace muy bien.
#97 Efectivamente, es como tú dices. Si Python es tan popular ahora es porque enlaza con numpy, scipy, etc.
Pero además, Python se utiliza para programas pequeñitos, el que un investigador ejecuta en su ordenador. En mi centro de trabajo tenemos un supercomputador que actualmente está entre los 100 primeros del Top 500, y te aseguro que eso no se programa en Python.
#35 Es que hay muchos factores que hay que tener en cuenta, esa afirmación no es válida en general:
- ¿Cuánta gente va a usar ese programa?
- ¿Cuántas veces se va a ejecutar?
- ¿Va a ser necesario modificar el código?
En algunos ámbitos funcionará lo que dices, porque efectivamente da un poco igual el tiempo de ejecución y el coste de desarrollo sí que escuece. Pero dile a Google o a Amazon que da igual si su página principal, a la que acceden millones de personas por segundo, está optimizada, que simplemente le echen más CPUs y más RAM
Según la tabla normalizada ¿Perl consume casi 80 veces más energía que C? ¡El uso de Menéame contamina!
Y ABAB4 y todo el tinglao de SAP AG?. Lo digo ya, eso es un muerto en consumo de meoria, lento, y costoso. Sobre todo para la empresa.
no se han atrevido con el java ??
#66 Java está entre los que menos electricidad consumen.
#69 Sí, me ha dejado anonadado. También consume menos tiempo aunque más memoria. ¿Sería Java compilado directamente a la plataforma donde se ejecuta? Porque no cro que sea el que se ejecuta en bytecode ¿no?
Edito: ¡no es asi! Of the top five languages in both categories, four of them were compiled. (The exception? Java.)
#69 Eso no posible ser
Y después de este artículo, nos ponemos con Kubernetes.
Que? ya nadie programa en assambler?
Estudio chorra, la eficiencia* de un lenguaje o programa hecho en x lenguaje no solo depende de la tecnología, sino que también influye el buen hacer del programador/es. Si es alguien que no sabe aprovechar los recursos y minimizar el coste de computación gastará más.
*Cuantas más operaciones deba realizar más gasto energético.
#3 eso depende si tú programa lo va a utilizar una persona o un millón.
#8 #3 Exacto, si lo usa poca gente quizás las horas que has dedicado a óptimizarlo hace gastar más (porque tienes el aire acondicionado encendido según programas) que el hecho. O si es que has óptimizado 100 ms en algun algoritmo central de Google y has ahorrado el consumo de una ciudad.
#24 no sólo eso. Una optimización prematura seguramente sea más difícil de entender y por lo tanto de mantener o extender. A la larga (no tan larga) es más caro
#24 Tal cual. Por eso lo primero que se hace cuando se quiere optimizar un programa es ver cuanto espacio para mejoras de rendimiento. Lo primero es ver si, sin cambiar el algoritmo, se está muy lejos o no del pico de rendimiento de la máquina para la complejidad de la carga que está ejecutando. Si la mejora no es suficiente, se pasa a buscar modificaciones del algoritmo, o directamente a cambiar el algoritmo. Esto último es lo mas caro (en tiempo) de hacer, por lo que sólo se hace cuando se tiene claro que va a haber un beneficio claro.
#3 A mi personalmente me parece un poco sesgado el estudio, el tema es que analizan distintos algoritmos (arboles binarios, fractales,...), que generalmente se implementan en C/C++ y luego haces wrappers para lenguajes de más alto nivel. A este nivel siempre un lenguaje compilado va a marcar una diferencia considerable, no hace falta un estudio para ello, por ello los motores de cálculo suelen hacerse en C++ (más que por eficiencia energética, por tiempo de ejecución).
La cuestión es, PHP o Python no se caracterizan por la eficiencia del lenguaje en sí mismo, de hecho en el caso por ejemplo de Python habría que hablar de distintas implementaciones (muy probablemente Pypy se comporte muy superior a CPython, pero la realidad es que rara vez se usa en sistemas productivos). Estos lenguajes se apoyan en lo mejor de los dos mundos, eficiencia en las operaciones de bajo nivel (C/C++) y agilidad a la hora de desarrollar el alto nivel (frameworks en lenguaje interpretado).
Incluso a la hora de desplegar una aplicación web de suele tirar de código nativo (Apache/NGINX/...) y lógica en lenguaje interpretado.
La cuestión es que hay código más o menos critico en cuanto a requerir eficiencia en tiempo. En el más alto nivel suele ser despreciable, en comparación con las ayudas del lenguaje en cuanto a tiempo de desarrollo.
#3 No solo depende de las operaciones y de la velocidad de estas. Hay periféricos dentro del microprocesador que consumen más o menos energia. Suponiendo que mandar algo a la pila y recuperarlo gasta más energía que mantenerlo en un registro quizás haya maneras de programar, o de compilar en programa que sean más ecológicas que otras.
Ahora mismo los compiladores te ofrecen compilar para que la hueya en memoria sea menor, o para que el código sea más rápido. En el futuro quizás puedan ofrecer generar un código más verde. Y no tiene por qué ser proporcional al coste computacional. Lo dice el propio envío.