Simulador de memorias cach en Multiprocesadores:

LIMES
(Manual de Usuario)

Arquitectura de Computadores

Indice General
1 Introduccin a LIMES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Estructura de la simulacin. . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Aspectos previos a la simulacin. . . . . . . . . . . . . . . . . . . . . 4 3.1 Simuladores y protocolos de Limes. . . . . . . . . . . . . . . . . . . 4
3.1.1 El simulador Ideal 3.1.2 El simulador color 3.1.3 Protocolos Snoopy (WIN, WTI, Berkeley, Dragon) 3.2 Simulacin en sistemas de memoria Ideal / Realista. . . . . . . . .7 3.3 rbol de directorios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Archivo de configuracin makefile: variables y comandos. .9

4 Proceso de Simulacin: . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 4.1 Parmetros de simulacin. . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Casos de estudio: FFT, LU y OCEAN. . . . . . . . . . . . . . . . . 14 5 Anlisis de resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 5.1 Tasa de fallos de coherencia y de capacidad. . . . . . . . . . . . .16 5.2 Formato de tablas de resultados. . . . . . . . . . . . . . . . . . . . . 17 5.3 Grficas de ejemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Apndice: Presentacin de resultados . . . . . . . . . . . . . . . . . . .21

Limes: Manual de usuario

1. Introduccin a LIMES
Limes es una herramienta de simulacin de multiprocesadores de memoria compartida que funciona sobre PCs con procesadores i486 o superiores con al menos 8 MB de RAM bajo el S.O. Linux, necesitando tener en un directorio los archivos GCC 2.6.3. Limes simula el comportamiento de P procesadores con K KB de memoria cach distribuida en bloques de T Bytes, en N vas, ejecutando una aplicacin paralela, aunque realmente se realice en una mquina monoprocesador, nuestra mquina. De esta manera podemos evaluar, mediante una aplicacin paralela implementada en cdigo C o C++, el comportamiento de una determinada arquitectura multiprocesador definida mediante los parmetros nombrados anteriormente.

De forma general LIMES tiene 2 aplicaciones principales: Estudios de evaluacin de arquitecturas: Una aplicacin importante de Limes es el hecho de poder analizar el comportamiento de diferentes arquitecturas ante un determinado programa paralelo. Para ello lo que debemos hacer es evaluar el comportamiento de diferentes arquitecturas sobre el mismo programa C o C++, para as obtener resultados objetivos y analizar cual de las configuraciones evaluadas obtiene mejor rendimiento. Si repetimos este proceso con varios programas paralelos fijos, ms realistas sern las conclusiones obtenidas, pues mayor ser el muestreo utilizado y se evitarn dependencias de la arquitectura respecto a la aplicacin C/C++.

Evaluacin de algoritmos paralelos: Otra aplicacin que tiene Limes es la

evaluacin de la calidad de algoritmos de procesamiento paralelo. Para ello lo que debemos hacer es fijar los parmetros de una arquitectura determinada, y sobre ella evaluar los diferentes algoritmos paralelos, para a partir de los resultados devueltos por Limes evaluar el rendimiento de los mismos. Si repetimos este proceso sobre otra configuracin de arquitectura y sobre ella volvemos a evaluar los mismos algoritmos paralelos, podemos comparar los resultados obtenidos con los del caso anterior, y podemos de esta manera ir tomando mas muestras lo que revertir en unas conclusiones ms certeras y objetivas acerca de la calidad de los algoritmos evaluados

Arquitectura de Computadores

2. Estructura de la simulacin
Un aspecto importante antes de comenzar a explicar el funcionamiento del simulador es exponer la organizacin de dicho proceso de simulacin: Por una parte tenemos una aplicacin paralela creada para ejecutarse en un sistema con N procesadores, con lo cual idealmente debera ejecutarse N veces ms rpido que en un procesador simple. Esta ser pues la parte de cdigo paralelo a evaluar. Por otra parte tenemos el simulador de la arquitectura. Limes permite elegir entre un sistema de memoria ideal, donde el sistema asume que las lecturas y escrituras se realizan en un solo ciclo o alguno de los protocolos snoopy de coherencia de cach. Los protocolos snoppy estn basados en bus como veremos posteriormente. Por ltimo tenemos el kernel de la simulacin que est situado entre la aplicacin y el simulador de la arquitectura propuesta. Es responsabilidad del kernel llamar con eventos al simulador de memoria actual. El esquema general de funcionamiento del sistema que expresa la relacin existente entre la aplicacin, el simulador y el kernel es el siguiente:

Aplicacin a evaluar

Kernel de simulacin

