Medición de Balance de Carga Escalable para código
SPMD
Marcos Frutos
Facultad Politécnica
Universidad Nacional de Asunción
San Lorenzo - Paraguay
+595 981 165852
mharcosfrutos@gmail.com
ABSTRACT
El buen balance de carga es crucial en sistemas paralelos de gran
tamaño, pero los algoritmos más sofisticados introducen
desbalanceo dinámico. Para diagnosticar este desbalanceo, los
desarrolladores deben observar en sistemas grandes, con
mediciones en datos ordenados temporalmente y grandes escalas
de ejecución. Esto requiere la recolección de datos desde distintas
secciones de código, en todos los procesadores durante toda la
ejecución. Esto puede inducir a severas perturbaciones de
comportamiento debido a las limitaciones de ancho de banda de
E/S y capacidad de almacenamiento.
Presentamos y evaluamos una novedosa técnica, escalable y con
bajos índices de error para la medición del balance de carga.
Utiliza transformación wavelet y otras formas de codificación
paralela. Demostramos que comprimimos y reconstruimos los
datos con mínimos errores. Los volúmenes de datos son
significativamente menores a los datos en crudo y los tiempos son
logarítmicos, es decir, inferior a tiempos lineales. La sobrecarga
es suficientemente baja para ambientes de producción.
1. INTRODUCCIÓN
En sistemas de computadoras paralelas con memoria distribuida,
el balance de carga es crítico para el rendimiento. Generalmente
en estos sistemas corren algoritmos síncronos, en los cuales el
exceso de cómputo de un proceso puede causar que los otros estén
ociosos. El impacto del desbalanceo se está volviendo peor
últimamente, ya que anteriormente los mayores equipos contaban
con 9.632 procesadores, mientras que hoy en día una IBM Blue
Gene/L tiene 212.992. UnA simple sobrecarga en un proceso
puede causar que cientos de miles de procesos tengan que esperar.
Medir y diagnosticar el balance de carga es difícil ya que todos los
procesos deben ser observados. Además, muchas aplicaciones
utilizan algoritmos adaptativos, dato-dependientes que deben ser
observados por diferentes periodos de tiempo. Los datos deben ser
recolectados a lo largo de las siguientes 3 dimensiones: i) donde
ocurre el problema en el código; ii) en los procesadores en los
cuáles la carga es desbalanceada y iii) cuando ocurre el
desbalanceo de carga durante la ejecución.
La principal contribución de este paper es una novedosa forma de
medición que reduce el volumen en 2 o 3 órdenes de magnitud.
Nuestro esquema utiliza técnicas de compresión de datos y
tiempo, como también la codificación wavelet para reducir
suficientemente los requerimientos de comunicación y
almacenamiento.
Nos enfocamos en recolectar métricas de los ciclos, que
clasificamos en unidades de progreso y esfuerzo. Los ciclos de
progreso presentan los pasos a seguir para alcanzar el objetivo.
Los ciclos de esfuerzo son regiones incrustadas dentro de los
ciclos de progreso. Estos representan el esfuerzo realizado para
alcanzar una unidad de progreso. El número de iteraciones en los
ciclos de esfuerzo pueden variar por la adaptación de localización
de las estructuras de los datos, o la convergencia natural del
algoritmo hacia una solución. También el tiempo puede variar,
dependiendo de la localidad de los datos, la memoria o errores de
E/S.
2. EL MODELO DE ESFUERZO
El modelo está enfocado en aplicaciones paralelas con Programas
Simples de Múltiples datos (SPMD, por sus siglas en inglés),
particularmente los que utilizan MPI. Como MPI es ampliamente
utilizado, y es considerado el estándar de facto para programación
paralela, la mayoría podrá utilizar nuestro framework.
Los ciclos de las aplicaciones SPMD se pueden dividir en dos
categorías:
Ciclos de progreso: Típicamente el ciclo externo, el
cual indica el camino hacia el logro de un objetivo
específico. Cada iteración es global, síncrona y
midiendo la duración de estos ciclos podemos
determinar cuánto la aplicación tardará en ejecutarse,
aún sin saber la cantidad de ciclos que llevará terminar
el programa, gracias a la evolución de su rendimiento.
Ciclos de esfuerzo: Estos son ciclos con tiempo
variables, dependiente de los datos. Están dentro de los
ciclos de progreso y podemos medir el trabajo requerido
contando las iteraciones de los ciclos de esfuerzo.
Muchos factores influyen en la duración variable de un grupo de
ciclos de esfuerzo. El tamaño y la complejidad de los datos, la
disponibilidad y el rendimiento de los recursos de E/S, la red y
hasta inclusive nodos caídos. Los datos impactan fuertemente en
la complejidad, el grado de refinamiento y la velocidad de
convergencia.
La relación entre estos dos ciclos se da para determinar
problemas. Si los ciclos de esfuerzo tienen tiempos de ejecución
muy diferentes, podemos concluir que es un problema en los
datos. Sin embargo, si el tiempo de esfuerzo es equivalente en la
mayoría de los ciclos de esfuerzo, sin embargo los ciclos de
progreso varían, se podría tratar de un problema de hardware o
configuración.
Podemos comparar estos ciclos con sus respectivos pares en otros
procesos y obtener datos significativos referentes a la carga y
anomalías entre procesos.
Las mediciones de esfuerzo podrían hacerse automáticamente,
pero en este trabajo lo realizamos en intervalos fijos de tiempo ya
que esto es suficiente para ilustrar el modelo sin perder
generalidad.
Progreso y esfuerzo son medidas de alto nivel. Los monitores de
rendimiento de Hardware (HPM, por sus siglas en inglés) pueden
capturar eventos a nivel de hardware. Podemos clasificarlos en:
• La razón o proporción de dos eventos HPM observados
durante cierto periodo;
• Eventos HPM por unidad de tiempo medidas sobre un
intervalo de observación;
• Eventos HPM por unidad de esfuerzo o progreso de la
aplicación;
• Eventos específicos de aplicación por unidad de tiempo
observados sobre un periodo.
Las proporciones y tasas, como los fallos de cache o mala
predicción de salto, miden la eficiencia con la cual ciertos
dispositivos están operando. Relacionar las mediciones de alto
nivel (Progreso y esfuerzo) con las mediciones HPM provee un
mejor entendimiento del rendimiento general del sistema.
3. ANÁLISIS WAVELET
Para colectar datos de sistemas grandes de forma escalable,
necesitamos una representación compacta y un método escalable
de agregación para el dato. El análisis wavelet se volvió el método
dominante para reducción de datos. Es utilizado en procesamiento
de señales diversas, imágenes digitales [1,2] y redes de sensores
[34]. Una transformación wavelet expande una función en el
dominio espacial a una función ortogonal polinomial en L2(R).
Figura 1: Descomposición multiescala para un nivel L en la
transformación wavelet.
Los fundamentos teóricos de la transformación son vistos en
[11,35], pero básicamente se trata de una operación que convierte
un grupo de N muestras, s0 … sN-1 en dos grupos de N/2
coeficientes. La transformación es realizada L veces, se le llama
transformación de nivel L, y los datos tendrán L escalas.
D es el tamaño de los filtros (a y b) utilizados. En este trabajo
utilizamos específicamente la transformación Favreau 9/7. Los
filtros de pasadas altas y bajas CDF 9/7 contienen 9 y 7
elementos reales, respectivamente. Se demostró que funciona bien
para compresión de imágenes, y es utilizado en JPEG-2000.
Seleccionamos la transformación wavelet por dos razones.
Primera, algoritmos paralelos escalables para la transformación
wavelet son conocidas [25]. Segunda, ciertas propiedades de la
transformación son útiles para el monitoreo del balanceo de la
carga. Además, la representación wavelet conserva la localidad de
los datos. Los coeficientes wavelet contienen información de
localidad y frecuencia de datos de las muestras originales, lo cual
es esencial para el propósito de nuestro análisis.
En este paper utilizamos múltiples transformaciones wavelet bi-
dimensionales para analizar las medidas tomadas en tiempo de
ejecución. Las transformaciones consisten en series de
transformaciones de una dimensión, primero en las filas luego en
las columnas. Aquí, la fila representan los pasos de progreso, y la
columna es el id del proceso en la aplicación paralela. Los valores
en cada matriz representan el trabajo generado por cierta región
en el código. La figura 1 muestra la matriz resultante. El
cuadrante de abajo a la derecha contiene los datos con mayor
frecuencia en ambas dimensiones, los cuadrantes superior derecho
e inferior izquierdo contiene datos de alta frecuencia en una
dimensión y baja frecuencia en otra, y los datos de baja frecuencia
en el cuadrante superior izquierdo es transformado en L veces.
4. UN FRAMEWORK PARA LA
ESCALABLE MEDICIÓN DE CARGA
Nuestro diseño consiste en dos mayores componentes. Primero,
hemos ideado un esquema para la obtención de datos modelo del
esfuerzo en eventos MPI. Se monitorea en el momento en el que
ocurren y se determina la región automáticamente. Segundo,
hemos diseñado un método de agregación escalabre usando
transformación wavelet en paralelo y técnicas de compresión
paralelas.
Empleamos una herramienta de propósito general.
Implementamos nuestra técnica de modelo de extracción de datos
usando la interface PMPI y mapeamos los eventos MPI a matrices
de esfuerzos distribuidas que pueden ser rápidamente agregadas.
La herramienta de agregación no está asociada a nuestro modelo
de esfuerzo, solamente comprime datos genéricos numéricos.
4.1 Capa de filtro de esfuerzo
Diseñamos una capa para la extracción automática de datos de
esfuerzo de las aplicaciones MPI. Como utilizamos PMPI, es una
librería vinculada y actualmente requerimos la intervención del
usuario para ello. Una vez agregada, el usuario puede hacer uso
de nuestra librería y sacar ventajas de nuestras herramientas de
colección de datos.
Para medir el esfuerzo computacional, almacenamos el tiempo
transcurrido en regiones de código donde no se realiza
comunicación. Asumimos que el esfuerzo está dado por
operaciones split, o construcciones de comunicación síncrona. Las
aplicaciones Split no se limitan a las colectivas
MPI_Allgather(), MPI_Barrier() y MPI_Reduce(),
sino también MPI_Waitall(). De todos modos, está
permitida la personalización de las aplicaciones consideradas
Split.

