ARQUITECTURA DE SISTEMAS PARALELOS I. 4º INGENIERÍA INFORMÁTICA. PRÁCTICA 4. PLANIFICACIÓN DINÁMICA: EL ALGORITMO DE TOMASULO. 1. OBJETIVOS.

Transcripción

1 ARQUITECTURA DE SISTEMAS PARALELOS I. 4º INGENIERÍA INFORMÁTICA. PRÁCTICA 4. PLANIFICACIÓN DINÁMICA: EL ALGORITMO DE TOMASULO. 1. OBJETIVOS. En esta práctica vamos a estudiar una técnica de scheduling dinámico (gestión, reordenamiento o planificación de instrucciones), propuesta originalmente en 1967, para procesadores distribuidos y del cual hoy día se usan diversas variantes en la mayoría de los microprocesadores avanzados: el algoritmo de Tomasulo. Se obtendrán las prestaciones para la ejecución de un pequeño bucle. Se manejará un simulador (DLXview, de libre distribución) del procesador didáctico encadenado DLX, que aparte de la cadena básica del DLX, simula muy fielmente dos algoritmos de scheduling dinámico (el del marcador o "scoreboard" y el de Tomasulo). 2. PREPARACIÓN. Este simulador del procesador DLX, tiene algunas diferencias con el WINDLX usado hasta ahora: Tiene tres modos posibles de encadenar instrucciones, que pueden elegirse en la configuración: 1. Basic Pipeline (cadena básica, sin scheduling dinámico pero con todos los bypasses). Es similar a la del WINDLX, mostrando el detalle electrónico del flujo de datos de la unidad de datos entera, aunque no informa en el cronograma de la causa de un bloqueo. En la cadena básica, al ser un simulador orientado a instrucciones FP, DLXview permite que existan varias instrucciones en las fases MEM y WB, es decir supone que la unidad de control soporta dos fases MEM y que hay un puerto de escritura para el fichero de registros entero y otro para el de flotantes. Cuidado! En este modo el simulador comete algunos errores en el cronograma de instrucciones que acceden a memoria. Por ese motivo es preferible usar WINDLX para la cadena básica. 2. Marcador centralizado o ScoreBoard (scheduling dinámico). No lo vamos a usar. 3. Tomasulo (scheduling dinámico). Se explica a continuación. Otras peculiaridades a tener en cuenta de este simulador son: No muestra en ninguna ventana el contenido de los registros ni de la memoria, aunque esté simulando perfectamente sus valores. Para validar los resultados de los programas que escriba el alumno debe utilizar los comandos en línea de la shell donde se invocó al DLXview (comandos get y put que se explican en la sección de "realización de la práctica"). Aunque algunas directivas varíen, las que se necesitan para programas simples son idénticas al WINDLX, y los programas de uno sirven para el otro. Todas las instrucciones mult y div requieren que sus operandos sean registros FP como está definido en el DLX original. Por tanto, si se quisiera hacer un producto entero, habría que mover los datos de los registros enteros a los registros FP (instrucciones movi2fp), y después de realizado el movimiento contrario para poner el resultado en un registro entero (instrucciones movfp2i). DLXview utiliza siempre saltos condicionales del tipo retrasado con un hueco de una sola instrucción (aunque el mnemónico para las instrucciones de ramificación sea beqz, bnez, deberían en realidad llevar la r de retrasado o la d de delayed delante, o sea ser rbnez o dbeqz). Esto tiene la consecuencia inmediata de que la instrucción tras el salto del bucle siempre se ejecuta (por tanto, no puede ser un trap 0, ya que finalizaría la simulación, y en el ejemplo se ha puesto otra instrucción). Además, el simulador trabaja con un supuesto sistema de predicción, que siempre acierta! (el simulador es capaz de predecir con 100% de acierto los saltos, ya que conoce a priori los resultados de las comparaciones, o sea hace trampa ). Las unidades funcionales (U.F.) del DLXview son configurables; en esta práctica vamos a trabajar con 4 U.F. separadas, todas segmentadas (es decir, pueden soportar un encadenamiento de 1 instrucción por ciclo). La duración que le daremos a las U.F. de F.P. será de 3 ciclos para MULT, 14 para DIV y 2 para ADDFP, al igual que las definidas en el libro de Hennessy y Patterson. Algoritmo de Tomasulo. El algoritmo de Tomasulo es idéntico al del libro de Hennessy-Patterson. Algunas aclaraciones se hacen a continuación: La búsqueda de la instrucción (IF) no se muestra en el simulador. Se le dota a las unidades funcionales (como se ve en la Fig. 1) de varias R.S. para emitir instrucciones enteras, para las de F.P. MULT, para las F.P. ADD, y además de R.S. (o búfferes de load y store) para los accesos a memoria. El número de R.S. es configurable. Las instrucciones NOP ocupan una estación de reserva (R.S.) entera y pueden contribuir a bloquear la máquina si se agotan las R. S. enteras. El bus de escritura CDB es único (existirán bloqueos de escritura al no poder realizar dos fases WB a la vez).