Simulador de la arquitectura propuesta

Figura 1: Relacin entre la aplicacin, el kernel y el simulador.

Con este diagrama parece mas claro el funcionamiento de la simulacin y la funcionalidad del kernel de simulacin: se encarga de ejecutar hilos (threads) de la aplicacin con total control sobre la ejecucin y de medir el tiempo de ejecucin de cada hilo en ciclos de reloj del procesador. Siempre que un hilo intenta realizar una operacin entra en modo kernel, y entonces se realiza la planificacin. En cierta manera existe una gran analoga entre el kernel del simulador y el kernel de Unix, ya que ambos controlan la ejecucin de los procesos y en el caso de Limes las operaciones de memoria mediante hilos(threads) se pueden ver como llamadas al sistema.

Limes: Manual de usuario

3. Aspectos previos a la simulacin

Limes cuenta con diversas opciones que permiten realizar simulaciones bajo diversas configuraciones, gracias a lo cual se consigue una gran flexibilidad de simulaciones. As tenemos 3 tipos de simuladores, ideal, snoopy y color, con lo que Limes permite realizar simulaciones bajo diferentes protocolos de coherencia de cach como invalidacin y actualizacin. Veamos a continuacin las opciones de simulacin que ofrece Limes:

3.1 Simuladores y protocolos de Limes

Limes incluye un conjunto de simuladores sobre los cuales podremos evaluar el rendimiento de los diferentes programas. Especficamente incluye 3 simuladores, dentro de los cuales se pueden incluir diferentes protocolos de coherencia de cach. Veamos a continuacin con mas detenimiento cada uno de ellos: 3.1.1 El simulador Ideal: En el caso de que no especifiquemos lo contrario, este es el simulador por defecto que toma Limes. Este simula un sistema de memoria perfecto, esto es, con lecturas y escrituras completas en un ciclo, tras lo cual se realiza la operacin de UNLOCK (liberar el cerrojo). En el caso de que se requiera el cerrojo, o lo que es lo mismo se quiera realizar un LOCK(bloquear cerrojo), lo que ocurre es que si no est libre debe de esperar hasta que este se libere, momento en el cual se ocupa de nuevo. El kernel de Limes realiza un control del comportamiento de los bloqueos, pudiendo optimizar la simulacin. 3.1.2 El simulador color: Este simulador es muy parecido al Ideal. Su estructura es la misma, con la nica diferencia de que este se ha ampliado para mostrar los accesos de datos en la ventana terminal, utilizando un color diferente para cada procesador y representando las lecturas/escrituras de forma diferente. Por ello se puede considerar muy til para la visualizacin de acceso de datos. Para utilizar este simulador en Limes lo que debemos hacer es poner SIMHOME=color en el makefile y recompilarlo. 3.1.3 Protocolos Snoopy: Limes incluye un paquete con 4 protocolos snoopy de coherencia de cach, que se pueden utilizar en la simulacin. Mediante los protocolos snoopy se permite resolver problemas complicados mediante la interpretacin de eventos que ocurren de forma natural en el sistema mientras el procesador permanece inalterado. De esta manera las lecturas y escrituras se usan de forma implcita para mantener la coherencia de las cachs mientras que la serializacin del bus mantiene la consistencia. Limes incluye 4 simuladores snoopy: WIN(Word Invalidate): Protocolo snoopy basado en invalidacin parcial de palabra. WTI(Write-Through Invalidate): Es un protocolo de invalidacin de escritura.

Arquitectura de Computadores

Berkeley: Berkeley es un protocolo de coherencia de cache mediante invalidacin de escritura. Este protocolo tiene la estructura MESI, o lo que es lo mismo un protocolo de invalidacin de 4 estados, que es una mejora del protocolo MSI ya que incluye un estado intermedio entre compartido y modificado, obteniendo un mejor rendimiento que el MSI. Para que Limes tome el protocolo Berkley en la simulacin debemos especificarlo en el archivo makefile poniendo SIMHOME=snoopy SIM=ber y recompilarlo. El esquema general de funcionamiento de Berkeley es:

Figura 2: Diagrama de estados de Berkley

Esquemticamente el protocolo Berkley consiste en 4 estados:

Modificado(M): Este procesador tiene una copia vlida del bloque en su cach, y la

copia de memoria principal est anticuada y ninguna cach tiene una copia vlida.
Exclusivo(E): Solo esta cach tiene copia del bloque y no ha sido modificado. Compartido(C): El bloque esta en la cach y no ha sido modificado. Invalidado(I): Se encuentra en un estado de invalidacin (Valor del bloque no til)