Figure 2: Identificación dinámica de regiones de esfuerzo.
En la figura 2 vemos las capas de esfuerzo con una máquina de
estados. En la figura, la sombreada MPI_Control() las
operaciones Split corresponde a los estados. Cuando el control
pasa de un sitio a otro, se genera un grafo de transición. Este grafo
guarda el tiempo transcurrido del esfuerzo, etiquetado en la figura
con sus identificadores. En tiempo de ejecución, monitoreamos el
tiempo transcurrido para cada región de esfuerzo separadamente,
usando los paths de llamada inicio y fin como identificadores. El
framework también guarda el tiempo utilizado dentro de una
operación Split como una medida separada de esfuerzo de
comunicación. Para obtener los paths de llamada utilizamos la
API disponible públicamente de DynStackwalker[27].
Los datos de esfuerzo son recolectados al final de cada ciclo de
progreso. Nuestro filtro suma los valores de esfuerzo para todas
las regiones en el paso actual de progreso en el vector por-región.
Así, al final de n ciclos de progreso y m regiones de esfuerzo,
cada proceso cuenta con vectores con m n-elementos de valores
de esfuerzo. Como los valores de esfuerzo son etiquetados con sus
paths de llamados, el usuario posteriormente puede relacionar el
esfuerzo en tiempo de ejecución con regiones específicas del
código fuente.
4.2 Algoritmo Paralelo de Compresión
Nuestro algoritmo agresivamente se enfoca en los cuellos de
botella de E/S utilizando compresión wavelet para reducir el
tamaño de los datos. Utilizamos todos los procesadores para
realizar la compresión suficientemente rápido para el monitoreo
en tiempo real a escala.
Basamos nuestra transformación paralela según Nielsen [25],
aunque nuestros datos tienen una leve diferencia en cuánto a
distribución. Al final de cada tramo, cada proceso en la aplicación
distribuida tiene un vector de medida de esfuerzo (uno por cada
paso de progreso) para cada región de esfuerzo. Cada uno de estos
vectores pueden ser vistos como una fila en una matriz distribuida
de dos dimensiones. Para las transformaciones entre filas de esta
matriz, los datos son enteramente locales, pero transformaciones
entre columnas están distribuidas. Necesitamos por lo menos D/2
(la mitad del tamaño del filtro wavelet) filas por proceso. Esto
garantiza que solamente será necesaria la comunicación entre los
vecinos más cercanos entre procesos. Además, para una
transformación de nivel L, el número de filas por proceso deberá
ser suficientemente grande como para ser partido a la mitad L
veces y aun así los datos no sean más chicos que D/2. Para
asegurar esto, consolidamos las columnas antes de realizar la
transformación. Para un sistema con P procesos, nuestro
algoritmo reagrupa la matriz distribuida en P/S grupos locales de
S filas. La figura 3 muestra como se ve esto con S = 4.
Luego realizamos la transformación paralela en la matriz
consolidada.
Después de transformar cada matriz, nuestro algoritmo codifica
los coeficientes transformados utilizando la codificación Zerotree
Wavelet Embedido (EZW) [31]. Elegimos esta codificación por
dos razones: Primero, paraleliza muy bien [3,19]. El template
utilizado corresponde a la organización de los coeficientes de la
transformación wavelet y la codificación es enteramente local para
cada proceso. Segundo, compensa eficientemente las precisiones
de espacio. Los bits de salida del EZW están ordenados por
significancia. Cada pasada del codificador prueba los coeficientes
del wavelet contra sucesivos umbrales más pequeños y bits de
salidas indicando si los coeficientes fueron más grandes o más
pequeños que los umbrales. Los primeros pasos generalmente
generan datos muy compactos, y contienen los bits más
significativos de los coeficientes mayores en la salida. De todos
modos podemos obtener una buena aproximación leyendo una
pequeña de datos del EZW. Examinando más pasadas detalladas
refina la calidad de la aproximación, a cambio de un mayor costo
de volumen de datos. En nuestro framework el número de pasadas
se puede configurar. En una etapa final, tomamos la codificación
local del EZW, lo codificamos a lo largo y luego unimos los
búferes en una reducción paralela. Cada nodo interno del árbol de
reducción recibe buffers codificados de sus hijos, los junta sin
descomprimir y envía el buffer resultante mezclado a sus padres.
La unión está hecha por el hecho de unir corridas de símbolos
matcheados en cada fin del buffer codificado. Agregamos el dato
comprimido en un buffer simple en la raíz del árbol de reducción
y codificamos con Huffman[17] todo el buffer.
El paso de consolidación sacrifica paralelismo con el fin de
incrementar la localidad y reducir el costo de comunicación. De
todos modos, generalmente tenemos muchas matrices a
transformar, y podemos realizar S transformaciones concurrentes.
Si tenemos S o más regiones de esfuerzo, podemos distribuir este
trabajo entre todos los procesos en el sistema.
4.3 Reconstrucción de los datos
Nuestra herramienta produce una representación compacta de un
sistema grande, datos con carga balanceada y temporalmente
ordenados. Una vez almacenados, podemos descomprimir y
reconstruir los datos para análisis o para mostrar en una
herramienta de visualización. El proceso de reconstrucción es
simplemente la inversa de la compresión. Decodificamos con
Huffman, decodificamos a lo largo, decodificamos con EZW y
aplicamos la transformación wavelet inversa al dato comprimido.
La representación wavelet son particularmente útiles para el
balanceo de carga, porque conserva la información espacial.
Como la transformación guarda información de escala y espacial,
características representadas por los coeficientes en el dominio
wavelet son reconstruidos en sus id originales y pasos de progreso
cuando la transformación inversa aplicada.
La compresión tiene ciertas pérdidas por varias razones. La doble
precisión de los puntos flotantes utilizados en la transformación
CDF 9/7 introduce errores de redondeo. La doble precisión es
puesta a escala y convertida a enteros de 64 bits para la
codificación EZW. Finalmente, la salida del EZW es truncada
luego de cierta cantidad de pasadas, ocasionando errores En la figura 5 muestra la sobrecarga de nuestra herramienta en
variables. Sin embargo, estos errores introducidos no son términos de porcentaje, sin incluir compresión. Para ambos,
significativos en nuestro análisis. Raptor y ParaDis, la carga fue siempre de 5% o menos,
comparados con ejecuciones sin la herramienta.

