Compilador más "multicore"

Intel acaba de publicar una nueva versión de su compilador, y esta versión trae herramientas que ayudan a programar para multicore, lo que Intel llama Intel Threading Building Blocks

Dos de las herramientas son un detector de bloqueos y pausas en programas multihilo, y un analizador de rendimiento en programas multicore. La primera me intriga: Es una forma de decir que la programación multihilo es muy compleja y que el cerebro de los programadores va a tener que aguantar toda esa complejidad. Es decir, que Intel sigue sin tener una solución para que el software escale mágicamente, lo cual no es sorprendente ni vergonzoso para ellos. A mi, francamente, un detector de bloqueos que tenga que utilizarse a diario me parece tan absurdo como, por ejemplo, un detector de pausas en el pipeline del procesador: Sin duda es útil para microoptimización y casos concretos, pero no es de lo que la mayoría de los programadores debería preocuparse a diario. Y pongo ese ejemplo porque el mundo multicore tiene sus similitudes con los procesadores cuyo rendimiento sufre demasiado con las pausas, como los P4. ¿Se imaginan un procesador como el P4 pero a lo bestia, que necesitara un extremo cuidado para no hacer pausas en el pipeline? ¿Se imaginan tener que echar un ojo al ensamblador para ver qué ha generado el compilador? Pues bien, usar ese procesador sería una gloria comparado con el multicore, porque al fin y al cabo es el compilador el que genera el código optimizado para no crear pausas en el pipeline; mientras que un compilador no te va a solucionar el problema de tener que usar varios cores simultaneamente, tienes que hacertelo tú. Y miren dónde se ha quedado el P4. O el Itanium.

En cierto modo es volver al mundo del ensamblador. Bueno, la analogía correcta sería decir que volvemos a la complejidad de los días de los programas en ensamblador, cuando el programador pasaba más tiempo intentando encontrar los fallos (eso no ha cambiado mucho hoy, pero antes era peor, hoy en día los fallos se buscan en programas con decenas miles de líneas, antes los fallos te abrumaban con unos cientos) o buscando un rendimiento decente que programando funcionalidad. Volvemos a ese mundo, porque la programación en paralelo no es asequible a la mente humana, por muchos adornos que le pongan, igual que no lo es la programación de una suite ofimática en ensamblador, y la única manera de afrontar esa complejidad es que alguien, ya sea el compilador, las capas más bajas del sistema operativo, la orientación a objetos, una mezcla de todo, sea quien sea, resuelva al programador el problema.