¡La broma ha terminado!
¡La broma ha terminado...! es la frase que su agente de bolsa le dijo a Groucho Marx por teléfono minutos antes de suicidarse tras el crack del 29. La frase vuelve a estar de moda ahora que la crisis es una realidad de nuevo. Que nadie piense que me he vuelto loco y ahora mi blog va a tratar de economía. Hoy vengo a hablar de otra crisis que nos toca más directamente a los programadores: el fin de la Ley de Moore tal y como la conocíamos hasta ahora. No es que los microprocesadores vayan a dejar de doblar su potencia cada año y medio más o menos, sino que este incremento de velocidad va a dejar de ser transparente para los desarrolladores de software. Los desarrolladores tenemos nuestra propia crisis técnica. El crecimiento de velocidad va a venir de las mejoras en paralelización de los microprocesadores, no de las mejoras de velocidad de proceso en sí. Los procesadores serán capaces de hacer más cosas a la vez, pero no serán capaces de hacerlas más rápido. La potencia se define como trabajo por unidad de tiempo. Hacer más trabajo a la vez es una manera tan buena de mejorar la potencia como hacer el trabajo más rápido.
A la economía se le acabo la confianza, a los desarrolladores se nos acabo el poder confiar en que nuestro software se ejecutará más rápido con solo cambiar de máquina. Igual que ha ocurrido con la economía hay voces que ya nos llevan hablando de los posibles problemas desde hace tiempo. Esta es una realidad que ha mordido ya a algunos, con paradojas como que incrementar el número de procesadores de su servidor de bases de datos haga que las consultas sean más lentas. Pero la cosa no va a quedar aquí. Si a futuro queremos que nuestro software siga beneficiándose de las mejoras de rendimiento de los procesadores en el futuro debemos empezar a cambiar ya nuestra manera de desarrollar.
No tengo claro aun cual va a ser la magnitud del impacto, igual que ocurre con la crisis económica se están tomando infinidad de medidas para tratar de minimizar el impacto de esta crisis. Hay cientos de equipos de desarrollo trabajando a bajo nivel para dotarnos de abstricciones que puedan evitar que los desarrolladores de negocio tengan que preocuparse por estas cuestiones. En cualquier caso el mundo del desarrollo va a ser más complejo, no importa como de buenas sean las abstracciones.
Lo que está claro es que los desarrolladores seremos quienes de un modo u otro tendremos que empezar a pensar en paralelización. Y la paralelización no es un problema trivial. Es un problema que separa el trigo de la paja, al buen desarrollador (desde programadores a arquitectos) del desarrollador en la media. Cierto es que los desarrolladores de herramientas de desarrollo nos van a tratar de facilitar la vida construyendo herramientas y abstracciones que faciliten la adopción de este nuevo paradigma, pero toda abstracción no trivial fuga detalles, como reza la ley enunciada por Joel Spolky.
Se están construyendo nuevas abstracciones, como las Parallels Extensions de .Net, la Parallel Patterns Library de C++ y muchas otras, que van ha permitir que los desarrolladores de negocio se centren en resolver los problemas que realmente importan, los del negocios. Pero mucho me temo que estas abstracciones nos van a plantear problemas: exigen cambios de diseño y tendrán, como todas las abstracciones, fugas y en este caso las fugas serán fugas de complejidad elevada. En cualquier caso el cambio de paradigma nos exige una nueva manera de pensar. Los hilos son una abstracción demasiado débil. Tenemos que empezar a pensar en tareas no en hilos. Y en relaciones entre esas tareas y su concurrencia en lugar de en sincronización de hilos. Es la única manera de abordar la complejidad que la programación concurrente aplicada a un amplio espectro de aplicaciones impone.
Dicen que en Chino crisis y oportunidad se expresa con la misma palabra. A la vista de la silenciosa revolución que está ocurriendo una nueva raza de desarrolladores va a surgir: aquellos que dominen la programación concurrente. En mis primeros tiempos como desarrollador de C/C++, había una casta especial de desarrolladores, mejor pagados y más considerados que los demás, esa casta estaba formada por los desarrolladores de C/C++ que además dominaban las optimizaciones en esamblador del código. Llego un momento en que la Ley de Moore y la mejora en los compiladores hizo innecesarios a estos desarrolladores, pero durante mucho tiempo, contar con uno de estos en tu equipo fue algo clave. Creo que esto va ha ocurrir de nuevo.
De aquí se deriva mi propósito en el ámbito técnico para el año que viene: actualizar mis conocimientos sobre programación multihilo a la programación concurrente. Si alguien más se quiere unir a este propósito le invito a empaparse el número de Octubre de MSDN Magazine y a visitar el centro de desarrollo de Parallel Computing de Microsoft.