2 El nombre de las etiquetas de los registros coincide con el de la R.S. que ocupa. Por ejemplo en la Fig. 1, el buffer de Store está esperando por el registro F6, que en realidad es la etiqueta Add1, o sea el registro de destino de la primera R.S. de la U.F. de ADD. Con respecto a los esquemáticos y cronogramas del simulador, éstos se muestran en la siguiente Fig. 1 y hay que tener en cuenta lo que sigue. COLOR VERDE COLOR ROJO Fig. 1: Ventana principal del Algoritmo de Tomasulo La parte superior es el esquema tradicional del algoritmo de Tomasulo. En la parte inferior izquierda de tal esquemático (diagrama Instruction status), se observa la temporización de las instrucciones que se van ejecutando paso a paso (se muestran los ciclos en que se ha producido la IS, EX y WB de cada instrucción). También se muestra el ciclo actual (current cycle) de ejecución (el 12 grande en la Fig. 1). En cuanto una instrucción se emite en IS, ya se sabe cuándo se van a ejecutar el resto de sus fases E, W, es decir el simulador (o sistema real) analiza las dependencias con las instrucciones anteriores y calcula esta duración. Por ejemplo si existe una dependencia real, se puede calcular el ciclo en que deben leerse los operandos como es el caso de la sd 0x0(r2), f6, que necesita esperar hasta el ciclo 13 por el registro f6 escrito en el 14 en el bus común por la instrucción anterior. A partir de estos ciclos el alumno puede construir un cronograma de ejecución, donde se incluyan los bloqueos y puede descubrir la causa de los mismos, analizando las dependencias de datos. Recuérdese que al existir un algoritmo de planificación dinámica, pueden darse ciclos de espera, es decir aquellos que sólo afectan a cierta instrucción (que está a la espera de un recurso o dato) pero no a las futuras, no incrementando por tanto el CPI. Recuérdese que en una máquina encadenada sin algoritmo de planificación dinámica, todos los bloqueos eran totales, es decir, una burbuja que impedía que avanzaran las instrucciones siguientes e incrementaba el CPI forzosamente.

