Análisis y Diseño de Algoritmos

Ernesto Cárdenas Cangahuala

Semana 14: Computación paralela

Recordando:¿Bajo que supuesto hemos estudiado los algoritmos hasta ahora?

Logro de aprendizaje

• Al finalizar la sesión el estudiante:Explicara los fundamentos de la

computación paralela y su problemática

Hemos supuesto que nuestros programas se ejecutaran en una maquina que solo puede ejecutar una instrucción por vez

¿Es eso cierto en la vida real?

• ¿Qué ventajas podríamos sacar de esta realidad en nuestros algoritmos?

¿Qué es la programación paralela?• El uso de varios procesadores trabajando

juntos para resolver una tarea o problema común

Ventajas

• La programación paralela permite:• Resolver problemas que no caben en una CPU• Resolver problemas que no se resuelven en un

tiempo razonable

• Se pueden ejecutar• Problemas mayores• Más rápidamente (aceleración)• Más problemas

Aclarando conceptos…• Programación concurrente:

• Varios procesos trabajando en la solución de un problema, puede ser paralela (varios procesadores)

• Computación heterogénea:• Varios procesadores con características distintas

• Programación adaptativa:• Durante la ejecución el programa se adapta a las características del sistema

• Programación distribuida:• Varios procesadores geográficamente distribuidos. Hay paso de mensajes pero

se necesita infraestructura especial (ej: cloud)

• Computación cuántica o biológica

¿Y como empezó esto?

Recordemos

• Ley de Moore: Cada dos años aproximadamente se duplica la cantidad de transistores en un circuito integrado

Bajo la Ley de Moore…• En los 70s y 80s, cada generación de chips podía

usar la mayoría de los transistores adicionales para añadir una Gran Caracteristica (unidad de punto flotante, pipelining…)que haría que el código single-threaded corra mas rápido.

• En los 90s y 2000s, cada generación de chips empezó a usar los transistores adicionales para añadir o mejorar dos o tres pequeñas características que haría que el código single-threaded corra mas rápido, y luego cinco o seis características aun mas pequeñas y así sucesivamente.

Hasta que…

• “The Free Lunch is Over” (Herb Sutter, 2005)• Los fabricantes se enfocaran en

mejorar el soporte multithreading y por ende los procesadores multi-core• Los desarrolladores deberán

producir programas multihilo a fin de sacar mejor uso a estos procesadores

Esto significa

• Adiós esperar que la velocidad de los procesadores ayude a compensar a un software lento• Las ganancias de performance ya no

serán lineales, habrá que luchar por ellas

Los multinucleos ya no son la excepción, son la norma

Welcome to the Jungle!

Welcome to the Jungle!“For the first time in the history of computing, mainstream hardware is no longer a single-processor von Neumann machine, and never will be again.”

Explotando ese terreno…• Aplicaciones que aprovechan la GPU• Esquemas donde la GPU y el CPU acceden a

la misma memoria (¡Xbox!)• Intel Threading Building Blocks (TBB),

Microsoft Parallel Patterns Library…• Procesadores con diferentes tipos de cores en

su núcleo (¡Playstation!)• Y los modelos de cloud elásticos…

Asi pues…

¿Y esto que significa para nosotros?

• Las aplicaciones necesitaran ser al menos masivamente paralelas, e idealmente capaces de usar cores no locales y cores heterogéneos

• La optimización de Eficiencia y performance será mas y no menos importante

• Los sistemas y lenguajes de programación se verán forzados cada vez mas a lidiar con paralelismo distribuido heterogéneamente

• Los entornos cloud te dan APIs para ello, hay que usarlas

Veamos algo en acción

Observaciones

• Se logran mejores resultados si usamos mas dimensiones para el problema de las reinas• Las tareas individuales pueden durar un

poco mas porque es necesario una gestión alrededor de ellas puesto que corren en procesadores separados

¿Opiniones?

Tipos de Paralelismo

• Paralelismo de datos: cada procesador ejecuta la misma tarea sobre diferentes conjuntos o subregiones de datos• Paralelismo de tareas: cada procesador

ejecuta una diferente tarea• La mayoría de las aplicaciones están

entre estos dos extremos

Cuidados y riesgos• Hasta ahora asumíamos que se efectuaba una

instrucción por vez sobre una única variable• Cuidar lo que pasa cuando varios procesos asignen

nuevos valores a una variable en paralelo• ¿Se puede suponer que la variable tiene el ultimo

valor asignado?• ¿Sabemos cual es el resultado real de dicha

asignación?• ¿Y si dependemos que un conjunto de variables

alcance cierto valor? ¿Quién coordina?

Consideraciones• Los códigos paralelos rápidos requieren un eficiente

uso del escalamiento del hardware• No todos los algoritmos escalares pueden ser

paralelizados bien, puede ser necesario repensar el problema• Comunicación: Necesidad de minimizar el gasto del tiempo de

comunicación• Balanceo de Carga: Todos los procesadores deben hacer aprox. el

mismo trabajo

Topes• Ley de Amdahl’s: Limite fundamental de la

computación paralela pues predice que existe un máximo de escalabilidad para una aplicación (para un conjunto de datos de tamaño fijo), y este limite, generalmente, no es muy grande

• Ley de Gustafson’s indica que cualquier problema suficientemente grande puede ser eficientemente paralelizado

Rendimiento• Un código paralelo bien entendido es un buen

código escalar.• Si un código escala a 256 procesadores pero

sólo se obtiene un 1% de mejora de rendimiento en un pico, éste es un mal código paralelo.• Noticia buena: Cada cosa que usted sabe acerca de la

computación serial es útil en la computación paralela!• Noticia mala: Es difícil obtener un buen rendimiento de

procesadores y memoria en máquinas paralelas. Se necesita un uso efectivo de caché.

Eficiencia y optimización• En términos generales se considera que un

alg. Paralelo hace mas cálculos en t segundos con 20 procesadores que con cinco, así trabajo = procesadores * tiempo

• Se requiere un numero polinómico de procesadores y un tiempo polilogaritmico para ser eficiente

• Se es optimo si se es eficiente en trabajo respecto al mejor algoritmo secuencial posible

Aunque…

• Hay problemas sin solución secuencial eficiente, así que no podemos esperar una solución paralela eficiente• Hay muchos problemas con solución

secuencial eficiente pero sin solución paralela eficiente, en algunos casos esto no ha sido demostrado

La 1ra. Pregunta a Responder antes de Paralelizar

• Detenerse a pensar • ¿La cantidad de CPU disponibles justifican la

paralelización?• ¿Se necesita una máquina paralela para obtener

suficiente memoria agregada?• ¿El código va a ser usado una sóla vez o se usará para

una mayor producción?

• El tiempo es valioso, se puede consumir mucho tiempo para escribir, depurar, y probar un código paralelo. Mucho tiempo se gasta en escribir un código paralelo.

La 2da. Pregunta a Responder antes de Paralelizar

• ¿Cómo se debe descomponer el problema?• ¿Los computos consisten de un gran número de

pequeños e independientes problemas - trayectorias, parámetros del espacio estudiado, etc? Se puede considerar un esquema en el cual cada procesador realiza el cálculo para diferentes conjuntos de datos• ¿Cada computo requiere mucha memoria y CPU?

Probablemente hay que distribuir un simple problema hacia múltiples procesadores

Ojo, recuerda que tus múltiples procesos no necesariamente corren en una única maquina, el cloud también es computación paralela ;)

¿Opiniones?