Mi clase del curso de Analisis y Diseño de Algoritmos en la Universidad Privada del Norte, donde se da el contexto de la computación paralela como una tendencia irreversible, con énfasis en lo visionado por Herb Sutter (Welcome to the Jungle) y las consideraciones que hay que tener para programar en esa modalidad.

1. Análisis y Diseño de Algoritmos
Ernesto Cárdenas Cangahuala

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

3. Logro de aprendizaje

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

5. ¿Es eso cierto en la vida
real?

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

7. ¿Qué es la programación paralela?
• El uso de varios procesadores trabajando juntos
para resolver una tarea o problema común

8. 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

9. 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

10. ¿Y como empezó esto?

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

12. 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.

13. 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

14. 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

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

16. Welcome to the Jungle!

17. 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.”

18. 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…

19. Asi pues…

20. ¿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

21. Veamos algo en acción

22. 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

23. ¿Opiniones?

24. 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

25. 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?

26. 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

27. 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

28. 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é.

29. 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

30. 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

31. 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.

32. 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

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

34. ¿Opiniones?