Arquitectura de Computadores (Ing. Industrial) Práctica 2: Medida

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 pico1?. 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 (2n3)/3 + o(n2) 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.
2
●
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 tiempos2, 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
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 Second3
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
bytes leídos
IA-32
SPARC
datos memoria
bytes leídos
bytes escritos
datos registros
bytes leídos
bytes escritos
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
El
merlin es un ejemplo
fichero gauss.c está en:
de máquina de la familia HP-PA. Podéis usar la cuenta que ya tenéis.
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=[1026]).
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
/usr/local/doc/quotas.txt
gráfica. Ver:
●
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
Nombre / dir.IP:
Máquina:
CPU:
hendrix.cps.unizar.es /
155.210.152.16
Ultra 5 Model 360
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
Compiladores:
cc (WorkShop 5), gcc (2.95.2), gcc2 (gcc 2.8.1)
5.8, Kernel Version Generic_108528-06 64-
bit
Para más información, ejecutar la orden sysinfo
7.2 pentiums sala L0.01
Nombre / dir.IP:
infbnn,
CPU:
infbn.cps.unizar.es, n=[2-6] /
nn=[10-26, 28-31] /
155.210.154.[156-160]
155.210.154.[164-180, 182-185]
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 /
Máquina:
COMPAQ AlphaServer DS10 466 MHz DEC6600
CPU:
155.210.152.17
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 merlin4
Nombre / dir.IP:
merlin.cps.unizar.es /
Máquina:
CPU:
155.210.208.10
Servidor HP9000, serie 800, modelo L2000-36
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:
Memoria cache L1:
procesador-)
PA (Precission Architecture)
512 KB instr. + 1024 KB datos (1.5 MB en el chip -cada
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
(interesante contrastar
MFLOPS del código generado por ambos compiladores)
Más información en: /usr/local/info/merlin
4
Órdenes uname y model
2.8.1
7.5 pentiums sala L0.03
Nombre / dir.IP:
CPU:
xtnn.cps.unizar.es,
nn=[02-23] /
155.210.154.[111-132]
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
Arquitectura:
IA-32 (Intel Arquitecture 32 bits)
Memoria cache L1:
12 Kµops instrucciones + 8 KB datos
Memoria cache L2:
512 KB
Memoria principal:
512 MB RAM DDR-400
Disco duro:
1 disco IDE de 40GB, 7200rpm : ST340014A
Sistema Operativo:
MS-DOS y Windows NT
Compilador:
¿?
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