Limes: Manual de usuario

Dragon: Si Berkeley es un protocolo de coherencia de cache basado en invalidacin, Dragon realizar la misma funcin, pero en este caso mediante actualizacin. Este protocolo es muy utilizado en las cachs post-escritura. Para que Limes tome el protocolo Dragon en la simulacin debemos especificarlo en el archivo makefile poniendo SIMHOME=snoopy / SIM=dra y recompilarlo. El esquema general de funcionamiento del protocolo Dragon es el siguiente:

Figura 3: Diagrama de estados de Dragon

Esquemticamente el protocolo DRAGON consiste en 4 estados:

Modificado(M): Este procesador tiene una copia vlida del bloque en su cach, y la

copia de memoria principal est anticuada y ninguna cach tiene una copia vlida. Exclusivo(E): Solo esta cach tiene copia del bloque y este no ha sido modificado. Compartido(SC): Potencialmente dos o ms procesadores tienen este bloque en su cach y la memoria principal puede estar o no actualizada. Compartido Modificado(SM): Potencialmente 2 o ms procesadores tienen el bloque en su cach, la memoria principal no est actualizada y este procesador se encarga de actualizar la memoria principal cuando este bloque sea reemplazado en cach.

Arquitectura de Computadores

3.2 Simulacin en sistemas de memoria Ideal / Realista

A la hora de realizar una simulacin con Limes, cabe la posibilidad de realizarla con un sistema de memoria ideal, es decir que el sistema asume que las lecturas y escrituras se completan en un solo ciclo. Este caso, como ideal que es, no es generalmente el que se suele utilizar, sino que en la mayora de las simulaciones se recurre a un sistema de memoria realista, donde se produzcan problemas de coherencia o consistencia y donde las lecturas / escrituras tarden en ejecutarse ms de 1 ciclo. En el caso de que queramos analizar el comportamiento de un algoritmo paralelo, puede que no sea inconveniente el hecho de simular sobre un sistema de memoria ideal, ya que representara una situacin utpica en la prctica totalidad de arquitecturas existentes. En todo caso el sistema ideal puede considerarse como una referencia a conseguir. As si simulamos el comportamiento de un algoritmo paralelo, podemos evaluar su rendimiento (speedup o utilizacin del bus) y compararlo con el del caso ideal. Para conseguir que Limes realice la simulacin utilizando un sistema de memoria ideal basta con omitir los parmetros SIM=.. & SIMHOME=.. del archivo makefile que veremos a continuacin. Si por el contrario queremos que Limes simule con un sistema de memoria real, por ejemplo el protocolo snoopy Berkeley, lo que debemos hacer es incluir en el makefile SIMHOME=snoopy & SIM=ber.

Nota: Existe la posibilidad de realizar simulaciones sin referencias de simulacin, es decir que no se generan trazas pero se obtiene una simulacin mucho ms rpida. Esto es til tambin en caso de querer investigar algoritmos paralelos que requieren un tiempo de ejecucin elevado.

Limes: Manual de usuario

3.3 rbol de Directorios

Antes de lanzarnos a realizar las simulaciones pertinentes, debemos conocer la estructura de directorios y archivos de Limes, la cual se muestra en la siguiente figura:

Figura 4: Arbol de directorios y archivos de LIMES

Una breve descripcin de estos directorios puede ser la siguiente: El directorio kernel contiene todos los archivos fuente del kernel El directorio aug contiene utilidades para el tratamiento del cdigo ensamblador de la aplicacin paralela que se est compilando. El directorio sync es el directorio raz de todas las implementaciones de primitivas de sincronizacin. Pueden ser de 2 tipos: Realistas y Abstractas. El directorio sys_stdlib incluye libreras de funciones para el tratamiento del cdigo El directorio simulators contiene los simuladores de sistemas de memoria que utiliza Limes, esto es: el Ideal, Color y los 4 snoopy vistos anteriormente. El directorio applications contiene 3 aplicaciones paralelas SPLASH-2 y una aplicacin tpica simple. El subdirectorio javalike contiene la implementacin de hilos de C++ en su equivalente en JAVA. El directorio lib es el lugar donde los resultados intermedios de compilaciones anteriores son almacenados para aumentar la velocidad de compilacin.

10

Arquitectura de Computadores

3.4 Archivo de configuracin makefile: variables y comandos

