El consumo energético de los lenguajes de programación

En la actualidad los ordenadores son tan potentes que, quitando aplicaciones especializadas, lo que más preocupa a los usuarios es que los programas no se "cepillen" las baterías de sus portátiles y móviles en unos minutos. Y si no fíjate en las críticas que tiene el navegador Chrome por este motivo, o la manera escandalosa de acabar con la batería que tiene Pokemon Go. Por supuesto, más allá del consumidor, el consumo energético en los centros de datos es una cuestión de suma importancia económica.

[#1 skaworld]

Preocuparse por el gasto energetico de tiempo de proceso de un lenguaje u otro, cuando luego tienes todo el codigo lleno de loops dentro de loops dentro de loops, llamadas a base de datos ineficientes, sin cursores....

[#2 Desactivado]

#1 Quizá si no te preocupas por buscar 1 linea entre 1 millón en menos de un segundo, supongo que para ti no es problema.

Para el que tiene una operadora de móvil con millones de clientes, sí.


En tu caso, no hablas de código, hablas de una mierda de trabajo mal hecho, y en cualquier caso, habrá lenguajes que aún metiendo toda tu mierda, sean más rápidos que algo muy purista hecho en otros lenguajes...

[#4 skaworld]

#2 Vamo a ver, mi campo son ERPs industriales, SAP, Analista Técnico, no tengo ni puta idea de a que te refieres con buscar una linea entre un millón en menos de un segundo cuando aqui se esta hablando de código o sea que, disculpame presupongo que escuhcas campanas.

Cuando la mayor parte de lo que paga mi alquiler, es revisar procesos que ocupan en el CPD 8 putas horas y tras reingenieria pasan a consumir 5 minutos igual empiezas a valorar que el problema no es el lenguaje, ni que la base de datos sea SQL o NoSQL, nisiquiera el equipo donde corren las cosas, el problema es en un 97% de los casos (te concedo que a veces, contadas veces, tienes razon y si que hay que volver a replantearse la arquitectura escogida) es un problema de que se valora mucho el hard y la plataforma pero se pone poco o ningun cuidado en llevar una auditoria de codigo medio seria con un minimo análisis de rendimiento.

La diferencia entre codigo mal echo en java y codigo mal echo en C es el puto chocolate del loro, el problema es el codigo y de eso hay a patadas.


#3 Sabes de sobra que aunque me dedicase a sexar pollos, la virutilla siempre estaria ahi

[#5 Desactivado]

#4 Sí que se nota mucho (I'm a code man)

Te paso algunas lecturas de rendimiento:

https://brenocon.com/blog/2009/09/dont-mawk-awk-the-fastest-and-most-elegant-big-data-munging-language/

Yo hablo en casos por ejemplo de sistemas que requieren realizar tareas de acumulación de movimientos. Puede haber millones, y necesitas acumular millones, de millones de usuarios, cada uno en su bolsita.

Las gestiones de memoria de uno u otro proceso o la gestión de matrices multidimensionales permiten ahorrar muchísimo código, además de mejorar el rendimiento/desempeño de un programa. Al final son paradigmas que afectan muchísimo al rendimiento, la mantenibillidad, además de la rapidez a la hora de crear prototipos, etc.

[#8 squanchy]

#4 Yo he visto funciones que hacían concatenaciones de cadenas usando el "+=" y que tardaban 20 minutos en dar el resultado, y que tras cambiarlas usando el StringBuilder daban el resultado en pocos segundos. Y lo mismo con SELECTs que hacían join con 5 tablas, y que se optimizaban al usar subselects filtrando esas tablas antes de hacer join (cosa que debería hacer el gestor de bases de datos, pero que no hace). Pero es lo que pasa en el sector, que hay mucho programador mediocre. Lo bueno es que en cuanto resuelves tres problemas así, te hacen la genuflexión al entrar por la puerta de la oficina.

[#12 Desactivado]

#8 una incidencia de límites de crédito de telefonía que afectaba a varios millones de clientes. Obtener los datos eran varias horas incialmente (unas 6-8) para obtener lo mínimo para iniciar la solución, con la idea propuesta en el equipo inicialmente. Luego había que calcular los datos.

Me tire el pisto de que podía sacarme los datos (ya casi calculados) en una hora o así. No se lo creía nadie. Acordamos los datos de salida que tenía que generar y ellos prepararon los scripts para la corrección masiva. Yo mientras prepare mi query con 17 tablas (no estoy de coña). Los datos salieron en cero coma, salían instantáneos al dar al botón - sin putos table-scan y su-Puta-madre - y aquello tardaba como una hora en sacar todos los millones y millones de datos ya calculados.

Nos fuimos a casa pronto, y la query se guardó para la posteridad.

[#3 Desactivado]

#1 La cuestión está en saber si programar en C++ te obliga a deglutir más donuts con topping rosa y virutas de chocolate que si programases en Java

[#6 Desactivado]

#3 Programar e C++ te castiga a una vida sin mujeres.

[#9 Desactivado]

#6 Igual que cualquiera que tenga una pasión en algo.

[#10 squanchy]

#6 El amor no es computable.

[#7 Desactivado]

#1 Los dos (y otros factores) son partes de la ecuación. Programas muy mal hechos, el propio lenguaje de programación, si es interpretado o compilado, la eficiencia del compilador o interpretador (esto generalmente es intrínseco del propio lenguaje porque solo hay una implementación del mismo), la arquitectura del computador, etc. Pero también está la conveniencia de usar un lenguaje sobre otro. En donde se puede ahorrar en el tiempo del desarrollador.

De cualquier manera. Muy buen artículo. Pero no se si confiable. Me sorprende Java.

[#11 Desactivado]

Si se tiene un lenguaje y framework en donde sea muy fácil y rápido desarrollar aplicaciones, se ahorra mucho más. Si se tiene un desarrollador brillante y genial (o un grupo de desarrollo), que hagan aplicaciones estupendas se ahorra mucho más (órdenes de magnitud más).

Pues una persona que tenga a mano una aplicación, que le facilite enormemente su trabajo puede multiplicar su productividad, puede ahorrar mucha más electricidad que hacer el mismo trabajo sin las herramientas adecuadas. En conclusión. El consumo energético del lenguaje no importa tanto como la combinación de desarrolladores brillantes (con el lenguaje que se les venga en gana).

[#13 triturator]

#11 Todo es relativo.

Si tienes un programador superstar que te programa el sistema más eficiente del universo usando corutinas y metaclases de python, pero luego se larga y para meterle mano a eso hay que tener tres doctorados en el MIT, para la empresa es una ruina, y probablemente pierda más dinero en la primera incidencia que tengan, que lo que se pueda ahorrar energéticamente en toda su historia. Y si encima la rutina en cuestión era para enviar cuatro emails automáticos, y va exactamente igual de rápida y gasta igual aunque la escribas en PHP, pues peor me lo pones.

La brillantez está sobrevalorada, mientras que a la mantenibilidad no se le hace ni puto caso.