CASE ILLUSTRATIONS
BIBLIOGRAPHY
Los ejemplos muestran un algoritmo que no es de costo optimo. Basicamente, el proble- ma es que se utilizan tantos procesadores como numero de entradas, lo cual es excesivo. En la practica, pueden asignarse porciones mas grandes de entrada a cada procesador. Esto corresponde a incrementar la granularidad de la computacion. La tecnica de usar menos procesadores que el maximo posible para ejecutar un algoritmo paralelo se denom- ina scaling down (reduccion progresiva) del sistema paralelo en terminos del numero de procesadores 209, 141].
Una forma de reducir un sistema paralelo es dise~nar un algoritmo para un elemento de entrada por procesador, y luego usar menos procesadores para simular una cantidad mayor. Si hay n entradas y p procesadores (p<n), se puede usar el algoritmo dise~nado
asumiendo nprocesadores virtuales y haciendo que cada uno de lospprocesadores fsicos
simule n=p virtuales. Como el numero de procesadores decrece por un factor de n=p, la
computacion en cada uno crece por el mismo factor, ya que cada uno ahora realiza el trabajo de n=p. Si los virtuales estan mapeados apropiadamente en los fsicos, el tiempo
de comunicacion general no crece mas que un factor de n=p. El tiempo de ejecucion
paralelo total crece, a lo sumo, por un factor de n=p, y el producto procesador-tiempo no
crece. Por lo tanto, si un sistema paralelo con n procesadores es de costo optimo, usar p
procesadores para simularn preserva esta optimalidad.
Una desventaja del metodo de crecer la granularidad computacional es que si un sistema paralelo no es de costo optimo inicialmente, puede aun no serlo despues del incremento de granularidad. Esto se muestra en el siguiente ejemplo.
Ejemplo 4.4
Suma de n numeros en un hipercubo p-procesador.Sea el problema de sumar n numeros en p procesadores (p < n, ambos potencia de 2).
Puede usarse el mismo algoritmo que en el Ejemplo 4.1, simulando n procesadores en p,
como muestra la Figura 4.2
El procesador virtual i es simulado por el fsico con label ip los numeros a ser
sumados son distribuidos de manera similar. Los primeros logp de los logn pasos del
algoritmo original son simulados en ((n=p)logp) pasos en p procesadores. En los pasos
restantes, no se requiere comunicacion porque los procesadores que se comunican en el algoritmo original son simulados por el mismo por lo tanto, los numeros restantes son sumados localmente.
El algoritmo toma ((n=p)logp) tiempo en los pasos que requiere comunicacion,
y luego un solo procesador se queda con n=p numeros para sumar, tomando tiempo
Figura 4.2: 4 procesadores simulando 16 procesadores para computar la suma de 16 numeros
Figura 4.3: Suma de 16 numeros en un hipercubo 4-procesador, con costo optimo (asintoticamente mayor que el costo (n) de sumar n numeros secuencialmente). Por lo
tanto, el sistema paralelo no es de costo optimo 209]. 2
El Ejemplo 4.1 mostro que pueden sumarse n numeros en un hipercubo n-procesador
en tiempo (logn). Cuando se usan p procesadores para simular n, el tiempo de eje-
cucion paralelo esperado es ((n=p)logn). Pero, en el Ejemplo 4.4 la tarea se realizo
en ((n=p)logp). La razon es que cada paso de comunicacion del algoritmo original no
tiene que ser simulado a veces, la comunicacion tiene lugar entre procesadores virtuales simulados por el mismo procesador fsico. Por ejemplo, la simulacion de los pasos 3 y 4 no requiere comunicacion. Pero, esta reduccion en comunicacion no fue suciente para hacer al algoritmo de costo optimo. El siguiente Ejemplo muestra que el problema puede ser resuelto con costo optimo con una asignacion mas inteligente de datos a procesadores.
Ejemplo 4.5
Suma de n numeros con costo optimo en un hipercubo.La Figura 4.3 muestra un metodo alternativo para sumar n numeros usando p proce-
sadores. En el primer paso, cada procesador suma localmente sus n=pnumeros en tiempo
(n=p). Ahora el problema se reduce a sumar las p sumas parciales en p procesadores,
lo que puede hacerse en tiempo (logp) por el metodo descripto en el Ejemplo 4.1. El
tiempo de ejecucion paralelo de ese algoritmo es (n=p+logp) y su costo es (n+plogp).
Cuando n= &(plogp), el costo es (n), que es igual al tiempo de ejecucion. Por lo tanto,
el sistema paralelo es de costo optimo 209]. 2
Los ejemplos muestran que la manera en la cual la computacion se mapea en los procesadores puede determinar si un sistema paralelo es de costo optimo. Sin embargo, no puede hacerse de costo optimo a todos los sistemas que no lo son haciendo scaling down del numero de procesadores.
Con un mapeo de datos adecuado, usar menos procesadores fsicos para simular un numero mayor de procesadores virtuales mantiene la optimalidad en costo si el sistema
paralelo es de costo optimo inicialmente. Pero, si el sistema paralelo no es de costo optimo para un gran numero de procesadores, entonces una simulacion no resulta necesariamente en un sistema de costo optimo. Aun en el primer caso, mas alla de preservar la opti- malidad, un enfoque ingenuo puede resultar en una formulacion inferior en terminos de tiempo de ejecucion paralelo.
Una simulacion de varios procesadores por menos puede no tener en cuenta que hay multiples maneras de asignarnprocesadores virtuales apfsicos (n >p). La performance
puede ser diferente para distintas asignaciones. En el Ejemplo 4.1, la tarea de dividir
n entradas entre n procesadores era trivial pues a cada procesador se le asigno un solo
elemento. Pero, si las n entradas son mapeadas a pprocesadores, donde n >p, entonces
hay mas de una manera de hacerlo. Como muestran los Ejemplos 4.4 y 4.5, el tiempo paralelo del mismo problema es una funcion del mapeo de procesadores virtuales en fsicos. Un algoritmo que requiere W pasos de computacion basicos puede ser mapeado en
un maximo de W procesadores, y cada procesador realiza un solo paso del algoritmo
secuencial. Si se usan menos procesadores, entonces cada uno resuelve una parte mayor del problema entero. Puede haber distintos algoritmos secuenciales para resolver una parte del problema localmente en un procesador. A veces, la eleccion del metodo para realizar la computacion local afecta el tiempo de ejecucion paralelo asintotico. De hecho, la eleccion del mejor algoritmo para realizar las computaciones locales en cada procesador puede depender del numero de procesadores. Ejemplos de tales sistemas paralelos incluyen algunos algoritmos de sorting y multiplicacion de matrices.
El algoritmo paralelo optimo para resolver un problema sobre un numero arbitrario de procesadores no puede ser obtenido trivialmente desde el algoritmo paralelo de grano mas no. Mas aun: un analisis del sistema paralelo basado en la formulacion de grano mas no puede ocultar el efecto de ciertos rasgos de hardware sobre la performance del sistema paralelo. Por ejemplo, el tiempo de transferencia de un mensaje entre dos procesadores es el mismo con ruteos store-and-forward y cut-through si el mensaje contiene solo una
palabra. Por el contrario, el ruteocut-through con frecuencia permite transferencias mucho
mas rapidas de mensajes grandes que el ruteostore-and-forward. La performance de varios
algoritmos paralelos es casi identica en un hipercubo y una mesh con ruteocut-through sin
embargo, su performance es mucho peor en una mesh con store-and-forward. Un analisis
del algoritmo paralelo de grano mas no puede no revelar estos hechos importantes. Esta discusion ilustra que dise~nar un algoritmo paralelo eciente involucra mas que desarrollar un algoritmo para un elemento de entrada o para una computacion por proce- sador. Concebir el algoritmo de grano mas no usualmente es facil y puede servir como primer paso logico hacia el desarrollo de un algoritmo paralelo. Pero, el dise~no completo debera tener en cuenta el mapeo de datos en procesadores e incluir una descripcion de su implementacion en un numero arbitrario de PEs. Por eso es comun tomar el tama~no de la entrada y el numero de procesadores como dos variables separadas al dise~nar y analizar algoritmos paralelos.