A la hora de realizar una simulacin debemos tener mucho cuidado con el lugar desde donde nos disponemos a realizarla y al archivo makefile que utilizamos. Hay que considerar el hecho de que cada aplicacin que queramos simular debe tener un archivo makefile, el cual determina los parmetros caractersticos de la simulacin a realizar. Tambin hay que tener en cuenta que tras modificar el archivo makefile es necesario compilarlo para que los cambios efectuados tengan efecto. Los comentarios se ponen tras almohadillas. El archivo makefile debe tener al menos la siguiente informacin:

APPCS=<lista de archivos C que forman la aplicacin> APPCS= factorial.c TARGET=<nombre del archivo ejecutable> TARGET=FACTO include $(LIMESDIR)/all.make include $(LIMESDIR)/all.make

Sin embargo hay que indicar que normalmente el archivo de configuracin makefile suele tener ms variables y consecuentemente ser ms extenso. Variables permitidas: APPCS: Define la lista de mdulos C que definen la aplicacin a evaluar. APPCCFLAGS: Define banderas o flags para pasar el programa a compilacin. Normalmente utilizaremos la opcin -O2 con la cual obtendremos mxima optimizacin. Otra opcin es utilizar la bandera g que har que el compilador de d informacin de depuracin. APPLDFLAGS: Especifica las banderas o flags de la aplicacin que debern pasar al linkador. As, utilizaremos la opcin -lm para la librera matemtica. AUGFLAGS: Especifica el nivel de instrumentacin. Limes permite 3 niveles de instrumentacin: nivel 0(-0), nivel 1(-1) y nivel 2(-2): Nivel 0: Solo se trataran la sincronizacin y las instrucciones definidas por la mquina. Este nivel de instrumentacin es til en el caso de que investiguemos algoritmos que utilicen cerrojos para proteger secciones crticas. Nivel 1: Tiene la misma funcionalidad que el nivel 0 aadiendo el tratamiento de lecturas y escrituras compartidas. Este es el nivel por defecto. Nivel 2: En este nivel se tratan todos los aspectos incluyendo los accesos a datos locales y a pila. Debemos utilizar este nivel para simular el sistema con todo lujo de detalles, caso por ejemplo de simular cachs.

Limes: Manual de usuario

11

SYNC: Especifica la poltica de sincronizacin. Esta puede ser de 3 tipos: SYNC=realistic: Mediante esta poltica de sincronizacin, la respuesta que se debe dar ante la adquisicin o liberacin de cerrojos se pasa a la memoria del simulador. As, cuando se realiza una operacin LOCK en el archivo fuente, esta es reemplazada por una llamada al kernel que prepara la respuesta para la memoria del simulador; lo mismo ocurre en el caso del UNLOCK.

SYNC=abstract: Este modelo es til en el caso de evaluar algoritmos donde

no se simule el hardware. El esquema de funcionamiento es el siguiente: en el caso de que un hilo realice un LOCK, si este est libre continua; pero si est ocupado, el hilo pasa a un estado BLOCKED, y aade su identificador a la cola asociada a LOCK. Cuando se realiza un UNLOCK el primer proceso que estaba en la cola toma el cerrojo y pasa a estado READY. Las barreras se implementan de igual forma que los cerrojos.

SYNC=implementacin_propia: En el caso de que implementemos una

poltica de sincronizacin diferente la marcamos con el nombre que esta tenga. As, si nosotros diseamos una poltica propia, podemos probarla y comparar el rendimiento obtenido frente a la realista o la abstracta. TARGET: Especifica el nombre del archivo ejecutable. SIM, SIMHOME: Estas variables especifican respectivamente el nombre y la localizacin del simulador utilizado, relativo al directorio /limes/simulator. Si estas variables se omiten se entiende que se asume un sistema de memoria ideal. Si especificamos SIM pero omitimos SIMHOME Limes tomar por defecto el directorio limes/simulator/$(SIM). Normalmente se utiliza SIMHOME en el caso de que haya varios simuladores dentro de un mismo directorio. ALGEVALONLY: Activa las referencias de simulacin permitidas pero preservando un orden correcto para lecturas y escrituras. En el caso de poner ALGEVALONLY=1 en el makefile, se realizar una simulacin mucho ms rpida. Esto es interesante si estamos evaluando algoritmos paralelos donde no nos interesa la estructura del hardware.

12

Arquitectura de Computadores

Una vez analizadas las variables del archivo de configuracin makefile, lo ms adecuado es ver algunos ejemplos de archivos makefile, por lo que incluimos los de las aplicaciones FFT, LU y OCEAN, que veremos con mas detenimiento posteriormente:

FFT