5. RESULTADOS EXPERIMENTALES
Realizamos experimentos con nuestra herramienta en dos
sistemas. El primero es una IBM BlueGene/L (BG/L) con nodos
PowerPC de 2048 dual-core y 700 MHz. Cada nodo tiene 1 GB
de RAM (512 por núcleo). Usamos el compilador gcc con la
implementación MPI de IBM. En las pruebas utilizamos tanto el
modo de ejecución modo coprocesador como también el modo
virtual node (VN), en el cual cada núcleo realiza el cómputo y la
comunicación.
Utilizamos dos bien conocidas aplicaciones científicas para los
test, ParaDis y Raptor, ambos con escalas de 16,000 o más
procesos [20]. ParaDis[6] usa un balanceador de carga adaptativo
en tiempo de ejecución para mantener pareja la carga a lo largo de
la red. Estas disociaciones son divididas en regiones llamadas
dominios. Cada proceso computa en un dominio, y el balanceador
redistribuye las disociaciones entre dominios periódicamente.
Raptor [16], es un código que simula complejos fluidos
dinámicos. Como ParaDis, Raptor es conocido por tener
cantidades variables de computación por proceso.

5.1 Tiempo de mezcla

Hemos realizado ejecuciones a escala de Raptor y ParaDis en
nuestros clúster y medido el tiempo consumido por nuestro
algoritmo de compresión. Esto incluye, transformación,
codificación y tiempo de escritura. Para comparación, utilizamos
sets idénticos de ejecución en los cuales realizamos exhaustivas
escrituras en disco. Para los experimentos, realizamos las
escrituras en disco después de la consolidación de filas. Esto es,
cada hoja nodo en nuestra codificación a lo largo escribe su
partición de la matriz en un archivo. Así, nuestro volcado toma
ventaja de operaciones E/S paralelos si está disponible.
Para cada aplicación, corrimos las simulaciones para 1024 pasos.
Durante la compresión, permitimos a la transformación wavelet
repetir tan profundamente como pueda, y configuramos la fase
inicial del algoritmo para consolidar 128 filas por proceso.
Truncamos la salida del EZW en 4 pasadas. Para cada corrida,
guardamos el tiempo total de ejecución, tiempo de escritura del
dato crudo y el tiempo a comprimir y escribir el dato comprimido.
En la figura 6 se muestra el tiempo requerido para escribir la carga
balanceada al final de cada corrida, con y sin la herramienta; y
con distintos modos de ejecución. Para el Raptor vemos que el
sistema se satura alrededor de 1024 procesos, mientras que para
ParaDis empieza un poco antes, alrededor de 512 procesos.
Alternativamente, nuestro algoritmo de compresión logra un
rendimiento casi constante a lo largo de los rangos de procesos.
El tiempo es mayormente por la compresión y descompresión, sin
embargo no saturamos el sistema de E/S como lo hacen sin
compresión ambos algoritmos. Nuestro enfoque se ajusta
perfectamente ya que los algoritmos de transformación requieren
solamente comunicación con vecinos cercanos y la codificación
EZW es totalmente local. De hecho, esta implementación del
wavelet logra velocidades casi perfectas[25]. Al final, la
codificación a lo largo es lineal en términos de tamaños de datos
comprimidos, pero estos datos ni se acercan a lo que sería saturar Caracterizamos nuestros errores de dos maneras: cuantitativa y
el sistema de E/S. cualitativamente.

