Bibliotecas paralelas de memoria compartida basadas en tareas en Scientific Computing

En los últimos años, han aparecido varias bibliotecas / proyectos de software que ofrecen una forma u otra de paralelismo de memoria compartida de uso general basado en datos.

La idea principal es que, en lugar de escribir un código explícitamente enhebrado, los programadores implementan sus algoritmos como tareas interdependientes que luego son programadas dinámicamente por un middleware de propósito general en una máquina de memoria compartida.

Ejemplos de tales bibliotecas son:

• QUARK : Originalmente diseñado para la biblioteca de álgebra lineal paralela MAGMA , parece que también se ha utilizado para un método multipolar rápido paralelo .

• Cilk : Originalmente, un proyecto basado en MIT, ahora respaldado por Intel, implementado como extensiones de lenguaje / compilador para C, utilizado en el software de ajedrez informático Cilkchess y experimentalmente en FFTW .

• SMP superscalar : Desarrollado en el Centro de Supercomputación de Barcelona, ​​similar a Cilk en muchos aspectos, basado en #pragmaextensiones.

• StarPU : "codelets" basados ​​en bibliotecas similares que se pueden compilar y programar en varias arquitecturas diferentes, incluidas las GPU.

• Tareas de OpenMP: a partir de la versión 3.0, OpenMP introdujo "tareas" que se pueden programar de forma asincrónica (consulte la Sección 2.7 de la especificación).

• Intel's Threading Building Blocks : utiliza clases de C ++ para crear y ejecutar tareas asincrónicas, consulte la Sección 11 del Tutorial.

• OpenCL : admite paralelismo basado en tareas en núcleos múltiples.

Si bien hay mucha literatura que describe el funcionamiento interno de estas bibliotecas / extensiones de lenguaje y su aplicación a problemas específicos, solo he encontrado muy pocos ejemplos de que se utilicen en la práctica en aplicaciones informáticas científicas.

Así que aquí está la pregunta: ¿Alguien sabe de códigos informáticos científicos que utilicen alguna de estas bibliotecas / extensiones de lenguaje, o similares, para el paralelismo de memoria compartida?

deal.II utiliza los bloques de creación de subprocesos en toda la biblioteca y, en general, estamos razonablemente contentos con él. Hemos analizado algunas alternativas, en particular OpenMP, ya que todo el mundo parece estar usando eso para códigos más simples, pero nos parece que faltan. En particular, OpenMP tiene la gran desventaja de que su modelo de tarea no le permite obtener un identificador para una tarea que inició y, en consecuencia, es difícil acceder al estado de una tarea (por ejemplo, esperar a que termine) o devolver valores de funciones que ejecuta en una tarea separada. OpenMP es principalmente bueno para paralelizar los bucles más internos, pero gana eficiencia paralela al paralelizar los bucles complejos más externos , y OpenMP no es la herramienta para eso, mientras que los TBB son razonablemente buenos para eso.

En mi opinión, estos sistemas han sido relativamente infructuosos debido principalmente a las siguientes razones.

• La perspectiva ingenua de que la computación paralela se trata de paralelizar la computación (por ejemplo, flops) más que exponer la localidad de memoria y eliminar puntos de sincronización. Aunque algunos problemas, como los algoritmos de matriz densa, todavía están limitados por FP, eso solo ocurre después de una cuidadosa consideración del subsistema de memoria y la mayoría de los núcleos computacionales (especialmente en el mundo PDE) son más sensibles a la memoria. Las colas de trabajo tienden a cambiar la localidad de la memoria por un mejor equilibrio ingenuo de fracasos y más operaciones de memoria atómica (debido a la sincronización a través de la cola).
• Confianza en la descomposición excesiva para un equilibrio de carga dinámico a expensas de una fuerte escalabilidad. Las tareas generalmente tienen dependencias de datos superpuestas (valores fantasma). A medida que el tamaño del interior se reduce, la relación fantasma / interior aumenta. Incluso cuando esto no implica trabajo redundante, implica un mayor movimiento de memoria. Se pueden lograr reducciones significativas en los requisitos de ancho de banda de memoria mediante enfoques como la captación previa cooperativa mediante la cual múltiples subprocesos comparten una caché L1 o L2 mediante la captación previa de software para su vecino (que implícitamente mantiene el grupo de subprocesos aproximadamente coherente). Esto es exactamente lo contrario de la descomposición excesiva.
• Rendimiento impredecible, principalmente debido a los problemas relacionados con la memoria anteriores.
• Falta de componentes amigables para la biblioteca. Esto casi se puede resumir como no tener un análogo de un MPI_Commque permita a diferentes bibliotecas realizar operaciones ricas sin colisionar, así como pasar el contexto entre bibliotecas y recuperar los atributos necesarios. La abstracción proporcionada por el "comunicador" es importante para la composición de la biblioteca, independientemente de si se usa memoria compartida o distribuida.