APPCS = fft.c # Lista de archivos C que componen la aplicacin APPCCFLAGS = -O2 # Banderas CC. Poner -g si se quiere mas informacin SIM = ber # Estamos utilizando el protocolo de invalidacin Berkeley SIMHOME = snoopy # Estamos definiendo una simulacin snoopy #si omitimos SIM y SIMHOME se realizar una simulacin Ideal. AUGFLAGS = -1 #=-2Adems preferencias privadas / = 0solo sincronizacin ALGEVALONLY = 1 #incluimos referencias en la simulacin TARGET= FFT #FFT es el nombre del archivo ejecutable APPLDFLAGS= -lm #banderas para el linkador include $(LIMESDIR)/all.make

LU

# Lista de archivos C que componen la aplicacin # Banderas CC. Poner -g si se quiere mas informacin # Estamos utilizando el protocolo de actualizacin Dragon # Estamos definiendo una simulacin snoopy #si omitimos SIM y SIMHOME se realizar una simulacin Ideal. AUGFLAGS = -1 #Si: -2Adems preferencias privadas / Si: 0 solo sincronizacin #ALGEVALONLY = 1 #entre almohadillasNo queremos incluir referencias de simulacin TARGET = LU #LU es el nombre del archivo ejecutable APPLDFLAGS= -lm #banderas para el linkador include $(LIMESDIR)/all.make

APPCS= lu.c APPCCFLAGS = -O2 SIM = dra SIMHOME= snoopy

APPCS= main.c jacobcalc.c jacobcalc2.c laplacalc.c linkup.c multi.c slave1.c slave2.c subblock.c # Lista de archivos C que componen la aplicacin APPCCFLAGS = -O2 # Banderas CC. Poner -g si se quiere mas informacin SIM = ocean # Estamos utilizando el protocolo de actualizacin Ocean SIMHOME= snoopy # Estamos definiendo una simulacin snoopy #si omitimos SIM y SIMHOME se realizar una simulacin Ideal. OCEAN AUGFLAGS = -1 # Si:-2Adems preferencias privadas/Si: 0solo sincronizacin #ALGEVALONLY = 1 # entre almohadillas No queremos incluir referencias de simulacin. TARGET = OCEAN #OCEAN es el nombre del archivo ejecutable APPLDFLAGS= -lm #banderas para el linkador include $(LIMESDIR)/all.make

Figura 5: Tabla de archivos makefile para la simulacin con protocolos snoopy.

Limes: Manual de usuario

13

A parte de las variables del archivo makefile debemos tener en cuenta que adems Limes proporciona otros comandos relacionados con el makefile. Esto es muy importante sobre todo a la hora de modificarlo porque si no tenemos cuidado puede ocurrir que dichos cambios no tengan efecto. Para realizar un cambio de configuracin en makefile lo que debemos hacer es modificarlo y posteriormente compilarlo con make. El proceso que sigue Limes cuando realiza un make es:

COMPILAR LA SIMULACION

* Transforma la aplicacin C/C++ a cdigo ensamblador * Se trata el cdigo ensamblador * Compila el cdigo ensamblador y almacena el cdigo objeto en un archivo

LLAMADA AL MAKEFILE DEL KERNELkernel.a(contiene

archivos objeto del kernel)

LLAMADA AL MAKEFILE DEL SIMULADOR

$(SIM).a (archivos objeto del simulador)

LINKAR TODOS LOS ARCHIVOS DENTRO DEL EJECUTABLE $(TARGET)

Figura 6: Proceso interno del simulador tras realizar un make

En algunas ocasiones antes de realizar un make, es necesario borrar los archivos generados en compilaciones anteriores. Lo ms sano tras realizar una modificacin en el archivo makefile de la aplicacin correspondiente, es limpiar los archivos generados en simulaciones anteriores. Algunos comandos tiles para esto son los siguientes: make dep: Se utiliza cuando se quieren editar los archivos fuentes del simulador. make clean: Limpia todos los archivos de la aplicacin y del simulador. make simclean: Limpia solamente los archivos del simulador. Por ejemplo, es til si queremos realizar una simulacin con dragon, tras una con berkeley. make appclean: Limpia todos los archivos intermedios de la aplicacin, esto es tanto cdigo objeto como cdigo ensamblador. make kerclean: Limpia los archivos intermedios del kernel. make syncclean: Limpia todos los archivos objeto de sincronizacin. make libclean: Limpia el directorio limes/lib. make totalclean: Limpia todo. Este es el comando que se debe utilizar siempre que queramos evitar complicaciones. Es lo mas sano para evitar problemas. Como conclusin podemos aconsejar que tras modificar el makefile de la aplicacin paralela en cuestin, lo que debemos hacer es utilizar alguno de estos comandos de limpieza, preferiblemente make totalclean, para posteriormente ejecutar make.

