Embed Size (px)
Citation preview
Modelos y Lenguajes para Computación Paralela
Trabajo sobre el documento de David B. Skillicorn y Domenico Talia “Models and languages for parallel computation”, ACM Computing
Surveys, Vol 3, No 2, Junio 1.988
Septiembre - 2006
Ricardo Montañana GómezIngeniero Informático
Profesor de Enseñanza Secundaria
Contenido.
1. Modelos y sus propiedades.
2. Descripción de modelos.
3. Clasificación de modelos.
4. Conclusión.
1 Modelos y sus propiedadesDefinición: “Un modelo de computación paralela
es una máquina virtual que provee ciertas operaciones a nivel de programación y que requiere que estas operaciones se implementen en cada una de las arquitecturas subyacentes.”
Propiedades:1. Fácil de Programar.
2. Metodología de desarrollo de software.
3. Independiente de la arquitectura.
4. Fácil de comprender.
5. Rendimiento garantizado.
6. Medidas de coste.
1.1. Fácil de Programar
El modelo debe permitir al programador abstraerse de las características físicas del entorno de ejecución. Lo que implica que el modelo debe ocultar lo siguiente:
● Descomposición.● Asignación a procesadores.● Comunicación.● Sincronización (interbloqueos)..
1.2. Metodología de desarrollo de software.
Se requieren unos fundamentos semánticos firmes para conciliar la información proporcionada por el programador sobre la estructura semántica del programa y la estructura requerida para la ejecución del mismo.
1.3. Independiente de la arquitectura.
El modelo debe ser independiente de la arquitectura en la que se ejecute, de esta forma los programas realizados sobre ella pueden ser migrados sin tener que ser re-desarrollados ni modificados de manera significativa.
1.4. Fácil de comprender.
El modelo debe ser fácil de comprender, lo que implica que también será fácil de enseñar, ya que de otro modo será imposible formar a los programadores actuales para su uso.
Si los modelos de programación paralela son capaces de ocultar la complejidad y ofrecer una interfaz sencilla, tienen una oportunidad mayor de ser aceptados y utilizados.
1.5. Rendimiento garantizado
Un modelo debería tener un rendimiento garantizado sobre una variedad de arquitecturas paralelas.
Esto no significa que las implementaciones deban extraer todo el rendimiento disponible en cada una de las arquitecturas.
Sobre todo si ese incremento en el rendimiento sobre una arquitectura requiere un coste de desarrollo y mantenimiento considerables.
1.6. Medidas de coste.
Cualquier diseño de programas está condicionado más o menos explícitamente por cuestiones de rendimiento. El tiempo de ejecución es la más importante de estas cuestiones pero otras como la utilización del procesador o el coste de desarrollo también son importantes.
Se dice que un modelo tiene medidas de costemedidas de coste si es posible determinar el coste de un programa a partir del fuente, características mínimas sobre el diseño del computador e información sobre el tamaño de la información de entrada.
1.6. Medidas de coste.
Este concepto de coste es el mismo que se utiliza en modelos teóricos paralelos de complejidad como el PRAM [Karp & Ramachandran 1990].
Este requerimiento es el más conflictivo ya que requiere que los modelos provean costes predecibles y que los compiladores no optimicen el código. Aunque esta no es la forma en la que actualmente se considera el software paralelo, hay que decir que el diseño no es posible sin él.
Sin diseño, la construcción de software paralelo quedará como un arte oscuro en vez de como una disciplina de ingeniería.
2. Descripción de Modelos.
El objetivo de este apartado es dar a conocer los diferentes modelos actuales (1.998) y evaluar cuánto paralelismo de carácter general suministran, desde la perspectiva del cumplimiento de las propiedades descritas anteriormente.
Descripción de Modelos
Los modelos serán presentados en orden decreciente de abstracción en las siguientes categorías:
1. Abstracción completa del paralelismo.
2. Paralelismo explícito, pero descomposición en hilos implícita y por ende la asignación a procesadores, comunicación y sincronización.
3. Paralelismo y descomposición explícitos, pero asignación, comunicación y sincronización implícita.
4. Paralelismo, descomposición y asignación explícitos pero comunicación y sincronización implícita.
5. Paralelismo, descomposición, asignación y comunicación explícitos y sincronización implícita.
6. Todo explícito.
Descripción de Modelos
Dentro de cada categoría se presentan modelos de acuerdo a su grado de control sobre la estructura y comunicación, en estas subcategorías:
1. Modelos en los que la estructura de hilos es dinámica.
2. Modelos en los que la estructura de hilos es estática pero las comunicaciones no están limitadas.
3. Modelos en los que la estructura de hilos es estática y las comunicaciones están limitadas.
2.1 Nada Explícito.
Ocultar todas las actividades requeridas para ejecutar una aplicación paralela significa que el desarrollador puede utilizar todo su conocimiento y pericia en el desarrollo de un software secuencial.
Por otro lado esto significa que el trabajo del desarrollador de compiladores sea mucho más duro ya que estas herramientas deben inferir toda la estructura de cada programa.
2.2 Paralelísmo explícito.
Los desarrolladores de software no necesitan explicar de forma explícita cómo el cálculo va a ser troceado, cómo esos trozos van a ser asignados a distintas cpus y cómo se van a comunicar entre sí.
Las estrategias para implementar la descomposición se basa en utilizar algoritmos que calculen los cambios de contexto de menor coste.
La asignación a procesadores se realiza mediante estructuras de asignación predefinidas (skeletons) que se ajusten a la topología de procesadores.
2.3 Descomposición explícita.
Los modelos de este tipo requieren que los programas especifiquen las piezas en las que han de ser divididos, aunque la asignación de estas piezas a los procesadores de la arquitectura subyacente serán realizados por el propio modelo.
2.4 Asignación explícita.
Estos modelos requieren que la descomposición y asignación a procesadores venga hecha, pero proveen de cierta abstracción para las comunicaciones entre procesos.
La tarea más dura del desarrollador es identificar el origen y destino de cada comunicación; debido al alto número de comunicaciones que han de tener lugar, este proceso es largo y tedioso.
Todos los modelos de esta clase tratan de establecer una abstracción de más alto nivel para facilitar esta tarea al programador.
2.5 Comunicación explícita.
Los modelos de esta clase requieren que la comunicación se realice de forma explícita, aunque reducen la carga de sincronización que se requiere para llevarla a cabo.
Normalmente esto se realiza mediante una semántica asíncrona: los mensajes son entregados pero el emisor no puede esperar tener un tiempo de entrega predefinido, además la entrega de múltiples mensajes puede realizarse en otro orden que el de emisión.
2.6 Todo explícito.
En esta categoría de modelos no se oculta el detalle de descomposición y comunicación.
La mayoría de los modelos de computación paralela de primera generación están en este nivel, diseñados para un estilo de arquitectura concreta y gestionados de forma explícita por el desarrollador de aplicaciones.
2.7 PRAM
Es el modelo básico para muchos análisis teóricos de computación paralela.
La máquina abstracta PRAM está compuesta de un conjunto de procesadores ejecutando programas independientes pero conectados de forma síncrona a una memoria compartida.
Cualquier procesador puede acceder a cualquier posición de memoria en una unidad de tiempo, pero no pueden acceder de forma simultánea a la misma posición.
2.7 PRAM
Este modelo requiere un nivel de detalle muy grande, especificando el código para cada procesador y asegurándose que no habrá conflictos de memoria.
La parte de acceso a memoria en una unidad de tiempo es inasumible para cualquier máquina escalable real, por lo que las medidas de este modelo no son muy precisas.
El lenguaje FORK [Kessler & Seidl 1995] es un intento de proporcionar un cierto nivel de abstracción sobre PRAM.
3. Clasificación de modelos.
A continuación se citan los modelos actuales de paralelismo, junto con sus lenguajes asociados, clasificados según los criterios expuestos en los anteriores apartados.
3.1. Abstracción completa del paralelismo.
● Estructura Dinámica
– Higher-order Functional-Haskell
– Concurrent Rewriting—OBJ, Maude
– Interleaving—Unity
– Implicit Logic Languages—PPP, AND/OR, REDUCE/OR, Opera, Palm, concurrent
– constraint languages
● Estructura Estática
– Algorithmic Skeletons—P3L, Cole, Darlington
● Estática y Comunicaciones limitadas
– Homomorphic Skeletons—Bird-Meertens Formalism
– Cellular Processing Languages—Cellang, Carpet, CDL, Ceprol
– Crystal
3.2 Paralelismo explícito, pero descomposición en hilos implícita
● Estructura Dinámica
– Dataflow—Sisal, Id
– Explicit Logic Languages—Concurrent Prolog, PARLOG, GHC, Delta-Prolog, Strand
– Multilisp
● Estructura Estática
– Data Parallelism Using Loops—Fortran variants, Modula 3*
– Data Parallelism on Types—pSETL, parallel sets, match and move, Gamma, PEI, APL, MOA, Nial and AT
● Estática y Comunicaciones limitadas
– Data-Specific Skeletons—scan, multiprefix, paralations, dataparallel C, NESL, CamlFlight
3.3 Paralelismo y descomposición explícitos, pero asignación, comunicación y sincronización implícita.
● Estructura Dinámica● Estructura Estática
– BSP, LogP
● Estática y Comunicaciones limitadas
3.4 Paralelismo, descomposición y asignación explícitos pero comunicación y sincronización implícita.
● Estructura Dinámica
– Coordination Languages—Linda, SDL
– Non-message Communication Languages— ALMS, PCN, Compositional C++
– Virtual Shared Memory
– Annotated Functional Languages—Paralf RPC—DP, Cedar, Concurrent CLU, DP
● Estructura Estática
– Graphical Languages—Enterprise, Parsec, Code
– Contextual Coordination Languages—Ease, ISETL-Linda, Opus
● Estática y Comunicaciones limitadas
– Communication Skeletons
3.5 Paralelismo, descomposición, asignación y comunicación explícitos y sincronización implícita.
● Estructura Dinámica– Process Networks—Actors,
Concurrent Aggregates, ActorSpace, Darwin
– External OO—ABCL/1, ABCL/R, POOL-T, EPL, Emerald, Concurrent Smalltalk
– Objects and Processes—Argus, Presto, Nexus
– Active Messages—Movie
● Estructura Estática– Process Networks—static
dataflow
– Internal OO—Mentat
● Estática y Comunicaciones limitadas– Systolic Arrays—Alpha
3.6 Todo explícito
● Estructura Dinámica– Message Passing—
PVM, MPI
– Shared Memory—FORK, Java, thread packages
– Rendezvous—Ada, SR, Concurrent C
● Estructura Estática– Occam
● PRAM
4. Conclusiónes
● Se ha presentado un resumen de modelos de computación paralela utilizando un conjunto de seis criterios que un modelo ideal debería cumplir.
● Cuatro de los criterios establecen la necesidad de utilizar un modelo como objetivo para el desarrollo de software, estos son: facilidad de programación y la existencia de una metodología para la construcción de software que se encargue de los temas de corrección, independencia de arquitectura, simplicidad y abstracción.
4. Conclusiones
● Los restantes criterios responden a la necesidad de la ejecución del modelo en máquinas paralelas reales, garantizando rendimiento y la existencia de medidas de coste que puedan ser aplicadas al software. Juntos aseguran un rendimiento predecible para los programas
● Los modelos que se han descrito representan una amplia variedad de aproximaciones a diferentes niveles.
4. Conclusiones● Las tendencias que se observan en estos modelos son las
siguientes:
– El trabajo en modelos de bajo nivel en los cuales la descripción del proceso es totalmente explícita, ha disminuido considerablemente.
– Existe una gran concentración de modelos en el nivel medio de abstracción. Presumiblemente porque se aplica una mezcla de análisis teórico y experimentación lo que parece el mejor camino al éxito.
– Existen algunos modelos de alto nivel de abstracción que también proveen un nivel predecible de rendimiento en una gama de arquitecturas paralelas. Su existencia aumenta la esperanza, de que los modelos que satisfagan todos los requerimientos aquí expuestos, pueden ser construidos.
