5 de junio de 2007

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.

3 comentarios:

  1. Es que se empeñan en llevar al multiproceso cosas que quizás no se pueden llevar... en cualquier caso el tema de la programación multihilo en mi opinión tiene muchos fantasmas.

    Al igual que un software mal planteado es un infierno de la misma forma lo es un software mal planteado multihilo.

    Del software que he creado con multihilo nunca he tenido problemas mayores que los generados por una mala planificación.

    Cierto es que es más complejo diseñar un software multihilo pero es que en el mundo de la informática (como en casi todos) las cosas avanzan e implican que para poder sacar algo adelante hay que tener mejor organización.

    ResponderEliminar
  2. Anónimo12:21 a. m.

    La programación en hilos tiene su campo, no se puede aplicar a cualquier algoritmo ni a cualquier paradigma de programación. En el tratamiento vectorial y simulación de arquitecturas SIMD puede ayudar mucho, pero en el software de gestión del día a día tal vez no sea tan útil.

    No estoy de acuerdo con que "la programación en paralelo no es asequible a la mente humana". Seguro que tú has programado. ¿Siempre has pensado de forma secuencial? ¿Siempre siempre? Sí, el resultado es secuencial, pero al pensar en la solución ¿nunca has pensado que en paralelo lo harías de forma más eficiente? Te doy un ejemplo: la exploración de árboles binarios es un perfecto campo de aplicación del paralelismo, y siempre (con arquitecturas i386, etc.) nos hemos visto obligados a la secuencialidad. Es más complejo, pero creo que podemos pensar en paralelo. Es más, la programación distribuida no es nueva.

    Interesante tema. Un saludo.

    ResponderEliminar
  3. Podemos pensar en paralelo...pero generalmente en casos muy determinados como el que dices. Los multicore implican aplicar la programación multihilo a prácticamente todo...y si hay una parte del programa que no puedes paralelizar...pues aun así debes plantearte como paralelizarlo. Ahí es donde yo tengo serias dudas, programes como programes, diseñes como diseñes, de que acabará haciéndose un infierno inmantenible.

    ResponderEliminar