14

Arquitectura de Computadores

4. Proceso de Simulacin
Una vez vistos los aspectos generales que debemos tener en cuenta a la hora de realizar una simulacin, nos encontramos en disposicin de realizar una simulacin. Para ello debemos tener en cuenta que Limes a parte de las configuraciones vistas anteriormente, ofrece un conjunto de parmetros directos de simulacin. Una vez que hemos modificado el archivo de configuracin general makefile debemos compilarlo para que este tenga efecto real, por lo que ejecutamos el comando make habiendo realizado un make totalclean o similar. Es entonces cuando se crea el archivo ejecutable, y el momento en el cual podemos comenzar por fin la simulacin.

4.1 Parmetros de simulacin

Los parmetros que debemos ejecutar en la simulacin dependen de la aplicacin en cuestin, aunque genricamente Limes permite las siguientes opciones: -t: Produce un archivo de traza de la simulacin. -s: Estadsticas de los threads: Tras finalizar la simulacin, esta opcin muestra las estadsticas generales de hilos(threads), tales como nmero de lecturas y escrituras compartidas y privadas, cerrojos, barreras, tiempo total y el porcentaje de tiempo gastado en la sincronizacin. Hay que indicar que al incluir esta opcin implica incrementar el tiempo de simulacin en un 5% aproximadamente. -e: Esta opcin fuerza la salida a stderr en vez de a stdout, que es por defecto. -i <archivo de inicializacin>: Existen 2 formas de especificar los parmetros de inicializacin mediante un archivo: Mediante el archivo de configuracin limes.ini o mediante el archivo de configuracin especificado mediante esta opcin. En estos archivos se debe especificar el tamao de la cach, el n de vas y el tamao del bloque utilizado. Para ello se utiliza la siguiente sintaxis de asignacin: ITEM=VALUE. Un ejemplo de la asignacin de los parmetros de inicializacin dentro del archivo de inicializacin X.ini es el siguiente: ............. cache_size=16 #16 KB de cach cache_way=8 #8 vas cache_line_size=16 #Lineas de 16 bytes ............. En el caso de que no se especifique el archivo limes.ini ni otro que lo sustituya mediante esta opcin, el simulador utilizar la definicin por defecto:
Tamao de la cach=8KB, Tamao de linea=32 bytes, Numero de Vias=2

,excepto que se inicialicen de forma directa como se especifica a continuacin. dITEM =VALUE: Para definir los parmetros de inicializacin podemos hacerlo creando el archivo_incializacin.ini, como indicamos en el apartado anterior, o asignando estos valores de forma directa al lanzar la simulacin. En este caso deberemos incluir en la lnea de comandos la siguiente sintaxis de asignacin: dITEM=VALUE. En este caso sirva este ejemplo:
FFT l4 n2048 p1 s -- -dcache_size=16 -dcache_way=8 -dcache_line_size=16
#Es decir que simulamos la aplicacin FFT con 16KB de cach, 8 vas y lineas de 16 bytes

Limes: Manual de usuario

15

4.2 Casos de estudio: FFT, LU y OCEAN

Una vez especificados los parmetros generales a la hora de lanzar la simulacin, hay que tener en cuenta que dependiendo del tipo que aplicacin que vayamos a ejecutar, esta puede requerir unos parmetros diferentes. Para ello nos vamos a centrar en 3 aplicaciones que Limes incluye 3 aplicaciones (FFT, LU y OCEAN) que podemos paralelizar mediante un sistema multiprocesador de memoria compartida. Debido a que todas ellas tienen caractersticas especficas lo que debemos hacer verlas por separado: FFT:Transformada rpida de Fourier en 1 dimensin utilizando el mtodo de 6 fases Esta aplicacin incluye los siguientes parmetros especficos:
-mM : M = Nmero entero. 2^M es el total de puntos a transformar (10 por defecto) -pP : P = Nmero de procesadores, siempre potencia de 2 (1 por defecto) -nN : N = Nmero de lneas de cach -lL : L = Logaritmo en base 2 del tamao de bloque de cach -s : Muestra las estadsticas de tiempos individuales de los procesadores -t : Ejecuta adems de la FFT, la FFT inversa -o : Muestra los puntos de datos complejos -h : Muestra las opciones de la lnea de comandos

La mejor forma de comprender esta marejada de opciones es mediante un ejemplo:

FFT m12 p4 n2048 l5 -- -dcache_size=64 -dcache_way=8 -dcache_line_size=32