5.2 Volúmenes de datos

En esta sección, cuantificamos el volumen de datos producido por
nuestra colección de algoritmos. Caracterizamos el grado en el
cual el usuario puede sacrificar la precisión para mejorar la
compresión, y comparamos el volumen total de datos producido
por nuestro algoritmo con el tamaño de la salida sin comprimir.
Para esta corrida usamos filas de 128 por proceso y permitimos a
la transformación wavelet repetirse hasta el nivel 5, dependiendo
del tamaño de la matriz a ser comprimida.

Corrimos 1024 procesos, 1024 ciclos de progreso de Raptor y

ParaDis, variando el número de pasadas EZW para los archivos
comprimidos. La figura 9 muestra el error para cada pasada. El
gráfico se muestra con cajas para dar idea del tamaño de las
regiones de esfuerzo. Para el Raptor existen 16 y para el ParaDis
hay 120. Las cajas muestran el máximo y mínimo error en la
proporción de errores para cada pasada, mostrando la media con
una rayita negra.
Para Raptor podemos ver que el error medio baja de 10% en la
primera pasada a casi 0 en la pasada 64. Para las primeras pasadas
hay un rango de 1% a 25%. Después de 4 pasadas el error medio
es solamente 4% y solamente la cima de la caja está por encima
Como mencionamos, la compresión EZW permite ajustar el
del 10%. A la 7ma. Pasada el error ya no supera el 1%. Los
tamaño de los datos versus el error ajustando el número de
resultados del ParaDis en la figura 9(b) son similares. Empieza la
pasadas. La figura 7(a) y 7(b) muestra datos comprimidos y la
media alrededor de 10%, pero cae rápidamente, y otra vez en la
proporción de 1024 procesos y corridas del Raptor. Para una
pasada 7 ya no supera el 1%.
pasada la proporción es de 10000:1, para 5 es de 100:1 o mayores.
El tamaño luego crece hasta las 35 pasadas, desde donde ya
permanece casi constante.