3 La línea roja gruesa indica la salida de datos al CDB (en la Fig. 1 desde la U.F. F.P. ADD), la azul la lectura de operandos del fichero de registros, y la verde la emisión de instrucciones hacia la U.F. correspondiente. También la instrucción sobre fondo negro es la recién emitida (IS), y la que está sobre fondo gris la que acaba de escribir sus resultados. La ventana de control de la simulación se llama DLX Visual Simulator (Fig. 2), y permitirá ejecutar el avance de un ciclo de reloj (botón next cycle), el avance de una instrucción (botón step forward), o el retroceso de ambas. También se pueden cambiar las configuraciones o ficheros de entrada del simulador con el botón reset. Fig. 2: Ventana de simulación del Algoritmo de Tomasulo Ejercicios de preparación. En la tabla de resultados se muestra la cabecera en ensamblador de un bucle (con directivas propias del DLXview). Por tanto debe realizar antes de acudir al laboratorio: Entender los bucles dados y las directivas. Notar que un bucle es claramente paralelizable y el otro no. Traducir a ensamblador de DLX (usando un único salto al final del bucle), los bucles en C dados en la tabla de resultados, usando la cabecera dada en la misma. En esta traducción utilizar el mínimo número de registros posibles, y no reordenar ni optimizar estáticamente. No realizar una reordenación estática ( a mano ) del código, eso ya se realizó en prácticas anteriores y en ésta se pretende precisamente el estudio contrario: que la planificación sea dinámica. Señalar con un círculo las zonas del bucle 1 donde más instrucciones del mismo tipo (se ejecutan en la misma unidad funcional) están cerca y por tanto pueden dar bloqueo por agotamiento de estaciones de reserva. Señalar con un círculo las instrucciones del bucle 2 que tienen dependencia de datos para iteraciones distintas. Escribir una fórmula matemática que exprese la salida de ambos bucles (suponiendo que el vector x[] siempre contendrá los números naturales). 3. REALIZACIÓN DE LA PRÁCTICA. Arrancar el PC con el sistema operativo LINUX. Crear un directorio debajo del home llamado gxx, donde xx es el número de grupo. ATENCIÓN: cada vez que transfiera con ftp ficheros de texto con programas fuente (extensión.s), asegúrese de que se transfieren en modo ascii. Abrir una shell (no abrirlo desde el icono de acceso directo); ejecutar el simulador: dlxview (en minúsculas y nunca en background). Entonces la shell donde se invocó se convierte en un prompt que acepta comandos del DLXview (como get y put y también del S.O.), que nos servirán para ver el contenido de los registros, de la memoria, etc. como se explica luego. Tras invocarlo se lanza la ventana principal del DLXview o ventana de control de la simulación (se llama DLX Visual Simulator, Fig. 2). TABLA DE ESPERAS Y BLOQUEOS. 1. En la primera simulación, usar el botón configure de la ventana DLX Visual Simulator, introducir la opción del modo Tomasulo. Vamos a dotarle inicialmente del máximo número de R.S. enteras, MULT, DIV y de ADDFP y del máximo número de bufferes de Load y de Store para evitar bloqueos estructurales por agotamiento de R.S. La latencia (duración en ciclos) será la mencionada antes (2 para ADDFP y 3 para

4 MULTFP y 14 para DIV; 1 para las enteras y Ld/St). Todo lo anterior se muestra en la siguiente Fig. 3. DLXview arrancará entonces una ventana como la Fig Si la ventana de simulación Tomasulo Algorithm on DLX (Fig. 1) fuera más grande que la resolución máxima de la pantalla, en Linux se trabajará con una ventana virtual mayor que la pantalla (de forma que al desplazar el puntero del ratón por los bordes de la pantalla física se verá el resto de la ventana virtual). 3. Cargar luego el fichero de código que se quiera con el botón Load. 4. Se recomienda empezar con ejemplos simples. Por ejemplo, cargar previamente unos sencillos programas llamados: war.s, waw.s, raw.s, que contienen una dependencia de cada tipo, y así ir familiarizándose con el simulador y el efecto de los bloqueos. 5. Para empezar la simulación usar los otros botones de la ventana de control. Se permite ejecutar el avance de un ciclo de reloj (botón next cycle), el avance de una instrucción (botón step forward), o el retroceso de ambas, o la ejecución completa (botón go). 6. Al ejecutar el primer paso, dlxview pedirá una dirección. Pulsar sobre el botón default (por defecto). 7. Rellenar entonces la tablita de bloqueos y esperas de la tabla de resultados. 8. Cuando se quiera cargar otro código u otra configuración deberá usarse el botón reset, el cual permite modificar el código, la configuración o ambas cosas (se aconseja no usar el botón configure para cambiar con posterioridad las configuraciones: el simulador se cuelga a veces; el botón configure sólo sirve para la primera vez que se arranca DLXview) Fig. 3: Ventana de configuración del Algoritmo de Tomasulo NOTA: La configuración para el DLXview también se puede escribir en un fichero (p.ej. fich_config) con los comandos que acepta éste, por ejemplo de la forma: set add_ful_pipe 1 ; indica que la U.F. ADDFP está segmentada set fp_add_latency 2 set mul_ful_pipe 1 set fp_mul_latency 3 set div_ful_pipe 1 set fp_div_latency 14 set pipeline_mode Tomasulo; Otros modos : BasicPipe o ScoreBoard set input_files {prac1.s} ; es el fichero de código Start Entonces se invoca al DLXview con: > dlxview f fich_config Volcado de los registros y de la memoria. Para comprobar que un código está bien escrito, hay que ver los resultados de los registros y de los vectores. Este paso es obligatorio para cualquier código nuevo que se escriba, porque de contrario el programa podría estar mal. Para ello, en la shell donde se invocó el DLXview (se había convertido en un prompt con la cabecera (dlxview) ), se dispone de los siguientes comandos: get registro muestra en hexadecimal el contenido de cualquier registro Rxx o Fxx get registro d muestra en decimal el contenido de cualquier registro Rxx o Fxx get registro B muestra en binario el contenido de cualquier registro Rxx o Fxx

