400430406. Reglas para la Programación Paralela para Núcleo Múltiple

Programar para procesadores de núcleo múltiple presenta nuevos retos. Aquí van ocho reglas para la programación de núcleo múltiple que nos ayudarán a tener éxito en la tarea:

((Es necesario enfocar todos los problemas buscando el paralelismo. Entender dónde está el paralelismo, y organizar la forma de pensar))
-# Pensar en paralelo. Enfocar todos los problemas buscando el paralelismo. Entender dónde está el paralelismo, y organizar la forma de pensar para expresarlo. Decidir el mejor enfoque paralelo antes de tomar otras decisiones de diseño o implementación. Aprender a “Pensar en Paralelo”
-# Programar usando la abstracción. Concentrarse en escribir código para expresar el paralelismo, pero evitar escribir código para gestionar hilos o núcleos de procesador. Las bibliotecas, OpenMP, e Intel Threading Building Blocks son todos ejemplos del uso de abstracciones. No usar hilos nativos en bruto (pthreads, Windows threads, Boost threads, y cosas por el estilo). Los hilos y MPI son los lenguajes de ensamblaje para el paralelismo. Ofrecen máxima flexibilidad, pero requieren demasiado tiempo para escribirlos, depurarlos y mantenerlos. Nuestra programación debería tener el suficiente nivel como para que nuestro código sea sobre nuestro problema y no sobre la gestión de los hilos o de los núcleos.
-# Programar pensando en tareas (cometidos), y no en hilos (núcleos). Dejar el mapeado de tareas a hilos o a núcleos de procesador como una operación claramente separada en nuestro programa, preferentemente como una abstracción en uso, que se encarga de controlar la gestión de hilos/núcleo. Crear una abundancia de tareas en el programa, o una tarea que pueda ser extendida por los núcleos del procesador automáticamente (como por ejemplo un bucle OpenMP). Al crear tareas, se pueden crear cuantas se puedan sin tener que preocuparse de la suscripción excesiva.
-# Diseñar con la opción de desconectar la concurrencia. Para hacer más sencillo el depurado, crear programas que puedan funcionar sin concurrencia. De esta forma, mientras se depura, es posible ejecutar programas primero con concurrencia y después sin ella para ver si las dos ejecuciones fallan o no. El depurado de cuestiones comunes es más sencillo cuando el programa no está funcionando de manera concurrente, porque resulta más familiar y está mejor soportado por las herramientas actuales. Saber que algo falla sólo cuando se ejecuta de forma concurrente indica el tipo de fallo técnico que se busca. Si se ignora esta regla y no se puede obligar al programa a funcionar en sólo un hilo, se pasará demasiado tiempo depurando. Puesto que se quiere tener la capacidad de ejecutar en un solo hilo específicamente para el depurado, no hay necesidad de que sea eficiente. Sólo hay que evitar crear programas paralelos que necesiten de la concurrencia para funcionar correctamente, como muchos modelos de productor-consumidor. Los programas MPI a menudo violan esta regla, que es parte del motivo por el que los programas MPI pueden ser problemáticos de implementar y de depurar.
-# Evitar el uso de bloqueos. Sencillamente hay que decir “no” a los bloqueos. Los bloqueos ralentizan los programas, reducen su escalabilidad, y son fuente de fallos técnicos en los programas paralelos. Hacer de la sincronización implícita la solución al programa. Cuando se necesite aún la sincronización explicita, hay que usar operaciones atómicas. Usar bloqueos sólo como el último recurso. Hacer todo lo posible por diseñar que la necesidad de los bloqueos quede totalmente fuera del programa.
-# Usar herramientas y bibliotecas diseñadas para ayudar con la concurrencia. No “aguantar” con herramientas viejas. Ser críticos con el soporte de herramientas en lo que respecta a cómo presenta e interactúa con el paralelismo. La mayoría de las herramientas no están todavía preparadas para el paralelismo. Buscar bibliotecas seguras en los hilos – idealmente las que están diseñadas para utilizar ellas mismas el paralelismo.
-# Utilizar asignadores escalables de memoria . Los programas hilados necesitan usar asignadores escalables de memoria. Período. Hay una serie de soluciones y me da la impresión de que todas ellas son mejores que malloc(). El uso de asignadores escalables de memoria acelera las aplicaciones al eliminar los cuellos de botella globales, al reutilizar la memoria dentro de los hilos para usar mejor los caché y al dividir de la forma adecuada para evitar compartir línea de caché.
-# Diseñar para escalar a través de mayores cargas de trabajo. La cantidad de trabajo que el programa necesita gestionar aumenta con el tiempo. Hay que planificar para ello. Si se diseña con la escalada en mente, el programa gestionará más trabajo según aumenta el número de núcleos de procesador. Cada año, pedimos que nuestros ordenadores hagan cada vez más cosas. Los diseños deberían favorecer el uso de aumentos en el paralelismo para ofrecer ventajas en la gestión de mayores cantidades de trabajo en el futuro.

((Hay que decir “no” a los bloqueos. Los bloqueos ralentizan los programas, reducen su escalabilidad, y son fuente de fallos técnicos en los programas paralelos))

He escrito estas normas haciendo en todas partes una mención explícita al hilado. Sólo la regla #7 está relacionada específicamente con el hilado. El hilado no es la única manera de sacar provecho al núcleo múltiple. Con frecuencia se ejecutan múltiples programas o múltiples procesos, especialmente en las aplicaciones del servidor.

Estas reglas funcionan bien para sacarle provecho al núcleo múltiple. Algunas incrementarán su importancia en los próximos 10 años, según aumenta el número de núcleos de procesadores y según vemos un incremento en la diversidad de núcleos. La llegada de procesadores heterogéneos y NUMA, por ejemplo, hace que la regla #3 sea cada vez más importante.

Conviene entender y apreciar las ocho reglas. Me encantaría oír cualquier comentario que el lector quiera hacer sobre estas reglas o el paralelismo en general.