5.3 Error de reconstrucción

Hay tres fuentes de errores en nuestro algoritmo de compresión:
errores de redondeo del DF 9/7 de la transformación wavelet,
errores de conteo en las codificaciones a lo largo y los errores de
umbrales del EZW. Las dos primeras son inevitables, pero
contribuyen muy poco para el error global. El tercero puede ser
ajustado por el usuario y compensar la precisión con el espacio.
Obviamente, no podemos descartar demasiados datos, un error
severo podría empeorar la caracterización del esfuerzo.

Para evaluar si los errores permanecen estables en cuanto crecen
los tamaños de los sistemas, variamos el tamaño de los sistemas y
el número de pasadas EZW. Otra vez, recolectamos una gran
cantidad de datos con datos comprimidos al final de cada corrida,
y comparamos los valores de los errores obtenidos. La figura 10
muestra la media de errores para estas corridas. Para ParaDis los
errores disminuían acorde el sistema crecía, y se empezaban a
estabilizar al alcanzar los 1024 procesos. Sin embargo, con Raptor
vemos errores más variables, ya que usamos datos con cargas más
pesadas. Hay picos en procesos 256 y 4096 en el modo virtual
node (VN) y también en 1024 procesos en el modo coprocesador.
En todos los casos, vemos que estos picos se dan con una sola
pasada del EZW, en este caso la media de error puede variar
dentro del rango del 20%. De todos modos, la media de error
sigue estando por debajo del 10% para 3 o más pasadas del EZW.
El error medio es menos de 5% para 5 o más pasadas para ambas
aplicaciones, sin importar el tamaño del sistema.
5.4 Evaluación cualitativa de la
reconstrucción
Para ilustrar la calidad de la reconstrucción, guardamos datos
exactos para comparación. Para ilustrar el desbalance de carga,
usamos un conjunto de datos suficientemente pequeño como para
que la carga no pueda ser distribuida de forma pareja entre los
procesadores.
En la figura 11 vemos la reconstrucción del esfuerzo para
ParaDis, variando el número de pasadas del EZW. Como ya
dijimos, menores pasadas corresponden a mayor compresión y
mayores errores, lo que refleja la figura, donde vemos como con
cada pasada va acercándose a los datos exactos. A las 15 pasadas
podemos decir que trabajamos con los datos exactos.
6. TRABAJOS RELACIONADOS
Las herramientas de evaluación de rendimientos tradicionales son
insuficientes para el monitoreo del balance de carga en sistemas
grandes [12, 23, 32] ya que no tienen en cuenta información de
tiempo, que es crítico para el entendimiento de la evolución de la
carga. Los rastreadores de eventos [5,12, 22] guardan información
del tiempo pero fallan con sistemas grandes por sus
requerimientos de almacenamiento, que son lineales en tiempo y
espacio.
MRNet [29] es un software de capa superior para redes que
provee una interfaz genérica para operaciones eficientes multicast
y reducción para herramientas escalables. MRNet usa un árbol de
procesos entre una herramienta front-end y back-end para mejorar
la comunicación y reducir la perturbación. Esto nos permitiría
recolectar datos en tiempo de ejecución antes que post-mortem.
Nuestra idea es incorporarla en una versión futura usando la
herramienta de integración PNMPI[30].
SimPoint[28] detecta fases en las aplicaciones en bloques básicos
de vectores (BBVs). Provee alta precisión para medición de
arquitecturas.
TAU [32] y ompP[14] soporta perfilamiento de fases, el cual
captura la evolución de rendimiento a lo largo del tiempo con un
volumen aceptable de datos. De todos modos, nuestros datos son
menores, aunque los enfoques podrían ser complementarios.
7. CONCLUSIONES
El desbalanceo de carga es uno de los más importantes factores
limitantes en la escalabilidad de sistemas de gran escala en la
computación paralela. Por lo tanto, el entendimiento de su
impacto y fuente es un paso esencial para mejorar el rendimiento
de las aplicaciones. Los programas que recolectan datos a los
largo de la ejecución generalmente acumulan gran volumen de
datos, lo que hace inviable la implementación con enfoques
tradicionales.
En este paper, presentamos un novedoso enfoque al monitoreo de
grandes sistemas que logra la reducción de varios grados de
magnitud de los datos y tiempos sub-lineales (logarítmicos) de
mezcla, a pesar del tamaño del sistema. Introducimos un modelo
para cargas de alto nivel en aplicaciones SPMD que ayudaría en el
entendimiento de problemas de rendimiento. Usando agresivos
algoritmos de compresión pudimos reducir y juntar cargas
distribuidas y reducir cuellos de botellas significantes de E/S,
todo esto con un bajo nivel de errores y alta velocidad, inclusive
con altos niveles de compresión.
Demostramos con la utilización de dos aplicaciones: Raptor y
ParaDis, las cuales pudimos manejar eficientemente y capturar
información sobre la evolución del balance de la carga.
Demostramos también que con información del tiempo y el id del
proceso, el tamaño de los archivos crecía muy lentamente, por lo
tanto permite realizar medidas aún a mayor escala.
Mostramos con datos post-mortem que nuestra compresión
wavelet puede lograr tiempos de mezcla adecuado para el
monitoreo online de códigos de producción.
Estamos trabajando en como detectar el progreso en ciclos MPI
sin la necesidad de hacerlo de forma explícita. Planeamos
producir un framework completamente automático y transparente
para analizar eficientemente y optimizar el comportamiento del
balance de carga de cualquier código SPMD.
8. REFERENCIAS
[1] M. D. Adams. The JPEG-2000 still image compression
standard. Technical Report 2412, ISO/IEC JTC 1/SC
29/WG, December 2002.
[2] M. D. Adams and F. Kossentini. JasPer: a software-based
JPEG-2000 codec implementation. In Proceedings of the
International Conference on Image Processing, 2000.
[3] L.-M. Ang, H. N. Cheung, and K. Eshragian. EZW
algorithm using depth-first representation of the wavelet
zerotree. In Fifth International Symposium on Signal
Processing and its Applications (ISSPA), pages 75–78,
Brisbane, Australia, August 1999.
[4] S. Browne, J. Dongarra, N. Garner, G. Ho, and P. J.
Mucci. A portable programming interface for performance
evaluation on modern processors. The International
Journal of High Performance Computing Applications,
14(3):189–204, Fall 2000.
[5] H. Brunst, H.-C. Hoppe, W. E. Nagel, and M. Winkler.
Performance optimization for large scale computing: The
scalable VAMPIR approach. In Computational Science -
ICCS 2001, pages 751–760, May 2001.
[6] V. Bulatov, W. Cai, M. Hiratani, G. Hommes, T. Pierce,
M. Tang, M. Rhee, K. Yates, and T. Arsenlis. Scalable line
dynamics in ParaDiS. In Supercomputing 2004 (SC’04),
2004.
[7] M. Casas, R. M. Badia, and J. Labarta. Automatic phase
detection of MPI applications. Parallel Computing:
Architectures, Algorithms, and Applications, 38:129–136,
2007.
[8] M. Casas, R. M. Badia, and J. Labarta. Automatic
structure extraction from MPI applications. In European
Conference on Parallel Computing (Euro-Par), pages 3–12,
2007.
[9] M. Casas, R. M. Badia, and J. Labarta. Automatic
analysis of speedup of MPI applications. In International
Conference on Supercomputing (ICS), pages 349–358, Kos,
Greece, June 7-12 2008.
[10] P. Colella, D. T. Graves, D. Modiano, D. B. Serafini, and
B. v. Straalen. Chombo software package for AMR
applications. Technical Report (Lawrence Berkeley
National Laboratory), 2000. Available from:
http://seesar.lbl.gov/anag/chombo.
[11] I. Daubechies. Ten Lectures on Wavelets. SIAM: Society
for Industrial and Applied Mathematics, 1992.
[12] L. De Rose and D. A. Reed. SvPablo: A multi-language
architecture-independent performance analysis system. In
International Conference on Parallel Processing, 2000.
[13] P. Deutsch and J.-L. Gailly. ZLIB compressed data format
specification version 3.3. RFC 1950, Internet Engineering
Task Force, May 1996.
[14] K. F¨urlinger and M. Gerndt. ompP: A profiling tool for
OpenMP. In Proceedings of the First International
Workshop on OpenMP (IWOMP), 2005.
[15] A. Gara, M. A. Blumrich, D. Chen, G. L.-T. Chiu,
P. Coteus, M. E. Giampapa, R. A. Haring, P. Heidelberger,
D. Hoenicke, G. V. Kopcsay, T. A. Liebsch, M. Ohmacht,
B. D. Steinmacher-Burow, T. Takken, and P. Vranas.
Overview of the Blue Gene/L system architecture. IBM
Journal of Research and Development, 49(2/3), 2005.
[16] J. Greenough, A. Kuhl, L. Howell, A. Shestakov,
U. Creach, A. Miller, E. Tarwater, A. Cook, and B. Cabot.
Raptor – software and applications for BlueGene/L. In
BlueGene/L Workshop. Lawrence Livermore National
Laboratory, 2003. Available from:
http://www.llnl.gov/asci/platforms/bluegene/agenda.html.
[17] D. A. Huffman. A method for the construction of
minimum-redundancy codes. Proceedings of the Institute of
Radio Engineers, 40(9):1098–1101, September 1952.
[18] T. Huffmire and T. Sherwood. Wavelet-based phase
classification. In PACT’06, pages 95–104, September 16-20
2006.
[19] R. Kutil. Approaches to zerotree image and video coding
on MIMD architectures. Parallel Computing,
28(7-8):1095–1109, August 2002.
[20] S. Louis and B. R. de Supinski. BlueGene/L: Early
application scaling results. In NNSA ASC Principal
Investigator Meeting & BG/L Consortium System
Software Workshop, February 2005. Available from:
http://www-unix.mcs.anl.gov/ beckman/bluegene/
SSW-Utah-2005/BGL-SSW22-LLNL-Apps.pdf.
[21] A. D. Malony and W. E. Nagel. The open trace format
(OTF) and open tracing for HPC. In SC ’06: Proceedings
of the 2006 ACM/IEEE conference on Supercomputing,
page 24, New York, NY, USA, 2006. ACM.
[22] X. Martorell, N. Smeds, R. Walkup, J. R. Brunheroto,
G. Alm´asi, J. A. Gunnels, L. De Rose, J. Labarta,
F. Escal´e, J. Gimenez, H. Servat, and J. E. Moreira. Blue
Gene/L performance tools. IBM Journal of Research and
Development, 49(2-3):407–424, 2005.
[23] J. Mellor-Crummey. HPCToolkit: Multi-platform tools for
profile-based performance analysis. In 5th International
Workshop on Automatic Performance Analysis (APART),
November 2003.
[24] MPI Forum. MPI: A message passing interface standard.
International Journal of Supercomputer Applications and
High Performance Computing, 8(3/4):159–416, 1994.
[25] O. M. Nielsen and M. Hegland. Parallel performance of fast
wavelet transforms. International Journal of High Speed
Computing, 11(1):55–74, 2000.
[26] M. Noeth, F. Mueller, M. Schulz, and B. R. de Supinski.
Scalable compression and replay of communication traces
in massively parallel environments. In International
Parallel and Distributed Processing Symposium (IPDPS),
March 26-30 2007.
[27] Paradyn Project, Madison, WI. DynStackwalker
Programmer’s Guide, July 13 2007. Version 0.6b. Available
from: http://ftp.cs.wisc.edu/pub/paradyn/releases/
current release/doc/stackwalker.pdf.
[28] E. Perelman, M. Polito, J.-Y. Bouget, J. Sampson,
B. Calder, and C. Dulong. Detecting phases in parallel
applications on shared memory architectures. In
International Parallel and Distributed Processing
Symposium (IPDPS), 2006.
[29] P. C. Roth, D. C. Arnold, and B. P. Miller. MRNet: A
software-based multicast/reduction network for scalable
tools. In Supercomputing 2003 (SC03), 2003.
[30] M. Schulz and B. R. de Supinski. PNMPI tools: A whole
lot greater than the sum of their parts. In Supercomputing
2007 (SC’07), 2007.
[31] J. M. Shapiro. Embedded image coding using zerotrees of
wavelet coefficients. IEEE Transactions on Signal
Processing, 41(12):3445–3462, December 1993.
[32] S. Shende and A. Maloney. The TAU parallel performance
system. International Journal of High Performance
Computing Applications, 20(2):287–331, 2006.
[33] B. Sprunt. Pentium 4 performance-monitoring features.
IEEE Micro, pages 64–71, 2002.
[34] R. S. Wagner, R. G. Baraniuk, S. Du, D. B. Johnson, and
A. Cohen. An architecture for distributed wavelet analysis New York, NY, USA, 2006. ACM Press.
and processing in sensor networks. In Information [35] D. F. Walnut. An Introduction to Wavelet Analysis.
Processing in Sensor Networks (IPSN06), pages 243–250, Birkh¨auser Boston, 2004.