Con lo que tenemos una simulacin donde vamos a transformar 2^12 puntos, mediante 4 procesadores, en 2048 lneas de cach, con tamao de 64 KB con bloques de 32 bytes y 8 vas, y adems muestra las estadsticas de los 4 procesadores.

LU: Descomposicin LU de una matriz(LU) Esta aplicacin cuenta con los siguientes parmetros de simulacin:
-nN : Vamos a realizar la descomposicin LU de una matriz de tamao NxN (128 por defecto) -pP : P = Nmero de procesadores. Siempre potencias de 2 (1 por defecto) -bB : Se utiliza un tamao de bloque de B bytes (tamaos de 8 o 16 bytes son buenos) -s : Imprime las estadsticas de tiempos individuales de los procesadores -t : Test de salida -o : Muestra los valores de la matriz -h : Muestra las opciones de la lnea de comandos

Un ejemplo que muestra el lanzamiento de la simulacin LU puede ser:

LU n64 p8 -b16 -- -dcache_size=32 -dcache_way=8 -dcache_line_size=16

Con lo que tenemos una simulacin donde el tamao de la matriz es 64x64, evaluado mediante 8 procesadores, con una cach de tamao 32 KB con bloques de 16 bytes y 8 vas y mostrando las estadsticas de los procesadores adems de los valores de la matriz.

16

Arquitectura de Computadores

OCEAN: Estudio del rol de los remolinos y el limite de las corrientes en los movimientos ocenicos a gran escala (OCEAN). En la aplicacin Ocean los parmetros de simulacin son los siguientes:
-nN : El tamao de la malla es NxN, siendo N potencia de 2+2 (130 por defecto) -pP : P = Nmero de procesadores. Siempre potencias de 2 (1 por defecto) -eE : E = Error tolerado para el relajamiento iterativo (1e-7) -rR : R =Distancia entre regiones en metros (20000.0 por defecto) -tT : T =Tiempo entre pasos en segundos (28800.0 por defecto) -s : Muestra las estadsticas de tiempos -o :Muestra los valores residuales de la relajacin -h : Muestra las opciones de la lnea de comandos.

Un ejemplo de simulacin OCEAN puede ser el siguiente:

OCEAN n66 p16 -e1e-4 r12000.0 t15000.0 -- dcache_size=32 -dcache_way=8 -dcache_line_size=16

Con lo que tenemos una simulacin donde el tamao de la malla es 66x66, evaluado mediante 16 procesadores, con una cach de tamao 32 KB con bloques de 16 bytes y 8 vas, permitiendo un error de 10^-4, con una distancia entre regiones de 12000 metros, con 15000 segundos entre pasos y mostrando las estadsticas de tiempos.

Es tambin muy interesante llevar los datos devueltos por la simulacin a un archivo de salida, para despus de haber realizado un conjunto de simulaciones poder analizar con mas detenimiento los resultados obtenidos y obtener conclusiones a partir de estos. Para ello tenemos contamos con dos opciones igualmente vlidas: Redireccionar con >>
FFT m12 p4 -- -dcache_size=16 -dcache_way=8 -dcache_line_size=32 >> salida

Utilizar la opcin |tee:

FFT m12 p4 -- -dcache_size=16 -dcache_way=8 -dcache_line_size=32|tee salida

Limes: Manual de usuario

17

5. Anlisis de resultados
Una vez que hemos realizado las simulaciones necesarias para el estudio en cuestin, debemos analizar los resultados obtenidos para a partir de ellos obtener conclusiones. En el caso de que estemos evaluando el rendimiento de algoritmos paralelos, podemos hacerlo a partir de datos globales como el tiempo de ejecucin del algoritmo o el % de uso del bus, ya que los evaluaremos bajo la misma configuracin. Pero si estamos evaluando el rendimiento de un sistema multiprocesador nos tendremos que fijar adems en factores como la Tasa de fallos de capacidad(%) o Tasa de fallos de coherencia(%).

5.1 Tasa de fallos de coherencia y capacidad

El tiempo total de ejecucin, el Speedup y la utilizacin del bus se obtienen directamente a partir de los datos obtenidos en la simulacin, pero dependiendo del protocolo de coherencia de cach que estemos utilizando, la forma de calcular el valor exacto de la Tasa de fallos de capacidad y la Tasa de fallos de coherencia vara. As por ejemplo si utilizamos el protocolo de invalidacin Berkeley tenemos que:
replacemen t Tasa _ fallos _ capacidad = request

invalidation Tasa _ fallos _ coherencia = request

Mientras que por el contrario si utilizamos el protocolo de actualizacin Dragon:

replacemen t Tasa _ fallos _ capacidad = request

