¿Son los procesadores multicore el futuro? Quizás no...

(Advertencia a los lectores del Planeta Augcyl: el enlace que pone en el planet es incorrecto este es el bueno)
Como muchos se habrán dado cuenta, los mutlicore se han convertido de la noche a la mañana en el ojo del huracán. La multiprogramación se está volviendo -ya se ha vuelto, para los más avispados- el paradigma central en el que centrarse a la hora de diseñar software, no solo en el mundo de los servidores (donde ya se utiliza desde hace mucho tiempo) sino en entornos de escritorio, que son utilizados hasta por los programadores que programan software para servidores. Los expertos de Intel recomendaron a los programadores en el último Foro para Desarrolladores de Intel que para aprovechar el máximo rendimiento en los futuros procesadores multicore, empiezen a diseñar sus programas pensando desde el principio en la multiprogramación: algoritmos, estructuras de datos...que no se lo planteen como una "mejora" sino como eje troncal, y que se familiarizen con las herramientas de depuración de bloqueos de Intel y con siglas como OpenMP (del que por cierto, se acaba de dar soporte en el recien salido GCC 4.2).

Sin embargo la multiprogramación sigue siendo jodidamente dura. Para la mayoría de los programadores, la multiprogramación resulta aproximadamente igual de asequible que los discursos de HazteOir.org. Nadie sabe como hacer que el software escale mágicamente a unas cuantas decenas de CPUs y que su potencia sea utilizada en su totalidad del mismo modo que un bucle cerrado haciendo nada -o Evolution- consume el 100% de una sola CPU (tambien el 100% de la memoria, en el caso de Evolution). Existe un amplio consenso, especialmente en el mundo del hardware, sobre que que el mundo del software carece de un modelo para explotar las CPUs multicore, y que las CPUs multicore han venido para quedarse y que esto va a obligar a que se produzca una revolución en el software para descubrir cual es ese modelo. Creen que los fabricantes de CPUs llevan muchos años aumentando el rendimiento de los ordenadores, y que le toca al software partirse el cráneo.

¿Ocurrirá tal mejora? De venir, idealmente la mejora tendría que venir del desconocido y oscuro pero sin embargo amplio terreno que existe desde el nivel del lenguaje de programación al de los transistores de la CPU. Sin embargo existe un grupo de gente que simplemente piensa que esa mejora no se producirá, y que el software jamás podrá utilizar eficientemente tantos cores. De esta opinión parece ser Robert O'Callahan, uno de los mejores hackers de Firefox, especializado en temas gráficos, y que en un post anterior dijo que no merecía la pena centrarse en utilizar mucho threading en el renderizado de Gecko porque la complejidad que generaría no merecería la pena. En su última entrada de blog ha escrito unas palabras que por su profundidad y claridad creo que merecen una profunda reflexión:

"There was a great deal of discussion of parallel programming, now that we have entered the multicore world. More than one person opined that multicore is a mistake we will live to regret --- "we don't know what the right way is to use the transistors, but multicore is definitely wrong". There was general agreement that the state of parallel programming models, languages and tools remains pathetic for general-purpose single-user programs and no breakthrough should be expected. My position is that for regular desktop software to scale to 32 cores by 2011 (as roadmaps predict) we'd have to rewrite everything above the kernel, starting today, using some parallel programming model that doesn't suck. Since that model doesn't exist, it's already too late. Probably we will scale out to a handful of cores, with some opportunistic task or data parallelism, and then hit Amdahl's law, hard. It is probably therefore more fruitful to focus on new kinds of applications which we think we have reasonable ideas for parallelizing."