Actualmente Internet necesita tanta energía como la que se consume en Francia y España en un año. Supone un 7% de la energía consumida en todo el mundo.
Esta clase de cuentas absurdas solo pueden clasificarse como engaños:
- 1) Es falso que sea el 7% de la "energía" mundial, sino de la "electricidad" mundial. Hay mucha diferencia.
- 2) El cálculo del 7% se basará en el estudio de Barath Raghavan, es decir, incluye los pcs de casa de la gente + los datacenters + transporte de datos, todo eso como "internet". Como si tu pc no trabajase si en vez de visitar internet jugases a un juego, por ejemplo.
- 3) Internet no emite CO2. Lo emite el mix eléctrico. Es CO2 asociado debido a quemar carbón o gas natural para conseguir electricidad. Lo que habrá que hacer es poner mas renovables. No dejar de visitar webs.
- 4) Suigere contratar electricidad "renovable" pero contratarla no hace que esta sea "renovable" ni ahorra un gramo de CO2. No hace nada. Es la misma electricidad del mix. Simplente te "asignan contablemente" que es "renovable", en un papelito, te ponen "pa ti te contamos como renovable" y al resto le asignan más porcentaje de "no renovable", y en la factura del resto aparece menos renovable. Nada cambia ni se genera menos CO2 ni se pone un puto panel solar más. Ya, si todos pidieramos "renovable" llegaría un momento en que no podrían asignarnos a todos "renovable" y se verían en un lío y subirían el precio de la renovable, y quizás a largo plazo si pondrían un panel solar. Pero es un escenario improbable.
Depende del benchmark que mires, pero cualquier lenguaje compilado y fuertemente tipado deja a un php/python en ridículo en cuanto a velocidad, uso de memoria y, en consecuencia, eficiencia energética.
En el artículo, puntuan a C con un 1, Go un 3.23, 4,45 javascript, php 29 y python 75. Es un índice sintético, obviamente, pero el sentimiento general va por ahí.
Cada vez que alguien pone un programa python o php en producción, Dios mata un gatito.
#7 Ya dije que no quería abrir un flame, pero te empecinas.
Me gusta Go para algunas cosas, pero todas las cosas hay que compararlas con conocimiento de causa, y en igualdad de condiciones.
Si hablas de entornos de producción, como parece, php no estará configurado para ser lo más ineficiente posible, sino al contrario, por lo tanto usará una caché nativa para residir en memoria con una versión precompilada. No voy a decirte que sea más eficiente que Go, pero imagino que ese "29" tiene mucho que ver con las condiciones de los experimentos, cuya configuración no he encontrado en el mismo, y es determinante a la hora de hacer benchmarks.
Si te lees el artículo, verás que en condiciones diversas los mismos lenguajes se comportan distinto:
"But at the same time, when manipulating strings with regular expression, three of the five most energy-efficient languages turn out to be interpreted languages (TypeScript, JavaScript, and PHP),". Manipular y reemplazar cadenas de texto es algo primordial en estos lenguajes, y como ves, son muy eficientes haciéndolo.
El test que han hecho se hizo para optimización en juegos, que es un escenario muy distinto a servir páginas web.
También es más eficiente un entorno de programación estructurada que orientada a objetos, y eso no significa que sea "mejor" usar estructurada para todo.
Como se suele decir en todo flame que se precie, cada herramienta tiene un contexto y sirve para un propósito, y es algo que te muestran en el propio artículo que enlazas, como conclusión:
“Although the most energy efficient language in each benchmark is almost always the fastest one, the fact is that there is no language which is consistently better than the others,” the researchers conclude. “The situation on which a language is going to be used is a core aspect to determine if that language is the most energy-efficient option.”
Espero que mi comentario haya contribuido a relajar un poco tu dogmatismo, y a mirar con una mente más abierta la realidad
Edito: Como nota adicional, php tiene todas sus funciones core pre-programadas en c, lo cuál hace que sea un híbrido muy interesante a la hora de ser rápido y eficiente energéticamente, siempre que lo uses correctamente.
#13 Pues si no quieres hacer un flame, no lo hagas.
He programado en PHP en los últimos 10 años y todavía hoy tengo algún repo que mantener.
No me hables de dogmatismo, que lo mismo te digo blanco que negro. Hay que tener más apertura cuando se escucha a los demás.
En serio, la comparación entre PHP y un compilado en cuanto a rendimiento no se aguanta. He visto facturas de AWS caer a la cuarta parte cambiando servidores de PHP a go.
Pero el mismo consejo valdría para PHP, Ruby o Python.
#15 Entre el blanco y el negro, existe una escala de grises.
Yo he visto facturas de servidores multiplicarse por diez al pasar a microservicios, y la factura de coste de desarrollo multiplicarse por 5. Lo primero es contra-intuitivo, y denota que se han hecho muchas cosas mal, por eso no lo uso como ejemplo válido normalmente, porque asumo que una particularidad no puede elevarse a norma.
En el caso que comentas de AWS, es perfectamente factible, como es perfectamente factible lo contrario, si añades otros costes asociados. Puede ser un indicador de mejora usando go, o un indicador de que lo que se hacía con php no estaba optimizado.
Llevo suficiente tiempo en el mercado como para comprender que un simple cambio de lenguaje no es una solución mágica, y que hay que valorar las cosas en un contexto más amplio para tener una opinión realista ( bajo el coste de servidores, pero aumento el coste de desarrollo, o el tiempo de desarrollo, o la complejidad de encontrar personal, etc etc ).
Ya he comentado que go me gusta para algunas cosas, tiene unos puntos fuertes que no son despreciables, y de hecho lo utilizo para sacarle partido a esos puntos fuertes. Pero el paradigma de cambio todo php a go y salgo ganando, es una decisión estructural que afecta a más ámbitos que el mero desempeño concreto de algunos algoritmos, y es lo que te discuto.
He visto equipos enteros perderse en la niebla porque pensaban que un simple cambio de paradigma les iba a salvar el salto de su propia incompetencia, y el resultado ser mucho peor, porque lo que fallaba de base es que no sabían utilizar las herramientas que tenían, y mucho menos las nuevas.
Misma película para SQL / NoSQL, Nginx vs Apache y un largo etcétera, por eso te prevengo de la postura evangélica, porque tengo buen corazón. Eso no quita para que me alegre de que estés contento con Go, y que le saques todo el partido que puedas.
Evidentemente cualquier lenguaje compilado va a funcionar más rápido que cualquier interpretado, pero hay que sopesar si te interesa entrar en el monte con el Ferrari.
En cualquier caso, siguen siendo algoritmos genéricos, que nos dan una visión más transversal, pero no específicamente enfocada a un uso determinado, por un lado es bueno, porque es más objetivo, pero por otro es menos adecuado a una comparación en los entornos típicos. Es mucho más pesado hacer un test de cada lenguaje en su "entorno natural", junto con el resto, pero nos daría una idea más cercana de lo que se quiere ver, si lo que se quiere ver es la velocidad de cada lenguaje en su propósito "normal".
Quiero decir, si comparas la velocidad de dos coches en carretera, te saldrán mejor parados los coches más habituados a ese entorno, pero te dará una idea falaz de la velocidad de esos mismos vehículos en un entorno agreste.
Creo que me extiendo demasiado, lo que quiero decir se ve a la legua.
Edito: Añado el C&P que le hice acosmonauta con la conclusión del propio artículo que me enlazaba:
“Although the most energy efficient language in each benchmark is almost always the fastest one, the fact is that there is no language which is consistently better than the others,” the researchers conclude. “The situation on which a language is going to be used is a core aspect to determine if that language is the most energy-efficient option.”
Comentarios
Os ahorro el clic https://www.websitecarbon.com/website/meneame-net/
#3 Tengo la sensación de que no me he ahorrado el clic.
¿Cuantos viajes ahorran la videoconferencias?
#9 Súmale cuánto ahorro energético se tiene con la gente teletrabajando, y lo mismo flipamos con las cuentas.
#14 esa es otra
Esta clase de cuentas absurdas solo pueden clasificarse como engaños:
- 1) Es falso que sea el 7% de la "energía" mundial, sino de la "electricidad" mundial. Hay mucha diferencia.
- 2) El cálculo del 7% se basará en el estudio de Barath Raghavan, es decir, incluye los pcs de casa de la gente + los datacenters + transporte de datos, todo eso como "internet". Como si tu pc no trabajase si en vez de visitar internet jugases a un juego, por ejemplo.
- 3) Internet no emite CO2. Lo emite el mix eléctrico. Es CO2 asociado debido a quemar carbón o gas natural para conseguir electricidad. Lo que habrá que hacer es poner mas renovables. No dejar de visitar webs.
- 4) Suigere contratar electricidad "renovable" pero contratarla no hace que esta sea "renovable" ni ahorra un gramo de CO2. No hace nada. Es la misma electricidad del mix. Simplente te "asignan contablemente" que es "renovable", en un papelito, te ponen "pa ti te contamos como renovable" y al resto le asignan más porcentaje de "no renovable", y en la factura del resto aparece menos renovable. Nada cambia ni se genera menos CO2 ni se pone un puto panel solar más. Ya, si todos pidieramos "renovable" llegaría un momento en que no podrían asignarnos a todos "renovable" y se verían en un lío y subirían el precio de la renovable, y quizás a largo plazo si pondrían un panel solar. Pero es un escenario improbable.
Si es Pornhub, probablemente el doble
#1 y mucho humo
¿Preparando el terreno para limitar el acceso a Internet en nombre de la ecología?
#10 Para cobrar más. Siempre va de, oh, casualidad, más dinero.
Depende de si está programada en php y javascript o en lenguajes de verdad como go, o incluso es html estático.
#2 "en lenguajes de verdad como go"
No quiero iniciar un flame, pero madre mía...
#6 https://thenewstack.io/which-programming-languages-use-the-least-electricity/
Depende del benchmark que mires, pero cualquier lenguaje compilado y fuertemente tipado deja a un php/python en ridículo en cuanto a velocidad, uso de memoria y, en consecuencia, eficiencia energética.
En el artículo, puntuan a C con un 1, Go un 3.23, 4,45 javascript, php 29 y python 75. Es un índice sintético, obviamente, pero el sentimiento general va por ahí.
Cada vez que alguien pone un programa python o php en producción, Dios mata un gatito.
#7 Ya dije que no quería abrir un flame, pero te empecinas.
Me gusta Go para algunas cosas, pero todas las cosas hay que compararlas con conocimiento de causa, y en igualdad de condiciones.
Si hablas de entornos de producción, como parece, php no estará configurado para ser lo más ineficiente posible, sino al contrario, por lo tanto usará una caché nativa para residir en memoria con una versión precompilada. No voy a decirte que sea más eficiente que Go, pero imagino que ese "29" tiene mucho que ver con las condiciones de los experimentos, cuya configuración no he encontrado en el mismo, y es determinante a la hora de hacer benchmarks.
Si te lees el artículo, verás que en condiciones diversas los mismos lenguajes se comportan distinto:
"But at the same time, when manipulating strings with regular expression, three of the five most energy-efficient languages turn out to be interpreted languages (TypeScript, JavaScript, and PHP),". Manipular y reemplazar cadenas de texto es algo primordial en estos lenguajes, y como ves, son muy eficientes haciéndolo.
El test que han hecho se hizo para optimización en juegos, que es un escenario muy distinto a servir páginas web.
También es más eficiente un entorno de programación estructurada que orientada a objetos, y eso no significa que sea "mejor" usar estructurada para todo.
Como se suele decir en todo flame que se precie, cada herramienta tiene un contexto y sirve para un propósito, y es algo que te muestran en el propio artículo que enlazas, como conclusión:
“Although the most energy efficient language in each benchmark is almost always the fastest one, the fact is that there is no language which is consistently better than the others,” the researchers conclude. “The situation on which a language is going to be used is a core aspect to determine if that language is the most energy-efficient option.”
Espero que mi comentario haya contribuido a relajar un poco tu dogmatismo, y a mirar con una mente más abierta la realidad
Edito: Como nota adicional, php tiene todas sus funciones core pre-programadas en c, lo cuál hace que sea un híbrido muy interesante a la hora de ser rápido y eficiente energéticamente, siempre que lo uses correctamente.
#13 Pues si no quieres hacer un flame, no lo hagas.
He programado en PHP en los últimos 10 años y todavía hoy tengo algún repo que mantener.
No me hables de dogmatismo, que lo mismo te digo blanco que negro. Hay que tener más apertura cuando se escucha a los demás.
En serio, la comparación entre PHP y un compilado en cuanto a rendimiento no se aguanta. He visto facturas de AWS caer a la cuarta parte cambiando servidores de PHP a go.
Pero el mismo consejo valdría para PHP, Ruby o Python.
#15 Entre el blanco y el negro, existe una escala de grises.
Yo he visto facturas de servidores multiplicarse por diez al pasar a microservicios, y la factura de coste de desarrollo multiplicarse por 5. Lo primero es contra-intuitivo, y denota que se han hecho muchas cosas mal, por eso no lo uso como ejemplo válido normalmente, porque asumo que una particularidad no puede elevarse a norma.
En el caso que comentas de AWS, es perfectamente factible, como es perfectamente factible lo contrario, si añades otros costes asociados. Puede ser un indicador de mejora usando go, o un indicador de que lo que se hacía con php no estaba optimizado.
Llevo suficiente tiempo en el mercado como para comprender que un simple cambio de lenguaje no es una solución mágica, y que hay que valorar las cosas en un contexto más amplio para tener una opinión realista ( bajo el coste de servidores, pero aumento el coste de desarrollo, o el tiempo de desarrollo, o la complejidad de encontrar personal, etc etc ).
Ya he comentado que go me gusta para algunas cosas, tiene unos puntos fuertes que no son despreciables, y de hecho lo utilizo para sacarle partido a esos puntos fuertes. Pero el paradigma de cambio todo php a go y salgo ganando, es una decisión estructural que afecta a más ámbitos que el mero desempeño concreto de algunos algoritmos, y es lo que te discuto.
He visto equipos enteros perderse en la niebla porque pensaban que un simple cambio de paradigma les iba a salvar el salto de su propia incompetencia, y el resultado ser mucho peor, porque lo que fallaba de base es que no sabían utilizar las herramientas que tenían, y mucho menos las nuevas.
Misma película para SQL / NoSQL, Nginx vs Apache y un largo etcétera, por eso te prevengo de la postura evangélica, porque tengo buen corazón. Eso no quita para que me alegre de que estés contento con Go, y que le saques todo el partido que puedas.
Evidentemente cualquier lenguaje compilado va a funcionar más rápido que cualquier interpretado, pero hay que sopesar si te interesa entrar en el monte con el Ferrari.
#13 "El test que han hecho se hizo para optimización en juegos, que es un escenario muy distinto a servir páginas web."
https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game
Cuando dice "Juegos" entiendo que se refiere a videojuegos. Nada mas lejos de la realidad.
¿Si a usted le parece esto un videojuego?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/revcomp-php-3.html
#19 Cierto, ahí he patinado.
cosmonauta con la conclusión del propio artículo que me enlazaba:
En cualquier caso, siguen siendo algoritmos genéricos, que nos dan una visión más transversal, pero no específicamente enfocada a un uso determinado, por un lado es bueno, porque es más objetivo, pero por otro es menos adecuado a una comparación en los entornos típicos. Es mucho más pesado hacer un test de cada lenguaje en su "entorno natural", junto con el resto, pero nos daría una idea más cercana de lo que se quiere ver, si lo que se quiere ver es la velocidad de cada lenguaje en su propósito "normal".
Quiero decir, si comparas la velocidad de dos coches en carretera, te saldrán mejor parados los coches más habituados a ese entorno, pero te dará una idea falaz de la velocidad de esos mismos vehículos en un entorno agreste.
Creo que me extiendo demasiado, lo que quiero decir se ve a la legua.
Edito: Añado el C&P que le hice a
“Although the most energy efficient language in each benchmark is almost always the fastest one, the fact is that there is no language which is consistently better than the others,” the researchers conclude. “The situation on which a language is going to be used is a core aspect to determine if that language is the most energy-efficient option.”
Madre mía..... cuanto daño ha hecho el porno.
#12 Si, es muy dirty https://www.websitecarbon.com/website/pornhub-com/