T _ f _ coherencia = T _ f _ actualizacin _ bloques + T _ f _ actualizacin _ paginas donde : wbrd T _ f _ actualizacin _ bloques = request wupg T _ f _ actualizacin _ paginas = request

Para ambos casos la Tasa_fallos_Total=Tasa_fallos_capacidad+Tasa_fallos_coherencia

18

Arquitectura de Computadores

5.2 Formato de tablas de resultados

Un buen mtodo para encontrar las mejores configuraciones posibles es ir dejando parmetros de la arquitectura fijos e ir modificando otros, para ver donde se encuentran los problemas y en que sitios el hecho de incrementar la cache, no implica una mejora sensible de rendimiento. Algunos casos de estudio pueden ser: Modificar el nmero de procesadores y dejar fijo el resto de parmetros con lo cual veremos a partir de que valor el hecho de incrementar el nmero de procesadores no implica un aumento significativo en el rendimiento global. As en este caso una posible estructura de evaluacin pudiera ser la siguiente tabla:
P1 Tasa_fallos_capacidad(%) Tasa_fallos_coherencia(%) Tiempo_Total Tasa_fallos_total(%) Speedup Utilizacin_Bus(%) P2 P4 P8 P16

Tabla 1: Evaluacin de diversos factores de rendimiento en funcin del nprocesadores

Modificar el tamao de la cach, hasta encontrar el punto a partir del cual el hecho de incrementar el tamao de la cach no revierte en una mejora de rendimiento global de cierta importancia. En este caso una posible estructura de evaluacin puede ser la que muestra la siguiente tabla:
8KB Tasa_fallos_capacidad(%) Tasa_fallos_coherencia(%) Tiempo_Total Tasa_fallos_total(%) Speedup Utilizacin_Bus(%) 16KB 32KB 64KB 128KB

Tabla 2: Evaluacin de diversos factores de rendimiento en funcin del tamao de la cach

Igualmente podemos jugar con factores como el nmero de vas o el tamao de los bloques de cach, para comprobar su relacin coste vs mejora de rendimiento.

A partir de la informacin agrupada en estas tablas, podemos realizar grficas que muestren la calidad y rendimiento de las configuraciones y a partir de ellas obtener cuales son las que consiguen una mejor relacin calidad vs coste.

Nota: Evidentemente se pueden incrementar indefinidamente las caractersticas de la arquitectura, pero esto no es factible cuando esto no conlleve una mejora del rendimiento significativa que pudiera justificar una configuracin tan costosa.

Limes: Manual de usuario

19

5.3 Grficas de ejemplo

Como conclusin, podemos mostrar un conjunto de grficas que muestran el comportamiento de diferentes configuraciones a partir de resultados obtenidos empricamente tras realizar diversas simulaciones:
Tasa de fallos de capacidad y coherencia en FFT (Nmero de procesadores variable)

8% 7% 6% 5% 4% 3% 2% 1% 0%
1 2 4 8 16 Nmero de procesadores Tasa de fallos de coherencia Tasa de fallos de capacidad

Grfica 1: Tasa de fallos en funcin del n procesadores, ej: FFT

Tasa de fallos de capacidad y coherencia en OCEAN (tamao de cach variable)

20% 18% 16% 14% 12% 10% 8% 6% 4% 2% 0% 16 32 64 128 256

Tamao de la cache(KB) Tasa de fallos de coherencia Tasa de fallos de capacidad

Grfica 2: Tasa de fallos en funcin del tamao de la cach, ej: OCEAN

Tasa de fallos de capacidad y coherencia en LU (Tamao de bloque variable)

3,5% 3,0% 2,5% 2,0% 1,5% 1,0% 0,5% 0,0% 16 32 64 128 256
Tamao de bloque Tasa de fallos de coherencia Tasa de fallos de capacidad

Grfica 3: Tasa de fallos en funcin del tamao de bloque ej: LU

20

Arquitectura de Computadores

Tasa de fallos total en funcion del uso del bus al variar el tamao de bloque(OCEAN,dra)

14% 12% 10% 8% 6% 4% 2% 0%

0
16 bytes

20

40

60

80
128 bytes

100

Uso del bus( % ) 32 bytes 64 bytes

Grfica 4: Tasa de fallos en funcin de la utilizacin del bus ej: OCEAN

SpeedUp en Ocean con Berkeley (nmero procesadores variable)

6 5 4 3 2 1 0
1 2 4 8 Nmero de procesadores SpeedUp 16

Grfica 5: SpeedUp obtenido en funcin del n de procesadores ej: OCEAN

Mejora SpeedUp

Limes: Manual de usuario

21