5 fget registro fget registro d muestra en formato flotante simple precisión el contenido de cualquier registro muestra en formato flotante doble precisión el contenido de cualquier registro Si se cambia registro por una dirección de memoria (valor numérico o simbólico) muestra el contenido de esa dirección. Por ejemplo: get 0x1008 d muestra en decimal el contenido de la dirección 0x1008 fget arrayx+4 d muestra en formato flotante doble precisión el contenido de la dirección dada por arrayx+4 Para modificar el contenido de un registro o dirección es igual pero con el comando put y el valor. Por ej.: put registro valor coloca el valor en decimal (o hexadecimal si lleva 0x) en el registro Rxx o Fxx put direccion valor coloca el valor en decimal (o hexadecimal si lleva 0x) en la dirección. fput registro valor d coloca el valor flotante de doble precisión en el registro Fxx SIMULACIÓN BUCLE1. 9. Cargar el programa del bucle 1 y ejecutarlo totalmente una vez, para comprobar que los resultados (valores de y[]) son los que cabría esperar (usar lo explicado en el apartado de: Volcado de los registros y de la memoria.). Anotar los valores en la tabla de resultados. Recordar rellenar el hueco del salto con una instrucción. 10. Usar en primer lugar la configuración del apartado anterior (máximo número de R.S. enteras, etc.). Ejecutar paso a paso. En la tabla de resultados, anotar el CPI y dibujar el cronograma de las primeras instrucciones del bucle (incluyendo también la fase IF), indicando: - los bypasses por el CDB que se van produciendo. - Los conflictos por el uso del CDB (dos instrucciones que intentan usarlo en el mismo ciclo). - Idem para conflictos de alguna de las UF. - El número de R.S. de cada que se usan en cada ciclo (para este cálculo no considerar las instrucciones de cabecera previas al bucle). 11. Otras cuestiones para la tabla de resultados: - puede deducir cuál será el número máximo de búferes de almacenamiento al ejecutar todo el bucle? Conteste en la tabla de resultados. - puede deducir cuál será el número máximo de búferes de almacenamiento al ejecutar todo el bucle para una duración de la UF de división de n ciclos? Conteste en la tabla de resultados. - Anotar también el orden de ejecución en el tiempo (fase EX o equivalente) de las instrucciones. Si dos instrucciones empezaran su ejecución en el mismo ciclo, considerar como primera la que esté antes en la traza del programa. - Anotar cuál es el registro que toma más nombres diferentes y cuántos y cuáles son (gracias al renombrado dinámico de registros). 12. A continuación cambiar la configuración para que haya un único búfer de almacenamiento. En la tabla de resultados, anotar el número de ciclos de bloqueo en la primera, en la segunda iteración y en la tercera iteración. Extrapolar para calcular el CPI para el estacionario de infinitas iteraciones (evidentemente sin tener que ejecutarlas todas en el simulador). Explicar como ha calculado la extrapolación. SIMULACIÓN BUCLE Continuar con la misma configuración que antes. Cargar el programa del bucle 2 y ejecutarlo totalmente una vez, para comprobar que los resultados (valor de y[0]) son los que cabría esperar (usar lo explicado en el apartado de: VOLCADO DE LOS REGISTROS Y DE LA MEMORIA). Anotar el valor en la tabla de resultados. NOTA: Recordar rellenar el hueco del salto con una instrucción. 14. A continuación, ejecutar paso a paso. En la tabla de resultados, anotar el CPI de la primera iteración. 15. Anotar que instrucción impide que sea un bucle paralelizable. 16. Teniendo en cuenta eso, calcular el CPI de una iteración en el estacionario del bucle (tras muchas iteraciones y cuando las R.S. se empiezan a agotar). 17. Otras cuestiones para la tabla de resultados: puede deducir cuál será el CPI de una iteración en el estacionario para una duración de n ciclos de la UF de MULT? NOTAS: También puede ejecutarse el simulador en un PC con Windows que permita conexión al servidor (como murillo.eii.us.es, etc.), si se dispone de un emulador de ventanas X de UNIX (como X-Win32). Para abrir una sesión en el servidor en modo gráfico, ejecutar primero X-Win32 Utility y configurar las opciones de X-Win32 Utility para visualizar mejor el simulador así: Options, Windows Settings, Single (Single Settings Width:1280, Heigth:1024). Fonts, Path, Include MS-Fonts. De esa forma se emula una ventana mayor que la pantalla (la cual maximizada, dispondrá de las barras de scroll para moverse por toda ella). Ejecutar entonces X-Win32 y conectarse al servidor en XDMCP (probablemente el Xwin32 abre una de estas sesiones al arrancar). No hacer caso del posible mensaje de Unknown host. Si no diera tiempo a realizar alguno de los apartados se dispone de horarios de libre acceso en un Aula del CdC. También se estudiará la posibilidad de situar una tutoría especial en las aulas de ordenadores. El simulador DLXview también está en la página web del departamento: en la zona de descargas (es necesario disponer de versiones recientes de Tcl/Tk).

