Arquitectura de Computadores (Ing. Industrial) ArqTecComp - Dpto. Informática e Ingeniería de Sistemas CPS - UniZar Práctica 2: Medida de Prestaciones En esta práctica se determinan las prestaciones de una máquina con un procesador RISC (Sun UltraSPARC IIi) y de otra con procesador CISC (Intel IA-32) mediante la ejecución de un programa de prueba intensivo de cálculo en coma flotante. También se medirá la influencia del compilador. Los índices escogidos van desde medidas independientes de la arquitectura (MFLOPS) hasta índices muy dependientes de la arquitectura/ implementación (CPI). Si hojeáis una revista de informática donde aparezcan anuncios de computadores, encontraréis números acerca de sus prestaciones. No siempre estos índices tienen sentido, están en contexto o son reproducibles. Por ejemplo, para qué sirve saber la máxima velocidad a la que puede trabajar el hardware, velocidad de pico 1?. Lo que importa en realidad es resolver problemas en el menor tiempo y/o con la máxima precisión posibles. Una forma de medir la calidad del computador consiste en tomar medidas durante la ejecución de programas de prueba (benchmarks). Cualquier programa de prueba puede orientarnos en la comparación entre computadores si tenemos claro que: a) El compilador va a representar un papel importante, un hardware superior puede ser la base de un computador mediocre si el compilador no es bueno. b) Los resultados deben ser comparables y reproducibles: lista exhaustiva de condiciones de contorno (KBytes de los distintos niveles de cache, MBytes de memoria principal - DRAM-, prestaciones de disco y de bus, nivel de optimización del compilador, número de procesos en la máquina, versión del sistema operativo...). En esta práctica se medirán distintos índices de prestaciones del computador (MIPS, MFLOPS, CPI...) ejecutando un pequeño programa núcleo (kernel). Siempre teniendo en cuenta el tiempo de ejecución medido, podrán obtenerse índices operaciones/tiempo (a partir del número de operaciones realizadas), instrucciones/tiempo (a partir del número de instrucciones ejecutadas)... Linpack (Linear Algebra Package) es un programa de prueba muy utilizado para medir la potencia del computador en un ámbito de cálculo vectorial en coma flotante. El programa de 1 De pico, es decir de boca. Velocidad que por definición nunca se consigue en problemas reales.
prueba Linpack inicializa una matriz y un vector con datos aleatorios, realiza una descomposición triangular superior/inferior -L/U- mediante eliminación Gaussiana con pivotado parcial, sustituye y finalmente verifica la respuesta. Existen variantes en el tamaño del sistema (matriz 100x100 ó 1000x1000) y en la precisión de las variables (simple, 4 bytes o doble, 8 bytes). La resolución del sistema implica (2n 3 )/3 + o(n 2 ) operaciones. La mayoría de estas operaciones se deben al bucle más interno, que resta un múltiplo de la fila pivote a cada fila de la submatriz implicada. Por tanto, y para simplificar el análisis del programa, podemos experimentar tan sólo con ese bucle más interno sin alterar las conclusiones. En esta práctica vamos a medir prestaciones de dos máquinas a) hendrix: arquitectura SPARC (RISC). b) infbn (n=[2-6]), infbnn (nn=[10-26, 28-31]): arquitectura IA-32 (CISC). Son los PCs con Linux de la sala de prácticas L0.01, a los que se puede acceder de forma remota con ssh. Comparten el sistema de ficheros con hendrix, así que vuestro nombre de usuario, password y directorio de trabajo son los mismos en todas estas máquinas. Utilizaremos como programa de prueba gauss.c, que es una simplificación de Linpack. Podéis encontrar este programa y copiarlo en vuestro directorio desde: hendrix: /export/home/compu/peimarin/gauss/gauss.c hendrix: /home/chus/gauss.c O bien descargaroslo desde la web de la asignatura. El fragmento de código a medir es el siguiente: for (i=0; i<m_size; i++) { } for (j=0; j<m_size; j++) { } A[i][j] = A[i][j]-P[i]*B[j]; Esta pareja de bucles resta a cada fila de la matriz A un vector B escalado por P[i]. Estos bucles, a su vez, están incluido en dos bucles más: limit y repeat. El bucle limit (contador s) sirve para repetir la operación matricial y conseguir un tiempo suficientemente grande para ser medido con precisión. Si la medida de tiempo no es mayor que 20 veces la resolución de la rutina de medida de tiempos 2, el programa lo advierte: habrá que incrementar el número de iteraciones limit. El bucle más externo repeat (contador r) pretende conseguir resultados más fiables (reproducibles), calculando la media de varios experimentos. Si la variabilidad 2 Resolución de la llamada al sistema times() o clock()
(varianza) de las medidas de dichos experimentos es alta, el programa lo avisará: habrá que realizar una nueva medición incrementando el valor de repeat. Estudiad con detalle el código para comprender bien el papel de los dos bucles más externos. 1. MFLOPS, Millions of FLOating Point OPerations per Second En este apartado mediremos la eficiencia del computador ejecutando código de alto nivel. Es equivalente a ocultar los detalles del compilador, del lenguaje máquina y de la implementación en un caja negra y hacer medidas desde el exterior. Mediremos prestaciones en términos de operaciones en coma flotante. En primer lugar compilaremos el programa gauss.c en las dos máquinas con dos niveles de optimización en cada una de ellas. Para ello crea dos directorios llamados sparc e ia32, y copia gauss.c en los dos directorios. Compila el programa en cada uno de los directorios desde la máquina que corresponde, con el compilador y con los niveles de optimización que se indican en la siguiente tabla: Sin optimización Con optimización hendrix cc gauss.c -o gauss cc -xo3 gauss.c -o gauss3 infbnn gcc gauss.c -o gauss gcc -O3 gauss.c -o gauss3 Ejecuta las distintas versiones del programa con diferentes tamaños de la matriz A (16x16, 32x32, 64x64, 128x128, 256x256, 512x512). Hay que ajustar el valor de la variable limit para cada tamaño de matriz, de modo que el tiempo de ejecución medido en cada iteración del bucle más externo (bucle repeat) sea mayor que 20 veces la resolución del temporizador. Así se limita el error de medición debido a la resolución del temporizador. Asimismo hay que ajustar el valor de la variable repeat de forma que se eviten medidas poco fiables. Calcula los MFLOPS para cada tamaño y nivel de optimización (velocidad de las operaciones suma y producto de coma flotante efectuados por el programa). La cifra cambia según el tamaño de la matriz, por qué?. Como se especifica en la documentación de la práctica, el procesador IA-32 que estáis usando es un Pentium III a 1 GHz. Dispone de 2 unidades funcionales de coma flotante y por tanto es capaz de ejecutar 2 GFLOPS de pico. Sin embargo la propaganda asegura que ejecuta 4 GFLOPS de pico usando las instrucciones SSE (Streaming SIMD Extensions). En cuanto al procesador SPARC empleado, se trata de un UltraSPARC IIi a 360 MHz, capaz de lanzar 4
instrucciones por ciclo de las que sólo 2 pueden ser de punto flotante. Por tanto, puede ejecutar 720 MFLOPS de pico. Por qué la cifra que habeis obtenido al ejecutar gauss es con toda seguridad muy inferior a los MFLOPS de pico anunciados por la propaganda? Qué tipo de programas rondaría los MFLOPS de pico? 2. MIPS, Millions of Instructions Per Second 3 A continuación abriremos parcialmente la caja negra y consideraremos el nivel lenguaje máquina. Conseguid el listado en ensamblador del programa para cada arquitectura y nivel de optimización utilizando la opción -S del compilador. Por ejemplo, para nivel de optimización 3: hendrix:~/ cc -xo3 -S -o gauss3.s gauss.c El bucle más interno de cada una de las versiones se encuentra en las líneas del fichero.s que se indican en la siguiente tabla: SPARC IA-32 sin optimización con optimización sin optimización con optimización Línea inicio 375 462 224 204 Línea final 422 483 258 214 Para cada nivel de optimización y arquitectura, cuántas instrucciones se ejecutan en cada iteración del bucle L/U más interno?. Calcular las velocidades en MIPS suponiendo que los tiempos medidos en el apartado anterior se deben exclusivamente a la ejecución del bucle interno. Un Pentium III puede decodificar hasta 3 instrucciones por ciclo a 1 GHz. Por tanto ejecuta 3000 MIPS de pico. En cuanto al procesador UltraSPARC IIi puede lanzar hasta 4 instrucciones por ciclo a 360 MHz. Por tanto ejecuta 1440 MIPS de pico. Por qué la cifra que habéis obtenido al ejecutar gauss es con toda seguridad muy inferior a los MIPS de pico anunciados por la propaganda? Qué tipo de programas conseguirían los MIPS de pico? 3 Medida desprestigiada. Por ejemplo, algunos dicen que MIPS es Meaningless Indicator of Processor Speed, o sea, indicador inútil de la velocidad del procesador.
3. CPI (Ciclos Por Instrucción) Conociendo el tiempo de ciclo del procesador, calculad el CPI de este programa. Para qué tamaño y nivel de optimización se obtiene el mejor CPI? Y el peor? Cómo se explican las diferencias, si existen? Mejor CPI implica siempre menor tiempo de ejecución? 4. Ancho de banda Para este apartado debéis estudiar cuidadosamente el código ensamblador. Considerad solamente las versiones optimizadas. Calculad el ancho de banda en megabytes por segundo (MBps) de: Las instrucciones, es decir, cuántos MBps de instrucciones está consumiendo el procesador? Para determinar los bytes de código buscados en IA-32 sigue el siguiente procedimiento: 1. añade en el fichero ensamblador (.s) etiquetas delimitando el código a medir. 2. compila el fichero ensamblador: gcc gauss.s -o gauss 3. utiliza el comando nm -n gauss para conocer las direcciones de las etiquetas. Los datos, es decir el tráfico de datos entre procesador y memoria medido en MBps, tanto en lecturas como en escrituras. El banco de registros, o sea MBps de lecturas y escrituras en cualquier registro (salvo el contador de programa -PC-). Rellenad una tabla en la que se especifiquen, para las versiones optimizadas de las dos arquitecturas, los bytes de cada tipo leídos/escritos en una iteración del bucle interno (ver tabla). Rellenad otra tabla en la que, para cada tamaño de matriz y para cada arquitectura, se especifiquen los tiempos de ejecución y los MBps de cada tipo. instrucciones datos memoria datos registros IA-32 bytes leídos bytes leídos bytes escritos bytes leídos bytes escritos SPARC
5. (Optativo) Medidas sobre otras arquitecturas Como trabajo optativo puede realizarse el análisis de otras máquinas. 1.1Alpha La máquina Compaq Alpha paramo.cps.unizar.es con sistema operativo Tru64 5.0 también comparte el sistema de ficheros con hendrix. Vuestro nombre de usuario, password y directorio de trabajo son los mismos que en hendrix. 1.1HP-PA merlin es un ejemplo de máquina de la familia HP-PA. Podéis usar la cuenta que ya tenéis. El fichero gauss.c está en: merlin: /users2/ac/bench_sources/gauss.c 1.1Otras opciones También puede realizarse la práctica en casa analizando vuestro computador. Los binarios compilados -con y sin optimización- para un procesador x86 (AMD, Intel...) con MS-DOS, junto con el fichero fuente modificado para compilarse en dicha plataforma están en: http://www.cps.unizar.es/~chus/ac/wgauss.zip Si quieres compilar el fichero fuente deberás hacerte con un compilador de C. Si tienes acceso a Internet efectúa una búsqueda (www.google.com) con las palabras clave: "C compiler", "freeware" y la plataforma que utilices (Linux, Windows, MS-DOS, MacOS...). Para Intel80386 y posteriores puede utilizarse DJGPP, que se encuentra en: http://www.delorie.com/djgpp/ Los resultados obtenidos en tus experimentos deben incluir la lista de condiciones contorno (CPU, memorias cache y RAM, sistema operativo y versión, compilador, opciones de compilación, etc.). Si tienes un computador x86 (AMD, Intel, VIA, Cyrix) con SO Windows, puedes obtener información detallada del sistema con el programa CPU-Z, disponible en: http://www.cpuid.com/cpuz.php 6. Consejos de uso de hendrix/infbnn/paramo La cuenta de hendrix es válida para: la máquina Compaq Alpha llamada paramo los PCs con Linux 2.4.9 del laboratorio L0.01 (infbnn.cps.unizar.es, con nn=[10-26]). Si accedes a estos PCs en local (físicamente en el equipo) utiliza tu nombre de usuario y contraseña de hendrix en la ventana inicial. El acceso remoto deberá realizarse vía ssh (similar a
telnet pero utiliza cifrado para la comunicación, así no envía la contraseña en claro por la red), y en principio sólo puede realizarse desde máquinas ubicadas en las redes 155.210.155.0 y 155.210.152.0. Puede sortearse esta limitación para conectarse a paramo o los PCs del L0.01 desde casa, realizando en primera instancia ssh sobre hendrix: ssh hendrix.cps.unizar.es Si tu sistema no soporta ssh, puedes utilizar el programa PuTTY (gratuito), disponible en: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html http://www.cps.unizar.es/~chus/ac/putty.exe Debes seleccionar sesión ssh al puerto 22 de hendrix.cps.unizar.es (al estar fuera del dominio unizar deberás especificar el nombre completo de la máquina). Una vez establecida la conexión con hendrix, efectuar otro ssh a la máquina destino (si usas PuTTY, utiliza la línea de órdenes de UNIX): ssh infbxx.cps.unizar.es ssh paramo.cps.unizar.es 6.1Uso local de infbnn Si utilizas las máquinas infbnn accediendo en local, ten presentes las siguientes consideraciones: Primer login: entrar vía remota (telnet/ssh) desde la cuenta de xterminal de los PC's de L0.01 y cambiar el password. Cuando pide "enter login (NIS+) password" está pidiendo el antiguo. Uso de la cuenta para trabajar localmente en los PCs (Laboratorio L0.01): el directorio HOME es compartido con hendrix, así resulta más eficiente por ejemplo, editar los ficheros en el PC en el que estás sentado. Para usar NEdit como editor por defecto de Gnome, poner el path completo (/usr/local/ bin/x11/nedit). En lo posible se recomienda usar 'nc', como se describe en Nedit->Help- >Server Mode and nc. Los terminales que lanza gnome (entorno de ventanas de Linux) por defecto no son de login. Eso hace que las variables de entorno necesarias no estén presentes. Corregirlo en el cuadro de preferencias: Botón derecho->preferences...->general->use --login by default Uso del Netscape: si la cache de netscape os agota la quota una solución puede ser poner la cache de disco a cero en las preferencias. Para correo es mejor usar los programas nativos de correo: mutt, elm, pine, popclient, xmh, etc... Quotas: si se os agota la quota no podréis entrar en sesion gráfica. Ver: /usr/local/doc/quotas.txt
Cuentas antiguas: es posible que los ficheros de configuracion de tu shell no estén actualizados para soportar las 3 arquitecturas disponibles. Puedes encontrar los ficheros necesarios en: /usr/local/etc/proto_user 7. Características de los computadores 7.1 hendrix bit Nombre / dir.ip: hendrix.cps.unizar.es / 155.210.152.16 Máquina: Ultra 5 Model 360 CPU: Sun UltraSPARC-IIi, 360 MHz Decodifica hasta 4 instrucciones por ciclo, máximo 2 de coma flotante Arquitectura: Sparc (sparcv9+vis) Memoria Cache L1: 16 KB instrucciones + 16 KB datos Memoria Cache L2: 256 KB (en placa) Memoria principal: 320 MB DRAM Memoria virtual: 726 MB Disco duro: 8 GBytes HD SCSI Sistema Operativo: SunOS, version 5.8, Kernel Version Generic_108528-06 64- Compiladores: cc (WorkShop 5), gcc (2.95.2), gcc2 (gcc 2.8.1) Para más información, ejecutar la orden sysinfo 7.2 pentiums sala L0.01 Nombre / dir.ip: infbn.cps.unizar.es, n=[2-6] / 155.210.154.[156-160] infbnn, nn=[10-26, 28-31] / 155.210.154.[164-180, 182-185] CPU: 1 GenuineIntel (Coppermine) 999.860 MHz (Pentium III) Decodifica hasta 3 instr. por ciclo, 2 UFs de punto flotante Arquitectura: IA-32 (Intel Arquitecture 32 bits) Memoria cache L1: 16 KB instrucciones + 16 KB datos Memoria cache L2: 256 KB (en chip, funciona a la frecuencia de la CPU) Memoria principal: 256 MB DRAM Disco duro: 37 GB 2 IDE: ST340016A (hda) Sistema operativo: Linux Red Hat 7.2, kernel 2.4.18-27.7.x Compiladores: gcc 2.96
Más información: orden hinv 7.3 paramo Nombre / dir.ip: paramo.cps.unizar.es / 155.210.152.17 Máquina: COMPAQ AlphaServer DS10 466 MHz DEC6600 CPU: Alpha 21264 (EV6), 466 MHz. Decodifica hasta 4 instrucciones por ciclo, máximo 2 de coma flotante Arquitectura: Alpha Memoria cache L1: 64 KB instrucciones + 64 KB datos Memoria cache L2: 2 MB Memoria principal: 256 MB Sistema Operativo: Digital UNIX V5.0 (Rev. 910); Fri Oct 5 10:56:37 MEST 2001 Tru64 UNIX Spanish Support V5.0 (rev. 764) Compiladores: cc (Compaq C V6.1-011), gcc (2.95.2) Ver también /usr/local/doc/soft y /tmp_mnt/home/spd/paramo.html 7.4 merlin 4 Nombre / dir.ip: merlin.cps.unizar.es / 155.210.208.10 Máquina: Servidor HP9000, serie 800, modelo L2000-36 CPU: RISC, HP-PA8500 (64 bits), 360 MHz. 4 procesadores (multiprocesador simétrico) Decodifica hasta 4 instrucciones por ciclo, máximo 2 de coma flotante Arquitectura: PA (Precission Architecture) Memoria cache L1: 512 KB instr. + 1024 KB datos (1.5 MB en el chip -cada procesador-) Memoria cache L2: No tiene Memoria principal: 2048 MB Disco duro: 4 discos internos Seagate ST39103LC de 8683 MB. Sistema operativo: UNIX, HP-UX version 11.00 Compiladores: cc (version?) y gcc 2.8.1 (interesante contrastar MFLOPS del código generado por ambos compiladores) Más información en: /usr/local/info/merlin 4 Órdenes uname y model
7.5 pentiums sala L0.03 Nombre / dir.ip: xtnn.cps.unizar.es, nn=[02-23] / 155.210.154.[111-132] CPU: Arquitectura: Memoria cache L1: Memoria cache L2: Memoria principal: Disco duro: Sistema Operativo: Compilador:? 1 Intel(R) Pentium(R) 4 CPU 2.60C GHz Puede lanzar a ejecutar 1 instrucción SSE2 por ciclo, lo que supone un pico de dos operaciones de coma flotante de doble precisión (64 bits) o cuatro de simple precisión (32 bits) por ciclo. 5 IA-32 (Intel Arquitecture 32 bits) 12 Kµops instrucciones + 8 KB datos 512 KB 512 MB RAM DDR-400 1 disco IDE de 40GB, 7200rpm : ST340014A MS-DOS y Windows NT 5 Este pico sólo se alcanza entrelazando sumas y productos en ciclos consecutivos. Explicación más precisa en página 10 de G. Hinton, D. Sager, M. Upton, D. Boggs, D. Carmean, A. Kyker, P. Roussel., "The Microarchitecture of the Pentium 4 Processor". Intel Technology Journal, Q1, 2001