La eficiencia y medio ambiente en la ingeniería
Siempre he admirado el obtener el mismo resultado con menos partes o procedimientos. Es un beneficio para todos. Usé ese concepto en mi forma de diseñar. Estuve determinado a dar mi mayor estima a los ingenieros, y en ingeniería siempre nos esforzamos por obtener mayor eficiencia, definida matemáticamente como “más de salida con menos entrada” — Steve Wozniak, the Woz.
Lo dice un maestro de la optimización, los que conocen algo del diseño de Apple II podrán certificarlo, dicen que es una obra maestra de reducción de puertas lógicas y electrónica en general, aunque muy modular y extensible.
Está muy bien que nos lo recuerde, especialmente a los informáticos.
Las ingenierías más maduras han logrado métodos cuantitativos objetivos que permiten medir y establecer la arquitectura, materiales y seguridad de sus obras. Todas estos parámetros tienden a lograr la eficiencia que menciona Woz. Así en un puente se intenta soportar la mayor cantidad de tráfico con la menor cantidad de material posible y al mismo tiempo maximizando la seguridad. Todos estos contradictorios entre sí, el escenario habitual de una ingeniería, donde sobresalen los ingenieros que logran el mejor balance entre ellos aplicando soluciones imaginativas.
O sea, no es nada fácil ni obvio salvo que se trate de obras bien conocidas donde se introducen pocos cambios (pero estas obras tampoco hacen que sus ingenieros sobresalgan).
Este balance se hace cada vez más complicado, y sus tolerancias más pequeñas a medida que aumenta la sofisticación y que se aumentan las probabilidades de pérdidas de vidas humanas, como lo podrá atestiguar cualquier ingeniero aeronáutico.
¿Qué tiene que ver esto con la ingeniería del software?
En realidad sirve para mostrar las deficiencias que tenemos en nuestra ingeniería. No sólo que todavía no sabemos cómo obtener y usar esos parámetros cuantitativos –no los tenemos todavía, al menos no los mínimos necesarios [1]– sino que no tenemos en cuenta la eficiencia. O las hemos dejado cada vez más olvidadas debidas al “exceso” de recursos computacionales que disponemos –fundamentalmente gracias a los ingenieros electrónicos–.
Ésta, la consideración de la eficiencia, es otro de los aspectos que nos falta para que la ingeniería del software pueda considerarse como madura.
Seguramente muchos ya estarán pensando que el estudio de la complejidad de los algoritmos –por ejemplo que el quicksort es de menor complejidad que el burbuja– sí que son parte de la ingeniería del software. No estoy de acuerdo.
Considero a estos desarrollos de algoritmos cada vez más eficientes parte de la “ciencia de la computación” y no de la ingeniería. Fundamentalmente porque estos algoritmos se estudian y desarrollan por “investigadores” que están preocupados en resolver o mejorar la solución a un problema específica, pero genérico. No están pensados para resolver la necesidad concreta que tiene una empresa o aplicación.
Algo similar pasa con las demás ingenierías. Un ingeniero aeronáutico a la hora de diseñar un avión no se dedica –no podría– a estudiar las propiedades de las diferentes aleaciones de aluminio o titanio, lo que hacen es usar las herramientas –las aleaciones y sus parámetros– que han desarrollado los investigadores –quizás ingenieros– en metalurgia y usarlas para decidir que tipos de aleaciones conviene poner en cada parte del avión tomando en cuenta la resistencia a la tensión, elasticidad, fatiga del metal, etc.
Así, un ingeniero informático simplemente selecciona los algoritmos que los de la “ciencia” han desarrollado. El problema es que tiene que seleccionar cientos o miles de técnicas y algoritmos que puedan solucionar el problema de su cliente o programa.
Y aquí, a este nivel, es donde en general –claro que hay excepciones– no nos preocupamos de esa eficiencia, y no hablo solamente de “complejidad del algoritmo, o tiempos de ejecución, sino también de la simplicidad del propio sistema.
Simplicidad que es cada vez más acuciante en sistemas informáticos cada vez más complejos –generalmente innecesariamente–.
El tema da para hablar mucho, pero para hacerlo corto:
¿Cuántos se dedican a pensar qué es más eficiente/simple –también conocido como KISS– a la hora de elegir frameworks y librerías?
¿cuántos se dedican a pensar seriamente en obtener el mismo resultado con la mínima cantidad de líneas de código?
¿cuántos informáticos a la hora de diseñar programas que se ejecutan en miles de otros ordenadores –los típicos de la “web 2.0″– piensan también en minimizar la complejidad del código de esos programas [2]
No sé porqué siempre he sido un fanático del KISS (Keep It Simple Stupid) y la eficiencia. Lo tuve muy en cuenta a la hora de diseñar y desarrollar Diari de Balears, Última Hora y varios periódicos más hace ya casi 10 años cuando estaba en Atlas Internet. No fue nada mal, nunca tuvo problemas que hubiesen tomado más de pocos minutos para resolverlo y salió al aire todos los días desde entonces –aunque el código sigue siendo exactamente el mismo que se ejecutaba en 1998 y creo que sólo se actualizó el hardware una vez hace ya varios años–.
También fue básicamente lo mismo, simplificar el código de Bulma –aunque agregando bastantes más funcionalidades– allí por 2001 después que la máquina haya quedado casi muerta por un efecto Slashdot. Luego aguantó un par más de efectos Slashdot sin pestañear.
Posteriormente fue exactamente la misma motivación para el cpudyn (hoy ya obsoleto porque el módulo del kernel on demand hace exactamente lo mismo pero desde el propio núcleo, o sea más eficiente todavía) y el WP-Cache.
Con el Menéame me pasó lo mismo, en pleno surgimiento de la moda de plantillas y framewoks MVC.
Recuerdo que fue una decisión bastante difícil y con muchas dudas que tardaron en despejarse (todavía tengo varias).
Por aquella época estábamos trabajando con un becario –Lumen– en un proyecto RoR para la Banca March, y aunque era muy bueno para el desarrollo estándar nos encontramos con dos problemas: desarrollar cosas no contempladas por el framework (en aquel momento, creo que antes de la versión 0.8 todavía no había ni integración “AJAX”) obligaba a trabajar a bajo nivel con muchas dependencias externas y los requerimientos enormes de CPU (que además incrementaban el consumo de RAM por los procesos apache y los tiempos de respuesta).
A partir de esa [poca] experiencia tomé la decisión de hacerlo en PHP –me pareció que tampoco merecía usar Python por lo simple que pensaba hacer el menéame–. Pero luego tenía que tomar la decisión de usar o no plantillas. La alternativa casi obvia hace casi dos años era Smarty y me puse a estudiarlo. De entrada me pareció una aberración, al fin y al cabo era agregar otra capa con otro lenguaje diferente –el Smarty no es tan simple– y tenía la impresión que además iría muy lento, tal como leía en algunos comentarios.
Así hice unas pruebas simples en el ordenador de casa –el mismo que estoy usando ahora– con un 1) HTML, 2) un PHP con cambios de contexto a HTML y sólo usando el gettext() –para el soporte de traducciones– dentro del PHP, otro 3) PHP sin cambios de contexto, es decir todo código PHP con echo/print y un 4) con Smarty. Luego medí la cantidad de páginas por segundo que podía servir y los resultados fueron más o menos (lo hago de memoria):
- 400 páginas por segundo.
- 220 pps
- 280 pps
- 140 pps (Eduardo Diaz, autor de Blogmemes, tiene mejores datos)
De esos resultados estaba claro que no tenía ni los recursos –comenzamos con servidores virtualizados Xen a 20 dólares por mes–, ni el espíritu de aprender Smarty para hacerlo aún más complicado y las la idea fija que no podía ser “tan cerdo” el programa.
Así que opté por la decisión 3), ya que además de ser más eficiente me permitían abrir el fichero y “visualizarlo mentalmente” como si fuese un sólo lenguaje de programación (aunque hay gente que me criticó por el supuesto exceso de usar exclusivamente echo/print). Aunque al principio estaba muy preocupado, el tiempo me ha demostrado que no fue mala opción –funciona en un sólo servidor, nadie se queja que sea lento o demore mucho en cargarse–. Quizás no haya sido la mejor, pero seguro que tampoco está tan alejada de la óptima. Muy eficiente y razonablemente adecuada para el problema.
En fin, batallitas aparte siempre me ha obsesionado el tema de la eficiencia, pero sólo en los últimos años –con más edad, experiencia y mayor perspectiva– me estoy dando cuenta la importancia de este tema en la informática. Sobre todo a partir de conocidos análisis del tiempo exagerado que se tarda en arrancar Linux debido a la extrema ineficiencia de los programas de usuarios y los problemas de consumo y temperatura que están teniendo los grandes centros de datos –y me causó un disgusto enorme cuando los de Digg explicaron su arquitectura y afirmaron: sí, se quejan de que Digg es lento, pero eso es más culpa de las librerías JS y no del backend, como si el tema no fuese con ellos–.
También salían por allí análisis que para mantener el avatar de un usuario en Second Life se consumía más energía que el consumo medio de un brasileño. Aunque no le doy demasiada credibilidad sí que es patente el problema.
Pero la frase de Woz me llamó aún más la atención y noté la contradicción. Mientras que la eficiencia es un tema fundamental en ciencias de la computación, el interés de ella se reduce mucho a niveles de ingeniería (y las discusiones en mi blog demuestran lo difícil que es debatir este tema).
Creo que estamos en el momento en que habrá que pensar en estos temas y que la elección de las herramientas con la máxima simplicidad (aunque no más de lo necesario) empieza a ser fundamental… por dos temas:
Como dice Woz, los ingenieros debemos buscar la mayor eficiencia y simplicidad.
Medio ambientales: el consumo sí es un problema. Con el uso masivo de servidores y páginas dinámicas el coste de energético para generar cada página no ha dejado de aumentar. ¿Cuanto CO2 a la atmósfera no habríamos ahorrado de haber sido más cuidadosos en este tema y no sólo pensar “escala, con 100 servidores lo arreglo”?
Además obtendremos beneficios adicionales: la ingeniería del software se aproximará cada vez más a los estándares y prácticas de las ingenierías más maduras.
Quizás estoy exagerando, pero de todas formas creo que gastar el tiempo en estos temas es mucho más productivo –incluso para el medio ambiente– que salir a la calle para exigir la regulación (siento la insistencia en el tema, pero hay actitudes que no puedo entender con las cosas que no quedan por pensar y solucionar).
[1] Debido fundamentalmente a la complejidad del software comparado con las ingenierías tradicionales, que tratan con materiales sujetos a leyes físicas y por ende su complejidad está limitada por las inalterables leyes físicas (que seguimos usando las ya “obsoletas” de Newton, pero que nos sirven como excelente aproximación incluso para diseñar complejos aviones). Creo que la cantidad de componentes físicos de un avión moderno ronda el millón, mientras que cualquier programa mediano supera esa cantidad de componentes, dicen que un programa de unas 500.000 líneas tienen más de un millón de componentes –perdón, no encuentro los enlaces–.
[2] Es curioso este tema. En general preocupa menos la eficiencia del código que se ejecuta en el cliente “porque total no se ejecuta el servidor y no generará problemas de sobrecarga” cuando en realidad el problema de fondo se multiplica por el número de clientes que lo usan. Si lo midiésemos como haría un ingeniero eléctrico o electrónico se escandalizaría por la cantidad de energía adicional que desperdiciamos, mucho peor que si el código se ejecutase en el o pocos servidor/es.
Tens raó en el que dius, tot i que com tot és discutible.
A mi el que em crida l’atenció el teu comentari:
“¿cuántos se dedican a pensar seriamente en obtener el mismo resultado con la mínima cantidad de líneas de código?”
Moltes vegades resulta fàcil caure en una programació críptica per intentar obtenir un codi que faci el mateix en menys línies o més en menys línies (en aquest darrer cas ja és l’òstia!xD). Penso que quan “un” programa per si mateix es pot permetre el luxe de fer “les guarrades” que vulgui, però quan formes part d’un projecte on hi ha un equip que toca el mateix codi, trobar un estàndard en el nivell “d’encriptació” o simplicitat del codi és complicat.
No us ha passat mai tenir que llegir codi que és sumament críptic i costar-vos molt entendre “el que hi diu”? A vegades val la pena deixar 3 línies més de codi si això facilita la feina “dels que vindran després” (o inclús a tu mateix al cap del temps).
Felicitats per el post.
Comment by iGNASI — Saturday 25/8/2007 @ 13:15
Desde luego, cada vez que programo, me pregunto en cada bloque de código cómo podría ser más eficiente, menos variables, menos memoria, menos tiempo de ejecución. ..Incluso me divierto con ello.
Opino que los programadores de vocación disfrutan con estos temas, ya que siempre es un desafía intelectual para ellos.
Comment by Arturo — Saturday 25/8/2007 @ 13:40
Me cuesta bastante ver que relación tiene KISS con la eficiencia.
Comment by pmarin — Saturday 25/8/2007 @ 14:52
Eficiencia y legibilidad a veces van reñidos.
KISS mata a los dos pájaros de un tiro: mejora tanto la legibilidad, como la eficiencia.
Comment by DZPM — Saturday 25/8/2007 @ 14:55
#3, en primer lugar KISS significa menor número de componentes, y por lo tanto es el primer paso hacia la eficiencia.
Parece que le gente piensa que KISS es hacer programas pocos sofisticados y ponerle la etiqueta de “KISS”.
Todo lo contrario, KISS es hacer que un programa haga lo mismo pero con menos líneas de código, librerías, “layers”, variables, dependencias externas, etc. etc. Hacerlo bien es muy difícil, obliga a pensar bastante y a re-escribir mucho código cuando te das cuentas que lo estás complicando demasiado.
Comment by gallir — Saturday 25/8/2007 @ 16:02
Pues te voy a contar una cosa que creo que te hará saltar de la silla pero a mi esto del Kiss y de la optimización me parece una tontería.
Yo cuando diseño algo solo pienso en una cosa: !!!que sea fácil de mantener!!!
A mi me es más fácil de justificar una ampliación de memoria de un servidor que 40 horas de una persona para ajustar el aspecto de un portal a la nueva imagen de la empresa.
Comment by DN — Saturday 25/8/2007 @ 23:25
> Yo cuando diseño algo solo pienso en una cosa: !!!que sea fácil de mantener!!!
También, y suele pasar que los KISS son más fáciles, además de que hay que buscar un balance ¿no? Sino tendríamos que hacer los sistemas operativos también en Erlang, Python, Lisp, Java (elija usted el que considere más fácil de mantener que C).
Por otro lado, no sé si habrás hecho alguna vez algo que necesite 100 servidores, de todas formas veo que no captas el problema del consumo de los ordenadores (y empeorando mes a mes).
Comment by gallir — Saturday 25/8/2007 @ 23:32
Antes se me olvidaba. Pero yo no estoy muy de acuerdo con lo que dices que el menéame va rápido, y el servidor puede con él. Si, es cierto que va rápido, pero la máquina ya hace tiempo que no puede con él… por eso en las noticias antiguas ya no se guardan muchos datos.
La verdad es que estoy esperando a que el menéame sea tan grande que ya no se pueda usar esta “solución” para ver que es lo que te sacas de la mano.
¿Qué es lo que tienes en mente? Usarás una solución “kiss” (yo que se, mantener 1 tabla con las noticias “vivas” y otra con las ya cerradas, y tener una cache en disco con las cerradas) o algo ya más elaborado con varios servidores de mySQL replicados…
Comment by DN — Saturday 25/8/2007 @ 23:32
#7 Por favor no me trate de usted que me ruborizo
Para el ejemplo que me das, creo que me es más fácil justificar 40 horas de una persona para que programe el sistema operativo en C en vez de en Java si con eso puedo usar un ordenador de 600€ en vez de uno de 600M €
Comment by DN — Saturday 25/8/2007 @ 23:37
#8:
> Antes se me olvidaba. Pero yo no estoy muy de acuerdo con lo que dices que el menéame va rápido, y el servidor puede con él. Si, es cierto que va rápido, pero la máquina ya hace tiempo que no puede con él…
¿eins?
load average: 0.40, 0.42, 0.38
total used free shared buffers cached
Mem: 4049552 3872760 176792 0 96828 2836664
Lo único que se cambió el “summary” de los votos (a los cuatro meses cada voto se elimina después de actualizar la tabla de sumas parciales). Todo lo demás sigue exactamente igual. Pero eso no tiene que ver con rendimiento, sino que hace manejable la bbdd para backups y cambios de estructura si hace falta.
> La verdad es que estoy esperando a que el menéame sea tan grande que ya no se pueda usar esta “solución” para ver que es lo que te sacas de la mano.
Te puedo asegurar que pasarán muchos años antes de la necesidad de cambiar la estructura fundamental. Ahora mismo el servidor puede generar –según el apache benchmark– unas 160 pps para una historia, y unoas 90 para el índice.
> o algo ya más elaborado con varios servidores de mySQL replicados…
Que haya replicación no significa que sea “complicado”, de hecho es muy fácil y tenemos replicación hace más de un año como backup en tiempo real en otro sitio.
Cuando haga falta replicar la BBDD serán pocas línas en el ezdb.php para que coja de un slace si no hay replace, insert o update en el sql (que ya lo detecta ahora).
Comment by gallir — Saturday 25/8/2007 @ 23:39
Me doy cuenta en lo del consumo de energía de los ordenadores, y no hice nada que llegase a los 100 servidores (a los 100 puestos si
pero el consumo energético va como un gasto más… como un gasto más que no importa mucho, porque (por lo menos en mi caso) no repercute en mi departamento.
Eso si… esto lo digo “con la boca pequeña” porque ya entra en juego la conciencia ecologista de cada uno.
En lo del rendimiento de meneame, cuando dije que “se borran datos”, logicamente me estaba refiriendo a la tabla de votos, que debe ser un monstruo, a ver que desaparecían mis votos asumí que era un posible problema de rendimiento al acceder a esa taba, y no tanto un problema de almacenamiento en disco de los backups, sorry.
Y cuando hable de bases de datos mySql no dije “complicado”… dije “elaborado”, es que no sabemos leer hombre
Comment by DN — Sunday 26/8/2007 @ 0:01
> Y cuando hable de bases de datos mySql no dije “complicado”… dije “elaborado”, es que no sabemos leer hombre
No, es que te lo decía por lo de KISS. Presentabas a la replicación (o escalado) como algo contrapuesto al KISS, lo siento si dí esa imagen, pero no es lo que pienso.
Pero sí que hay una diferencia de eficiencia/energética muy grande entre usar 1, 5 ó 10 servidores a usar más de 100.
> Eso si… esto lo digo “con la boca pequeña” porque ya entra en juego la conciencia ecologista de cada uno.
Si todos hiciésemos un poco resolveríamos el problema (que no puede ser resuelto por unos pocos “héroes”).
Comment by gallir — Sunday 26/8/2007 @ 1:09
“Y…, si he escrito esta carta tan larga, ha sido porque no he tenido tiempo de hacerla más corta” (Blas Pascal)
KISS: Si he hecho este programa tan largo es porque no he tenido tiempo, o ganas, de hacerlo más corto.
Comment by cuasi-informatico — Sunday 26/8/2007 @ 2:08
Me has hecho recordar mis comienzos en COBOL (RM).
Mientras todos los demás programadores necesitaban varios cientos y miles de líneas para programar un ABCM, (sencillo), yo lo hacía con unas 80 líneas.
Además era tan legible o más, con esas pocas líneas que con muchas más.
Comment by zahorin — Sunday 26/8/2007 @ 14:10
#13, me alegra mucho que uses el wget para navegar por Internet, aunque no sé si me alegra mucho que sólo leas los titulares y cuentos cortos.
Comment by gallir — Sunday 26/8/2007 @ 15:44
Felicito a Rogelio Bernal RBA,
Hoy salió un buen artículo sobre Corank, en el diario El Pais.
Salutes.
Comment by JA — Sunday 26/8/2007 @ 18:58
> 1) HTML, 2) un PHP con cambios de contexto a HTML y sólo usando el gettext() –para el soporte de traducciones– dentro del PHP, otro 3) PHP sin cambios de contexto, es decir todo código PHP con echo/print y un 4) con Smarty
Supongo que con la opción 2 te estás refiriendo a usar PHP nativo para las plantillas no? http://beer2beer.com/2007/05/30/templates-nativos-en-php/
Realmente creo que no compensa la “pequeña” diferencia en velocidad, con mantener tu código ordenado y separado en capas. Ojo, que no digo que no sea significativa en cuanto a escalabilidad, pero sería un sacrificio más que asumible.
Al fin y al cabo, esas son las cosas que definen la “calidad” en Ing. del Sw. Y sí, KISS debería ser una máxima en esta ingeniería.
Comment by Kr0n — Monday 27/8/2007 @ 8:34
Aunque soy un fanático de la filosofía (sobre todo por la segunda S). Creo que tu visión es la de un profesional experimento y seguro de lo que hace. A pesar de que ciertos frameworks puedan llevar a unos rendimientos bastante penosos y que haya que amortizan las inversiones y cosas así. Opino que para una persona con menos experiencia le soluciona muchos problemas y que a medida que se esta persona va cogiendo experiencia si le es más facil modular su código y hacer todo más reutilizable hasta el punto que le moleste aquellas herramientas que en un principio le facilitaron la vida.
Desde luego que lo ideal es un código ligero, bonito y simple (o fácil de mantener por la persona que lo tiene que mantener) pero no creo que sea el caso del mercado. Basta ver la cantidad de programadores java con struts o net con o que sea que hay por ahí.
En cuanto a smarty tiene su punto aunque tambien es cierto que a veces obliga a construir unas caches eficientes, concepto opuesto a tema del artículo.
Un saludo a todos
Comment by miguel — Monday 27/8/2007 @ 11:19
La eficiencia y medio ambiente en la ingeniería…
¿Si el jefe escribe buenos posts que podemos hacer? Siempre he admirado el obtener el mismo resultado con menos partes o procedimientos. Es un beneficio para todos. Usé ese concepto en mi forma de diseñar. Estuve determinado a dar mi mayor estima a …
Trackback by meneame.net — Monday 27/8/2007 @ 19:57
Acabo de leer http://highscalability.com/mailinator-architecture y no se porque me acabo de acordar de la arquitectura del menéame… Si el menéame es kiss la del mailinator es super-kiss o re-kiss eso si que es ahorrar en recursos.
Comment by DN — Tuesday 28/8/2007 @ 9:37
Yo creo que en realidad en la mayoría de proyectos software (no web 2.0, ni publicaciones de periodicos, si no proyectos con requisitos funcionales complejos) lo que determina la complejidad es el cliente. Todo esto de la eficiencia al nivel que se habla aquí es solo una ínfima parte cuando te metes en proyectos con especificaciones de cientos de páginas, modelados de procesos muy complicados e interacciones entre decenas de sistemas.
Es otro nivel de complejidad en el que se mueven los ingenieros, y cada sistema tiene su propio dominio. Hay ya n ohay KISS que valga, todo depende de lo que haya que hacer.
Comment by Joserra — Tuesday 28/8/2007 @ 11:08
¿Y la Ingeniería Telemática está madura o no está madura?
Comment by Spectrum — Tuesday 28/8/2007 @ 19:02
KISS, desenvolupament i enginyeria del software…
Ricardo Galli ha publicat últimament un parell d’articles molt interessants sobre temes de desenvolupament de software [1][2].
M’agrada la idea que en Ricardo esmenta sobre les conseqüències que pot tenir desenvolupar bé o no un project…
Trackback by Quasi un bloc — Thursday 30/8/2007 @ 0:28
nfcnt s tnr l rdndr n dl td l d, tnr n rdndr * prsn.
Slds!
Comment by Perell — Thursday 6/9/2007 @ 16:01
Ricardo no habia leido tu post.
Tengo que aclarar que los tiempos de smarty pueden ser mejores a los que medi en el articulo que mencionas.
Smarty es una bestia que hay que aprender a dominar, y trabajar con smarty es simple sólo cuando tienes mucha experiencia con este sistema de plantillas, pero mientras aprendes a dominar esa bestia puedes cometer muchos errores, y tener resultados inesperados, como me pasaba antes.
Ahora el problema ya no es tan serio, porque aprendí que hay cosas que no se deben hacer con smarty, pero darse cuenta de eso toma tiempo, y en ese sentido es un costo que hay que evaluar cuando uno toma este tipo de decisiones de diseño.
Usar smarty no es peor ni mejor, es distinto, y para el que tiene experiencia puede ser bueno.
Comment by Eduardo Díaz — Sunday 9/9/2007 @ 3:03