6 ASP1. 4º INGENIERÍA INFORMÁTICA. PRACTICA 5 PLANIFICACIÓN DINÁMICA: EL ALGORITMO DE TOMASULO. NUM GRUPO: ALUMNOS: BUCLE1 EN C double y[15], x[15]={1.0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}, constante1=1.0, constante2=2.0; int i; for (i=0; i<15; i++) y[i]= (x[i]- constante1)*x[i]/constante2; BUCLE2 EN C double y[15],x[15]={1.0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}, constante1=1.0; int i; for (i=0; i<15; i++) constante1 = constante1 / x[i]; y[0]= constante1; CÓDIGO DLX.data 0x1000 constante1:.double 1.0 constante2:.double 2.0 arrayx:.double 1.0,2,3,4,5,6,7,8,9,10,11,12,13,14,15 ;/* NUMEROS ENTEROS */ finalx:.space 4 ;/* esta variable solo sirve para apuntar a la direccion posterior al final de x.data 0x1100 arrayy:.double 1.0,2.0,4, 1.0,2.0,4, 1.0,2.0,4, 1.0,2.0,4, 1.0,2.0,4.text ; ********** EMPIEZA CODIGO ************ addi r1, r0, constante1 ld f0, 0(r1) addi r1, r0, constante2 ld f2, 0(r1) addi r2, r0, arrayy addi r1, r0, arrayx ; ******** EMPIEZA BUCLE 1 ************ bucle: ; estos son para que las instrucciones de cabecera no interfieran con el bucle ; ******** EMPIEZA BUCLE 2 ************ bucle: trap 0 Fórmula Matemática: trap 0 Fórmula Matemática:

7 TABLA DE BLOQUEOS Y ESPERAS Poner una cruz en la siguiente tabla, para los factores que influyan en el CPI y los que sólo produzcan un ciclo de espera de una instrucción (no bloqueando completamente la máquina), para el algoritmo de Tomasulo y la cadena básica: CPI cadena CPI Tomasulo C. Espera cadena C. Espera Tomasulo Dependencia RAW Dependencia WAW Dependencia WAR BUCLE 1 Resultado en y[]: Nº R.S. LD Nº R.S. ADDD Nº R.S. MULT Nº R.S. DIV Nº R.S. INT Nº R.S. ST CRONOGRAMA CON NUM MÁX DE R.S. CPI: Nº MÁXIMO BUFERES ST (para duración de UF DIV=14): Nº MÁXIMO BUFERES ST (para duración de UF DIV= n): Registro que toma más nombres diferentes: Cuáles son? Cuántos?: ORDEN DE EJECUCIÓN DE LAS INSTRUCCIONES DEL BUCLE único búfer de almacenamiento Nº ciclos bloqueo Posible CPI para infinitas iteraciones: Iteración primera Iteración segunda Iteración tercera Explicación: BUCLE 2 Resultado en y[0]: Instr que impide que sea bucle paralelizable: CPI de iteración en estacionario: CPI de iteración en estacionario para duración n de DIV: CPI de 1ª iteración: