Optimización del Código New-dim en el...
38
1 Optimización del Código New-dim en el Computador ORIGIN 2000 Miguel Valero-García CEPBA, Marzo 1998
Transcript of Optimización del Código New-dim en el...
Optimización del CódigoNew-dim en el Computador
ORIGIN 2000
Miguel Valero-GarcíaCEPBA, Marzo 1998
1
2
código
RAN
o de
nas 24
rtida
], que
era de
emorias
istema
rgo, el
de la
ralela.
artidas.
ra la
rma
obre 8
e factor
(factor
lculo,
derarse
matriz
con la
nes de
a más
ue ha
ido la
varios
1 Resumen ejecutivo
En este documento se describe el trabajo realizado para la mejora del rendimiento del
new-dimsobre el computador paralelo ORIGIN 2000. Este código está escrito en FORT
77. La versión original del código es lento y, por lo tanto, resulta poco operativa. A títul
ejemplo, el caso práctico correspondiente a los datos de entrada disponibles requiere u
horas de tiempo de ejecución en un procesador de ORIGIN 2000.
El computador ORIGIN 2000 es un sistema multiprocesador con memoria compa
distribuida [LaLe97]. Los nodos están constituidos por procesadores R10000 [Yeag96
implementan varias técnicas avanzadas de arquitectura del procesador (ejecución fu
orden, predicción de saltos, etc). Cada procesador tiene dos niveles de cache. Estas m
cache mantienen una visión coherente de la memoria global del sistema mediante un s
de directorio. El sistema admite configuraciones de hasta 128 procesadores. Sin emba
trabajo se ha realizado bajo la suposición de que el número de procesadores
configuración disponible es 8. El computador ofrece varios modelos de programación pa
En este trabajo se ha usado un modelo de programación basado en variables comp
Esencialmente, el modelo corresponde a FORTRAN 77 con algunas directivas pa
paralelización y planificación de bucles.
El trabajo de optimización ha permitido reducir el tiempo de ejecución de fo
espectacular. En concreto, el código mejorado, ejecutando el caso práctico disponible s
procesadores es 133 veces más rápido que el código original sobre un procesador. Est
de reducción proviene de tres mejoras: (a) reducción del coste de los accesos a memoria
5.71), (b) reducción de operaciones innecesarias (factor 3.06), y (c) paralelización del cá
para 8 procesadores (factor 7.64). Es esfuerzo de reescritura del código puede consi
moderado. La mejora (a) sólo ha requerido una reordenación en las dimensiones de una
tridimensional, y la modificación de las sentencias que usan esta estructura, de acuerdo
nueva organización. La mejora (b) ha requerido pequeños cambios en las operacio
algunos bucles y una reorganización general de la estructura de bucles de la rutin
importante. Sin ser especialmente compleja, esta reorganización ha sido la mejora q
requerido mayor esfuerzo de reprogramación. Finalmente, la mejora (c) ha requer
inserción de las directivas necesarias para la paralelización de bucles y la substitución de
vectores por una matriz, con un mínimo esfuerzo de reescritura de código.
3
nálisis
ientas
otante,
digo y
yen al
cómo
iza un
iempo
tes. La
cesos a
ciones
, en la
n
que se
n una
simple
rutina
utinas
sin la
que el
En el proceso de optimización han resultado muy útiles algunas herramientas de a
del rendimiento del ORIGIN 2000. Estas herramientas son:Perfexy SpeedShop, que se basan
en los contadores de eventos que tienen los procesadores R10000 [ZLTI96]. Las herram
pueden contabilizar eventos tales como fallos de cache, de TLB, operaciones en coma fl
lecturas y escrituras de memoria, etc, mostrando su distribución por subrutinas del có
por procesador, y permitiendo incluso identificar las líneas de código que más contribu
valor final del contador de eventos. Un objetivo adicional de este documento es mostrar
se han usado estas herramientas y en qué fases del trabajo han resultado más útiles.
El documento se ha estructurado de la siguiente forma. En la sección 2 se real
análisis del código original, identificando las secciones de código que consumen más t
de ejecución e identificando también algunas de las fuentes de ineficiencia más importan
sección 3 describe las mejoras que se han realizado para reducir el coste de los ac
memoria. La sección 4 describe las mejoras que han permitido eliminar muchas opera
innecesarias. La sección 5 describe el proceso de paralelización del código. Finalmente
sección 6 se muestran las conclusiones del trabajo realizado.
2 Análisis del código original
2.1 Aspectos generales
El código original del programanew-dim tiene 1343 líneas de FORTRAN 77. La versió
original se compila de la siguiente forma:
%f77 -O3 -extend_source -static new-dim.f -o new-dim
En lo sucesivo seguiremos usando estas opciones de compilación, a menos
indique lo contrario.
El programa principal llama a varias rutinas que leen los datos de entrada, realiza
selección de los datos a tratar, realizan el tratamiento y escriben el resultado. Una
inspección del código revela que la mayor parte del tiempo de ejecución se emplea en la
LOAD_COEFF, donde se realiza el tratamiento de los datos seleccionados en las r
previas. Para confirmar esta hipótesis se ha realizado una ejecución del programa
llamada a la rutina LOAD_COEFF. El programa tarda sólo 9 segundos. Recuérdese
4
r tanto,
, unas
bucles
tres
or una
fases
e
). La
tina
llegar
te, en la
le
programa completo para el caso disponible tarda unas 24 horas. La conclusión es, po
que los esfuerzos de optimización deben centrarse en la rutina LOAD_COEFF (en total
500 líneas de código).
2.2 Análisis de la rutinaLOAD_COEFF
La rutina LOAD_COEFF tiene la estructura que se muestra en la figura 1. Se trata de 7
imbricados (figura 1a). En el cuerpo del bucle más imbricado (figura 1b) se identifican
fases de cálculo. La fase (a) corresponde al producto de un vector de 30 elementos p
matriz de 30 filas y 8 columnas (unas 500 operaciones aritméticas en coma flotante). Las
(b) y (c) están sujetas a una condición (cond1). La fase (b) es la llamada a una rutina, qu
puede ser THPLATE_MS o SANDWICH_MS, dependiendo decond2. El objetivo de estas
rutinas es calcular dos valores (SM1 y SM2) a partir del vector calculado en la fase (a
rutina THPLATE_MS realiza unas 500 operaciones en coma flotante. La ru
SANDWICH_MS realiza un número variable de operaciones en coma flotante (puede
hasta 2500 operaciones). Más adelante se darán detalles sobre estas rutinas. Finalmen
DO JCASE=1,NCASES
DO I_DYN=1,N_DYN_CASES
DO I_SBC=1,N_DYN_COMB
DO I_LAT=0,N_LAT
DO I_DF=1,N_DF
DO I_ENG=1,N_ENG
DO IEL=1,NELSEL
cuerpo del bucle
cuerpo del bucle
fase (a): producto de matriz por vectorIF cond1 THEN
fase (b): IF cond2 THENCALL THPLATE_MS
ELSECALL SANDWICH_MS
ENDIFfase (c): IF (CORE (IEL) .GT. SM1) THEN
LC (IEL) = ......DC (IEL) = ......SB (IEL) = ........
ENDIFENDIF
Figura 1: (a) Estructura de los bucles de la rutina LOAD_COEFF. (b) Estructura del cuerpo del buc
más interno.
(a) (b)
5
na la
na en
=8 y
to, la
cle
s de las
ida se
uencia
acto de
sobre
eden ser
MS y
mejora
ntes).
) todas
bucle
n las
e
mación
edan
fase (c), para cada valor de IEL (el índice del bucle más imbricado) se seleccio
información asociada al caso con SM1 y SM2 mínimos. Esta información se almace
varios vectores.
Los límites superiores de varios de los bucles son constantes (N_LAT=255, N_DF
N_ENG=8). Por otra parte, resulta que N_DYN_CASES× N_DYN_COMB = 14. Finalmente,
los valores de NCASES y NELSEL dependen de los datos de entrada. Por tan
complejidad de la rutina LOAD_COEFF puede aproximarse como sigue:
229376× NCASES× NELSEL× coste
En la expresión anterior,costerefleja el coste en segundos de cada iteración del bu
más interno. Como se ha visto antes, este coste es variable, dependiendo de los valore
condicionescond1 y cond2 (ver figura 1b).
La forma de evaluar el impacto de las diferentes mejoras será mostrar en qué med
reduce el tiempo de ejecución correspondiente al caso práctico disponible como consec
de cada una de las mejoras. Un problema de esta forma de evaluación es que el imp
cierto tipo de mejoras puede quedar poco enfatizado cuando las mejoras se realizan
secciones de código poco usadas en el caso de los datos de entrada utilizados, y que pu
muy usadas en otros casos. (este puede ser el caso de las rutinas THPLATE_
SANDWICH_MS).
Para resolver este problemas realizaremos el siguiente planteamiento. Cualquier
se evaluará para el caso práctico disponible (tal y como se ha mencionado a
Adicionalmente, la mejora se evaluará para cada una de las tres hipótesis siguientes: (1
las iteraciones del bucle interno ejecutan THPLATE_MS, (2) todas las iteraciones del
interno ejecutan SANDWICH_MS, y (3) todas las iteraciones del bucle interno elude
fases (b) y (c). Para cada una de estas hipótesis se calcula el valor correspondiente dcoste.
Estos valores se denotarán porcoste_t (hipótesis (1)),coste_s(hipótesis (2)), ycoste_e
(hipótesis (3)). Analizando cómo se reducen estas constantes, dispondremos de infor
complementaria sobre el impacto de cada mejora.
Con el objetivo de evaluar con comodidad el valor decoste_t, coste_sy coste_ese ha
instrumentado el código de la rutina LOAD_COEFF de forma que, al inicio de ésta, pu
6
ro de
rentes
o las
artir de
de las
para los
e
ue la
mucho
lizadas.
nto en
reescribirse los valores de NCASES, NELSEL y N_LAT. Así, puede controlarse el núme
iteraciones del bucle más interno. Se han tomado tiempos de ejecución para dife
combinaciones de NCASES, NELSEL y N_LAT. Para cada combinación se han forzad
tres situaciones antes descritas. Los tiempos obtenidos se muestran en la figura 2. A p
estos tiempos se ha obtenido los siguientes valores para las constantes:
coste_t = 7.10× 10-5 segundos
coste_s = 7.05× 10-5 segundos
coste_e = 5.50× 10-5 segundos
Sabemos que para el caso de los datos de entrada disponibles, la mayoría
iteraciones pasan por las fases (b) y (c). Por tanto, los valores decoste_to de coste_sson
buenas estimaciones para el coste medio de cada iteración. Teniendo en cuenta que,
datos de entrada del caso disponible, NCASES= 2 y NELSEL = 2837, puede comprobarse qu
el modelo predice las 24 horas aproximadas de tiempo de ejecución.
Es interesante observar que la diferencia entrecoste_ey coste_so coste_tes pequeña, a
pesar de que las rutinas THPLATE_MS y SANDWICH_MS hacen más operaciones q
fase (a). Esto revela serias ineficiencias en la fase (a) que elevan el tiempo de ejecución
más allá de lo que cabría esperar, a tenor del número de operaciones aritméticas rea
Esta hipótesis se ha confirmado mediante la herramientaperfex, que permite contabilizar
varios tipos de eventos, realizando una estimación de la contribución de cada tipo de eve
el tiempo de ejecución. El comando necesario es:
NCASES NELSEL N_LATiteraciones
bucleinterno
siempreTHPLATE_MS
siempre
SANDWICH_MSeludir fases
(b) y (c)
1 30 2 80640 6 6 5
1 300 2 806400 57 56 45
2 300 2 1612800 116 113 90
Figura 2: Tiempos de ejecución (en segundos) para diferentes combinaciones deNCASES,
NELSEL y N_LAT.
7
en
do por
l código
aso de
se han
se ha
s en el
en las
jorado
cesos
ia. Para
l TLB
por
ero de
mero
s a la
% perfex -a -y new-dim >& fichero.txt
El resultado del análisis queda enfichero.txt. El contenido de este fichero se muestra
el anexo 1. Los resultados confirman que el tiempo de ejecución esta claramente domina
los fallos de TLB.
2.3 Preparación de las pruebas
En las secciones siguientes se describen las mejoras que se han realizado sobre e
original. Con el objetivo de validar cada una de las mejoras se ha seleccionado un c
prueba, con un tiempo de ejecución pequeño. Los resultados de este caso de prueba
almacenado en un fichero de referencia. Después de cada modificación del código,
ejecutado el caso de prueba y se han comparado los resultados con los almacenado
fichero de referencia. Esta estrategia a permitido detectar rápidamente errores
modificaciones realizadas y ha permitido avanzar con la seguridad de que el código me
es correcto.
3 Reducción de fallos del TLB
Los fallos de la jerarquía de memoria, y en particular, los fallos de TLB se deben a que ac
consecutivos del procesador corresponden a posiciones no consecutivas de memor
identificar los puntos del código en los que se concentra la mayor parte de los fallos de
han resultado muy útiles las herramientas deSpeedShop. En particular, el comando:
%ssrun -tlb_hwc new-dim
genera un fichero de nombrenew-dim.tlb_hwc.xxxx con información sobre número y
distribución de los fallos de TLB. Después, el comando:
%prof new-dim.tlb_hwc.xxxx -h
genera un informe (ver anexo 2) en el que se muestra la distribución de fallos de TLB
subrutinas y se identifican las líneas de código que son responsables de un mayor núm
fallos de TLB. De esta forma, ha resultado muy fácil identificar la causa de el elevado nú
de fallos de TLB. Los fallos se distribuyen entre varias líneas de código correspondiente
8
rse que
lejanas
TLB.
siones
en el
labras,
RSEL
EL de
o, se ha
os
fase (a). La figura 3 muestra una sección de esta parte del código. Puede observa
accesos consecutivos a la matriz EFORSEL corresponden a direcciones de memoria
entre sí y, por tanto, utilizan páginas diferentes, lo cual impide reusar la información del
Debe recordarse que, en FORTRAN 77, las estructuras matriciales de dos o más dimen
se almacenan en memoria de forma que los elementos de la matriz que sólo difieren
índice de la izquierda (leading dimension) aparecen próximos en memoria. En otras pa
primero se almacenan los elementos EFORSEL (*,1,1), después los elementos EFO
(*,2,1), etc.
La primera mejora que se ha realizado consiste en reorganizar la estructura EFORS
forma que en la fase (a) se accedan a posiciones consecutivas de memoria. En concret
cambiado la definición de la matriz como sigue:
C DECLARACION ORIGINAL
REAL*8 EFORSEL
DIMENSION EFORSEL(NELE,NSBCASE,8)
C NUEVA DECLARACION
DO J=1,8
TFORCE(J)=TFORCE(J)+XCFORCE(17)*EFORSEL(IEL,17,J)
TFORCE(J)=TFORCE(J)+XCFORCE(18)*EFORSEL(IEL,18,J)
TFORCE(J)=TFORCE(J)+XCFORCE(20)*EFORSEL(IEL,20,J)
TFORCE(J)=TFORCE(J)+XCFORCE(21)*EFORSEL(IEL,21,J)
TFORCE(J)=TFORCE(J)+XCFORCE(23)*EFORSEL(IEL,23,J)
TFORCE(J)=TFORCE(J)+XCFORCE(24)*EFORSEL(IEL,24,J)
TFORCE(J)=TFORCE(J)+XCFORCE(26)*EFORSEL(IEL,26,J)
TFORCE(J)=TFORCE(J)+XCFORCE(27)*EFORSEL(IEL,27,J)
ENDDO
Figura 3: Ejemplo de una sección de código de la fase (a) donde se concentran muchos de los fall
del TLB.
9
ORSEL
de la
e
en el
s, esta
as, que
n esta
ejoras
or de
S y
ser las
entre
a de
REAL*8 EFORSEL
DIMENSION EFORSEL(NSBCASE,8,NELE)
Por supuesto, se han modificado todas las líneas de código en las que aparece EF
para adaptarlas al nuevo formato.
Después de validar la modificación, se ha comprobado mediante la herramientaperfex
que el número de fallos del TLB se ha reducido de forma muy importante. El impacto
mejora puede apreciarse con más precisión al reevaluar los valores decoste_t, coste_s y
coste_e, tal y como se describió en la sección 2.2. Los nuevos valores estimados son:
coste_t = 1.24× 10-5 segundos
coste_s = 1.36× 10-5 segundos
coste_e = 2.48× 10-6 segundos
Puede apreciarse la espectacular reducción decoste_e(el coste de la fase (a)), que pon
de manifiesto el hecho de que los fallos de TLB pueden tener un peso muy importante
tiempo de ejecución. Por otra parte, para el caso del los datos de entrada disponible
mejora ha supuesto dividir por 5.71 el tiempo de ejecución.
4 Eliminación de operaciones innecesarias
Se ha detectado que el código original, con frecuencia, realiza operaciones innecesari
pueden tener una contribución significativa en el tiempo de ejecución. Las mejoras e
sección corresponden a la eliminación de operaciones innecesarias. Globalmente, las m
introducidas contribuyen a dividir el tiempo de ejecución del caso disponible por un fact
3.06.
Consideraremos, en primer lugar, mejoras en el código de las rutinas THPLATE_M
SANDWICH_MS, que, después de las mejoras introducidas en la sección 3, pasan a
rutinas que más contribuyen al tiempo de ejecución (basta ver la diferencia que hay
coste_ey coste_to coste_s).En segundo lugar, consideraremos mejoras en la estructur
bucles que permitirán reducir el número de operaciones realizadas en la fase (a).
4.1 Mejoras en la rutina THPLATE_MS
10
xtraido
que se
liminado
joras se
se han
en este
ciones.
rarquía
ncia de
r de 30
.
_LAT,
RCE
se (a),
sólo son
do. Una
de los
s. En
fican al
estra la
a los
Básicamente, se han introducido dos mejoras en esta rutina. Por una parte se han e
algunos invariantes del bucle principal, de forma que se ahorran algunas operaciones
estaban repitiendo innecesariamente. En segundo lugar, una serie de vectores se han e
y su función la realizan ahora una serie de variables escalares. El impacto de estas me
determina evaluandocoste_t. El nuevo valor es:
coste_t = 7.44× 10-6 segundos
4.2 Mejoras en la rutina SANDWICH_MS
Las mejoras introducidas en esta rutina son de diversa naturaleza. Por una parte,
desarrollado completamente varios bucles que sólo tenían dos iteraciones. También
caso se han extraido invariantes de bucles, con la consiguiente reducción de opera
Finalmente, se han reorganizado algunas estructuras de datos para reducir fallos de la je
(en la línea de la reorganización de EFORSEL descrita en la sección 3). Como consecue
estas mejoras, el nuevo valor decoste_s es:
coste_s = 8.06× 10-6 segundos
4.3 Reorganización de la estructura de bucles
Tal y como se describió en la sección 2.2, la fase (a) consiste en el producto de un vecto
elementos, XFORCE (1:30), por una matriz de 30× 8 elementos, EFORSEL (1:30,1:8,IEL)
Se ha observado que las diferentes iteraciones de los bucles JCASE, I_DYN, I_SBC, I
I_DF, e I_ENG simplemente realizan una modificación de los valores del vector XFO
(cada bucle modifica un subconjunto de estos valores). De esta forma, al realizar la fa
muchas de las operaciones que se hacen son las mismas que en la iteración anterior, y
nuevas las operaciones correspondientes a los elementos de XFORCE que han cambia
reorganización adecuada de los bucles y de las operaciones permite eliminar muchos
cálculos que en la versión original se repiten innecesariamente.
La figura 4 muestra de forma muy esquemática la organización original de los bucle
este esquema se muestra (en itálica) cuáles son los valores de XFORCE que se modi
comienzo de cada bucle. La estructura de bucles puede reorganizarse tal y como mu
figura 5. Ahora, al comienzo de cada bucle se realizan las operaciones asociadas
11
DO JCASE=1,NCASES
XFORCE (1:12) = ......
DO I_DYN=1,N_DYN_CASES
DO I_SBC=1,N_DYN_COMB
XFORCE (16,19,22,25) = ......
DO I_LAT=0,N_LAT
XFORCE (17,18,20,21,23,24,26,27) = ......
DO I_DF=1,N_DF
XFORCE (28,29,30) = ......
DO I_ENG=1,N_ENG
XFORCE (13,14,15) = ......
DO IEL=1,NELSEL
TFORCE (1:8) = XFORCE (1:30)× EFORSEL (1:30,1:8,IEL)
Figura 4: Organización original de los bucles de la rutina LOAD_COEFF.
12
los
DO JCASE=1,NCASES
XFORCE (1:12) = ......
DO IEL=1,NELSEL
TFCASE (1:8) = XFORCE (1:12) × EFORSEL (1:12,1:8,IEL)
DO I_DYN=1,N_DYN_CASES
DO I_SBC=1,N_DYN_COMB
XFORCE (16,19,22,25) = ......
TFSBC (1:8) = XFORCE (16,19,22,25) × EFORSEL (16,19,22,25,1:8,IEL)
DO I_LAT=0,N_LAT
XFORCE (17,18,20,21,23,24,26,27) = ......
TFLAT (1:8) = XFORCE (17,18,20,21,23,24,26,27) × EFORSEL
(17,18,20,21,23,24,26,27,1:8,IEL)
DO I_DF=1,N_DF
XFORCE (28,29,30) = ......
TFDF (1:8) = XFORCE (28,29,30) × EFORSEL (5,6,7,1:8,IEL)
DO I_ENG=1,N_ENG
XFORCE (13,14,15) = ......
TFENG (1:8) = XFORCE (13,14,15) × EFORSEL (13,14,15,1:8,IEL)
TFORCE (1:8) = TFCASE (1:8) + TFSBC (1:8) + TFLAT (1:8) + TFDF (1:8)
+TFENG (1:8)
Figura 5: Reorganización de los bucles de la rutina LOAD_COEFF para evitar repeticiones de cálcu
13
una sola
siste en
para
e deben
s entre
ás, las
e estas
indicar
tes del
es del
es, el
alelo.
e una
nde de
l bucle
les que
os los
elementos de XFORCE que son fijados por el bucle. Estas operaciones se hacen ahora
vez.
Reevaluamos ahora los valores decoste_t, coste_s y coste_epara determinar el impacto
de la mejora. Estos valores son:
coste_t = 5.58× 10-6 segundos
coste_s = 4.96× 10-6 segundos
coste_e = 6.20× 10-7 segundos
5 Paralelización
5.1 Cuestiones previas
El modelo de programación paralela que se ha usado es muy simple. Básicamente con
añadir al código FORTRAN 77 directivas para identificación de bucles paralelos y
planificación de los bucles. Repasamos en este punto algunos aspectos básicos qu
tenerse en cuenta al abordar la paralelización de la rutina LOAD_COEFF.
Un bucle paralelo es aquel en el que las diferentes iteraciones son independiente
sí, es decir, pueden ejecutarse en cualquier orden sin que varíe el resultado final. Adem
diferentes iteraciones deben escribir en posiciones diferentes de memoria, a menos qu
posiciones correspondan a variables locales (tal y como se describe más adelante). Para
que un bucle es paralelo basta insertar la directiva C$DOACROSS inmediatamente an
bucle. De esta forma, en el momento de la ejecución, el sistema distribuirá las iteracion
bucle entre los procesadores disponibles. Una vez terminadas todas las iteracion
programa continuará su ejecución en secuencia hasta el siguiente bucle paralelo.
La directiva C$DOACROSS debe especificar las variables locales del bucle par
Una variable local es aquella que contiene valores cuyo uso se circunscribe a la vida d
iteración. El valor que adquiere una variable local en una determinada iteración no depe
los valores de esa variables en iteraciones anteriores. En el momento de la ejecución de
paralelo, cada procesador creará una copia privada de las variables locales. Las variab
no se declaran como locales se considerarán compartidas. Durante la ejecución, tod
14
e los
es la
ativas:
ienzo
aciones
una
igna la
o de
nes por
ica es
ración.
a tiene
e tener
.
a y
ador se
bajo se
que el
os va
menor
l coste
r caso,
cación
ero de
.
bucles
o para
procesadores pueden acceden a las variables compartidas.
Se denomina planificación al reparto de las iteraciones del bucle paralelo entr
procesadores disponibles. La directiva C$DOACROSS debe indicar también cuál
estrategia de planificación que debe usarse. Básicamente, existen dos altern
planificación estática y planificación dinámica. La planificación estática asigna, al com
de la ejecución, N/P iteraciones consecutivas a cada procesador (N es el número de iter
del bucle y P elnúmero de procesadores). La planificación dinámica asigna inicialmente
iteración a cada procesador. Cuando un procesador finaliza una iteración se autoas
siguiente iteración no asignada.
En general, la planificación dinámica permite un mejor reparto del trabajo (equilibri
carga) porque un procesador deja de trabajar sólo cuando ya no quedan más iteracio
realizar (ya no queda más trabajo por hacer). El inconveniente de la planificación dinám
que se emplea un cierto tiempo en la operación de autoasignación de la siguiente ite
Este tiempo se denomina sobrecarga de planificación. Por contra, la planificación estátic
poca sobrecarga de planificación (el reparto se hace al comienzo). Sin embargo, pued
problemas de desequilibrio de carga cuando el coste de las iteraciones no es constante
Una variante que ofrece un compromiso entre planificación dinámica pur
planificación estática es la estrategia GSS. En este caso, inicialmente cada proces
autoasigna un grupo de K iteraciones consecutivas. Cuando un procesador acaba el tra
autoasigna un nuevo grupo de iteraciones consecutivas pero ahora de menor tamaño
anterior (por ejemplo, K-1). A medida que progresa la ejecución, el tamaño de los grup
decreciendo. La estrategia tiende a proporcionar un buen equilibrio de carga con
sobrecarga de planificación que la estrategia dinámica pura.
Dado un bucle paralelo, para elegir la estrategia adecuada hay que determinar si e
las iteraciones del bucle es constante o puede sufrir variaciones importante. En el prime
la planificación estática es la adecuada. En el segundo caso, debe optarse por planifi
dinámica pura o por GSS. La estrategia GSS puede ser más adecuada cuando el núm
procesadores es elevado, porque, en este caso, la sobrecarga de planificación aumenta
Finalmente, es importante mencionar que en el caso de una estructura de
imbricados, con varios bucles paralelos, es preferible paralelizar el bucle más extern
15
ura 5.
oncluye
1b).
e los
es no
ben en
ejoras
ual es
l bucle
te caso
, en las
sultado
de las
lelo.
do con
n una
iables
ma es
rutinas.
s. Cada
ncurrirá
temente
reducir los costes de planificación.
5.2 Paralelización de los bucles de la rutina LOAD_COEFF
En el caso de la rutina LOAD_COEFF, la estructura de bucles es la mostrada en la fig
Teniendo en cuenta las operaciones realizadas en el cuerpo del bucle más interno se c
que el único bucle paralelo es el bucle IEL. El motivo está en la fase (c) (ver figura
Diferentes iteraciones de cualquier otro bucle escriben sobre una misma posición d
vectores LC, DC, SB, etc, que son variables compartidas. Por tanto, estas iteracion
pueden ejecutarse en paralelo. Sin embargo, diferentes iteraciones del bucle IEL escri
posiciones diferentes de las variables compartidas. Afortunadamente, tras las m
introducidas en la sección 4, el bucle IEL es el segundo más externo (ver figura 5), lo c
adecuado para evitar que la sobrecarga de planificación sea elevada.
Tal y como se ha visto en las secciones anteriores, el coste de las iteraciones de
IEL es variable, dependiendo de si se pasa o no por las fases (b) y (c). Por tanto, en es
parece que la planificación dinámica es más adecuada que la estática. De todas formas
secciones siguientes se darán resultados para ambos tipos de planificación.
Cabe señalar ahora un aspecto que, en esta fase de paralelización, ha re
problemático. Se trata de la sobrecarga de creación-destrución de las variables locales
rutinas THPLATE_MS o SANDWICH_MS, que se activan en el cuerpo del bucle para
Hay que recordar que las diferentes versiones no paralelas del código se han compila
flag de compilación-static. Este flag hace que las variables locales de las rutinas se cree
sola vez al inicio de la ejecución del programa. Si no se usa el flag entonces las var
locales se crean dinámicamente al inicio de la rutina y se destruyen al final, y el progra
más lento como consecuencia de la sobrecarga de esta creación-destrucción dinámica.
El problema se suscita cuando se paraleliza el bucle que hace las llamadas a las
En esta situación, diferentes procesadores activarán diferentes instancias de las rutina
una de estas instancias creará su propia copia de las variables locales y, por tanto, se i
en una sobrecarga de creación-destrucción dinámica de variables locales, independien
del uso del flag -static.
16
adas a
g de
s a
eación-
que
a rutina
S y
etros
tro real
riantes
uentre
le IEL
aso de
este
ón de
te, y
solo
de 176
76/P
reparto
ación.
án los
La forma de eliminar esta sobrecarga es substituir, en el cuerpo del bucle, las llam
las rutinas por el código de dichas rutinas. De esta forma, puede eliminarse el fla
compilación-static sin perjuicio para la eficiencia del código porque ya no hay llamada
rutinas en el bucle que se paraleliza y, por tanto, desaparece la necesidad de cr
destrucción dinámica de variables locales. Esta operación, que se denominainlining, se ha
aplicado al caso de las rutinas THPLATE_MS y SANDWICH_MS. Los dos aspectos
deben tenerse presentes para realizar la operación son: (a) deben declararse en l
LOAD_COEFF aquellas variables que eran locales a las rutinas THPLATE_M
SANDWICH_MS, y (b) en el código de las rutinas deben usarse los nombre de los parám
reales, en lugar de los nombre de los parámetros formales (este fue el caso del paráme
TFORCE, que dentro de las rutinas era referenciado como FORCE).
Finalmente, el comando que se usa para la compilación paralela de todas las va
que se discuten en las secciones siguientes es:
%f77 -O3 -extend_source -mp new-dim.f -o new-dim
La opción-mpes la que indica que debe generarse código paralelo cuando se enc
la directiva C$DOACROSS en el código fuente.
En las secciones sucesivas mostraremos el impacto de la paralelización del buc
para diferentes estrategias de planificación. Para evaluar este impacto utilizaremos un c
prueba correspondiente a NCASES = 2, NELSEL = 2000 y N_MAX = 9. Lógicamente, en
caso de prueba ya no se han alterado las condiciones que fuerzan la ejecuci
THPLATE_MS o SANDWICH_MS. Por tanto, el coste de cada iteración no es constan
depende del valor de los datos de entrada.
El tiempo de ejecución de la rutina LOAD_COEFF para el caso de prueba, en un
procesador, teniendo en cuenta todas las mejoras descritas en las secciones 3 y 4 es
segundos. La paralelización ideal haría que el tiempo de LOAD_COEFF fuese 1
segundos, siendo P el número de procesadores. Este tiempo óptimo correspondería a un
perfecto del trabajo entre los procesadores y a una sobrecarga nula de planific
Evaluaremos la calidad de las diferentes alternativas en función de lo cerca que est
tiempos de ejecución de este tiempo óptimo.
17
es la
gura 6
ués de
bucle.
PLE
es las
n
5.3 Paralelización con planificación estática
Aunque previsiblemente, tal y como se ha justificado antes, la planificación estática no
más adecuada para el bucle IEL, mostramos aquí los resultados que se obtienen. La fi
muestra la directiva C$DOACROSS que se requiere para paralelizar el bucle IEL. Desp
la palabra LOCAL y entre paréntesis, aparece la lista de todas las variables locales del
Después, la palabra MP_SCHEDTYPE identifica el tipo de planificación. La opción SIM
corresponde a la planificación estática.
Para analizar el resultado de la paralelización han resultado de nuevo muy útil
herramientas deSpeedShop. En este caso, el comando:
%ssrun -pcsamp new-dim
genera varios ficheros de nombrenew-dim.pcsamp.xxxx (tantos como procesadores participa
C$DOACROSS LOCAL (IEL, J, a, TFORCE_JCASE, TFORCE_I_SBC,
C$& TFORCE_I_LAT, TFORCE_I_ENG, TFORCE_I_DF, TFORCE,
C$& I_DYN, N_DYN_COMB, I_SBC, I_LAT, I_DF, I_ENG,
C$& X15,X16,X19,X22,X25,X17,X18,X20,X21,X23,X24,X26,
C$& X27,X13,X14,
C$& CORE_BYPASS, FACING_BYPASS, J_C, SM1, SM2,H,
C$& S1,S2,S3,IX,TX,TY,CFI,FX,FY,FXY, SIGVM, FSM,B,C,ROOT,FS_MIN,
C$& SIGVMMX,SIG1,SIG2,SIG12,SIG13,SIG23,SIG_VM,I)
C$& MP_SCHEDTYPE=SIMPLE
DO IEL=1, NELSEL
Figura 6: Directiva para paralelización del bucle IEL, con planificación estática.
18
cada
iado al
ás
s
trabajo
eras,
más
e 62
en la ejecución). Los ficheros contienen información sobre el tiempo empleado por
procesador en cada rutina. Después, el comando:
%prof new-dim.pcsamp.xxxx
genera un informe correspondiente a la actividad desarrollada por el procesador asoc
ficheronew-dim.pcsamp.xxxx. En este informe se identifican fácilmente las rutinas que m
tiempo de ejecución ha consumido, para el procesador en cuestión.
Se han tomado medidas correspondientes a 4 y 8 procesadores. Las herramienta
mencionadas ha permitido determinar cuánto tiempo ha empleado cada procesador en
útil (operaciones de la rutina LOAD_COEFF) y cuánto tiempo a empleado en esp
operaciones de sincronización para reparto de trabajo, etc (ver el anexo 3 para
información sobre este punto). El tiempo de ejecución de LOAD_COEFF ha sido d
10
20
30
40
50
60
62 segundos
32 segundos
8 procesadores1 8
4 procesadores1 4
tiempo (segundos)
Figura 7: Distribución del trabajo entre los procesadores en el caso de planificación estática.
Cálculo
Inactividad
19
perar, el
n P=8),
7, en la
cada
IC.
e para el
con 4
figura 8
segundos con 4 procesadores y 32 segundos con 8 procesadores. Como era de es
resultado está lejos del óptimo (el óptimo sería 44 segundos con P=4 y 22 segundos co
debido a los problemas de desequilibrio de carga. Esto puede observarse en la figura
que se identifica el tiempo dedicado a trabajo útil y el tiempo de inactividad, para
procesador.
5.4 Paralelización con planificación dinámica
La planificación dinámica se específica mediante la opción MP_SCHEDTYPE = DYNAM
A pesar de que se, dada la naturaleza del bucle, se esperaban mejores resultados qu
caso de planificación estática, no ha sido así. En concreto, el tiempo de LOAD_COEFF
procesadores ha sido 90 segundos y con 8 procesadores ha sido 79 segundos. La
20
dores y
o total
ente, si
gundos
tas de
muestra la actividad de cada uno de los procesadores, en cada caso.
Los datos muestran que el trabajo está perfectamente repartido entre los procesa
que la sobrecarga de planificación es moderada. Lo más remarcable es que el tiemp
dedicado a trabajo útil ha aumentado respecto a los 176 segundos originales. Concretam
se suma el tiempo dedicado a trabajo útil de todos los procesadores se obtiene 355 se
con 4 procesadores y 624 segundos con 8 procesadores. Utilizando las herramien
10
20
30
40
50
60
90 segundos
79 segundos
8 procesadores1 8
4 procesadores1 4
tiempo (segundos)
Figura 8: Distribución del trabajo entre los procesadores en el caso de planificación dinámica.
Cálculo
Sobrecarga70
80
90
planificación
21
ortante
de la
dores
cache.
n gran
cache.
igo
artición
b). La
e los
ación
tanto,
obre la
alsa.
s de x
sadores
2 tienen
che
la
SpeedShopse detecta fácilmente que la causa de esta circunstancia es un aumento imp
de los fallos de cache. Esto revela un problema de compartición falsa, que es típico
planificación dinámica. La compartición falsa se produce cuando diferentes procesa
escriben en posiciones de memoria distintas pero que pertenecen a la misma línea de
Esto hace que el protocolo de mantenimiento de coherencia de memoria genere u
número de invalidaciones de líneas de cache, lo cual supone un aumento de los fallos de
Usando las herramientasSpeedShoppueden identificarse las secciones de cód
responsables de la mayor parte de los fallos de cache y, por tanto, causantes de la comp
falsa. El problema se centra en las escrituras sobre los vectores LC, DC, SB (ver figura 1
figura 9a ilustra la situación. En una iteración IEL se escribe sobre la posición IEL d
diferentes vectores (posiciones en gris oscuro, en la figura). En el caso de planific
dinámica, diferentes procesadores trabajan con valores consecutivos de IEL y, por
escribirán en posiciones consecutivas de los vectores. En otras palabras, esribirán s
misma linea de cache , provocando invalizaciones y fallos de compartición falsa.
La directiva DOACROSS ofrece un mecanismo simple para evitar la compartición f
En concreto, la opción CHUNK=x hace que los procesadores se autoasignen bloque
iteraciones consecutivas. De esta forma se reduce la frecuencia con la que dos proce
escriben en la misma línea de cache. Teniendo en cuenta que las líneas de la cache L
LC DC SB
IEL
Linea decache L2
16
IEL
16
LC
DC
SC
Linea decache L2
Figura 9: (a) Las escrituras sobre los vectores LC, DC, SB, etc, son las causantes de los fallos de ca
por compartición falsa. (b) Reorganización de las estructuras de datos para evitar
compartición falsa.
(a) (b)
22
, todas
sador.
hora,
uestran
usar la
o se
ación
de la
nta de
ión de
nguaje
ambién
(ahora
o se han
on
tamaño equivalente a 16 números reales (REAL*8), un valor adecuado para x es 16. Así
las posiciones marcadas con gris claro en la figura 9a sería escritas por un único proce
La figura 10 muestra los resultados con esta variante de la planificación dinámica. A
el tiempo con 4 procesadores es 57 segundos y con 8 procesadores es 30. Los datos m
un ligero aumento del desequilibrio de carga, lo cual es natural como consecuencia de
opción CHUNK. También se aprecia un aumento del tiempo de planificación que n
esperaba, dado que CHUNK=16 hace disminuir el número de operaciones de planific
(autoasignación de trabajo). La explicación es que la operación de autoasignación
siguiente iteración, que es la que se usa en planificación dinámica pura, se impleme
forma muy eficiente (una sola instrucción de lenguaje máquina). Por contra, la operac
autoasignarse las siguientes x iteraciones (con x >1) require varias instrucciones de le
máquina, lo cual hace crecer el coste de planificación. Finalmente, puede comprobarse t
que el trabajo útil realizado en total sigue siendo superior a los 176 segundos originales
es 214 segundos con 4 procesadores y 205 segundos con 8 procesadores). Por tanto, n
10
20
30
40
50
57 segundos
30 segundos
8 procesadores1 8
4 procesadores1 4
tiempo (segundos)
Figura 10: Distribución del trabajo entre los procesadores en el caso de planificación dinámica, c
opción CHUNK=16.
Cálculo
Sobrecargaplanificación
23
cuada
scriben
que los
le más
r sufre
llos de
de las
RE_MS
che si
tiene
a figura
182
ión falsa
, DC,
EL),
la figura
sería
obre las
he L2.
resuelto completamente los problemas de compartición falsa.
En muchos casos, la compartición falsa puede también eliminarse con una ade
reorganización de la operaciones y/o de las estructuras de datos. A continuación se de
dos mejoras en este sentido, que han permitido reducir significativamente el problema.
En primer lugar, se han usado de nuevo las herramientas deSpeedShoppara detectar las
líneas de código responsables de la mayor cantidad de fallos de cache. Se ha visto
problemas se centran en la siguiente sentencia, correspondiente a la fase (c) del buc
interno:
CORE_MS (IEL) = MIN (CORE_MS(IEL),SM1)
Los fallos de cache se producen en las lecturas del vector CORE_MS. Este vecto
constantes escrituras que provocan invalidaciones constantes y, por tanto, muchos fa
cache. Las escrituras se realizan en la propia sentencia anterior. Además, muchas
escrituras son innecesarias porque sólo es estrictamente necesario escribir cuando CO
(IEL) > SM1, lo cual ocurre pocas veces. Pueden, por tanto, reducirse los fallos de ca
reescribimos la sentencia de la siguiente forma:
IF (CORE_MS(IEL) .GT. SM1) THEN
CORE_MS (IEL) = SM1
ENDIF
Esta misma operación debe realizarse con otra sentencia de la fase (c), que
exactamente el mismo problema. Los resultados de esta modificación se muestran en l
11 (sólo para 8 procesadores). Ahora, el tiempo total dedicado a trabajo útil es de
segundos, que se acerca bastante a los 176 segundos originales. Por tanto, la compartic
se ha reducido de forma muy significativa.
Una solución alternativa consiste en estructutar la información de los vectores LC
SB, etc, en forma de matriz, para conseguir que los elementos LC(IEL), DC(IEL), SB(I
etc estén en posiciones consecutivas de memoria. Esta reorganización de muestra en
9b. Cada uno de los vectores es ahora una fila de la matriz. Una matriz de 15 filas
suficiente pero es conveniente que tenga 16 filas. De esta manera, todas las posiciones s
que escribe el procesador encargado de la iteración IEL están en la misma linea de cac
24
cache
hacer
ia en
antes
mejora
ación.
nque el
la fase
fallos
ugar de
eoría,
brio de
as con
baja
lmente
ión de
erentes
po de
ca del
ización.
La ventaja principal de esta mejora respecto a la anterior no es la reducción de fallos de
(en la anterior ya se había reducido muy significativamente) sino el hecho de que permite
planificación dinámica pura sin peligro de compartición falsa, con la consiguiente ganac
equilibrio de carga y la reducción de la sobrecarga de planificación, por los motivos
apuntados. Los resultados se muestran en la figura 12. Se puede apreciar una
significativa, fundamentalmente motivada por la reducción de la sobrecarga de planific
De hecho, la mejora consigue el óptimo con 8 procesadores (22 segundos), incluso au
tiempo de planificación no es nulo. Esto se explica porque al reemplazar los vectores de
(c) por una matriz se ha mejorado la localidad espacial y se ha reducido el número de
con relación a la versión secuencial en la que la fase (c) todavía usaba los vectores, en l
la matriz.
Consideramos finalmente la opción de planificación GSS, que debe permitir, en t
una reducción de la sobrecarga de planificación a costa de un aumento del desequili
carga. Los resultados para el caso de 8 procesadores no ofrece diferencias significativ
respecto al caso de planificación dinámica pura. De nuevo, la explicación radica en la
sobrecarga de la planificación dinámica pura, gracias a su implementacién especia
eficiente.
La conclusión del proceso de paralelización es que, para 8 procesadores, la opc
planificación dinámica pura es la que ofrece los mejores resultados, después de las dif
mejoras introducidas en el código. La paralelización, con 8 procesadores, divide el tiem
ejecución del caso disponible por un factor 7.64. Este valor esta razonablemente cer
óptimo, que sería 8, por lo que puede considerarse aceptable el resultado de la paralel
En este caso, no tiene sentido evaluar los valores de las constantescoste_t, coste_s y coste_e.
25
n
ra
10
20
30 28 segundos
8 procesadores1 8
tiempo (segundos)
Figura 11: Distribución del trabajo entre los procesadores en el caso de planificación dinámica, co
opción CHUNK=16, después de transformar algunas sentencias del programa.
Cálculo
Sobrecargaplanificación
10
20
30
22 segundos
8 procesadores1 8
tiempo (segundos)
Figura 12: Distribución del trabajo entre los procesadores en el caso de planificación dinámica pu
después de la reorganización de los vectores que motivan la compartición falsa.
Cálculo
Sobrecargaplanificación
26
iginal.
ódigo
mbién
an los
0
3 veces
ión, es
rutina
LB.
de 3
6 Conclusiones
La figura 13 resume el impacto de las diferentes mejoras realizadas sobre el código or
Para cada mejora, la columnatiempoindica en tiempo, en formatohoras:minutos:segundos,
requerido para resolver el caso práctico disponible, tras la mejora. El tiempo para el c
original es aproximado. La columnafactor de impactoindica el cociente entre el tiempo
correspondiente a la mejora anterior y el tiempo correspondiente a la nueva mejora, ta
para el caso práctico disponible. En aquellos casos que tiene sentido, también se d
valores de las constantescoste_t, coste_sy coste_e. Estos valores se dan en unidades de 1-6
segundos. El resultado global es que el código optimizado para 8 procesadores es 13
más rápido resolviendo el caso disponible que el código original en un procesador.
Una primera característica del código, que ha ayudado en el proceso de paralelizac
el hecho de que la inmensa mayoría del tiempo de ejecución se emplea en una sola
(LOAD_COEFF). Esto ha permitido ignorar el resto del programa.
El primer paso para mejorar la rutina LOAD_COEFF ha sido reducir de fallos de T
Los problemas se centraban en la fase (a), y más concretamente, en una matriz
tiempofactor deimpacto
coste_t coste_s coste_e
código original 24:00:00 71 70.5 55
Reducción fallos TLB 4:12:07 5.71 12.4 13.6 2.48
Mejora THPLATE 7.44
Mejora SANDWICH 8.06
Reorganización bucles 1:22:23 3.06 5.58 4.96 0.62
Paralelización (P=8) 0:10:50 7.64
Figura 13: Impacto de las diferentes mejoras realziadas sobre el código original.
27
imple
TLB,
se ha
con
),
E_MS
iones
o en
ción y
refleja
os
ión de
de
fácil
ón del
lema
tición
no ha
ación
de un
rga de
ente en
tras de
a y ha
e la
l tiempo
o, que
dimensiones (EFORSEL) a la que se accedía de forma muy ineficiente. Una s
modificación en la declaración de la matriz ha permitido eliminar muchos de los fallos de
con una espectacular reducción del tiempo de ejecución (tiempo del caso práctico
dividido por 5.71). La importancia de la reducción en los fallos de TLB puede apreciarse
más intensidad comprobando la reducción decoste_e, correspondiente al coste de la fase (a
donde se centraban los problemas de TLB. La reducción decoste_ty coste_stambién es muy
importante, aunque menor porque estos valores incluyen el coste de las rutinas THPLAT
y SANDWICH_MS, que no se ven afectadas por la mejora introducida.
El segundo grupo de mejoras tenía como objetivo eliminar algunas operac
innecesarias. Las mejoras en las rutinas THPLATE_MS y SANDWICH_MS han consistid
extraer invariantes de bucle, reconvertir matrices en escalares que realizan la misma fun
desarrollar completamente bucles con sólo dos iteraciones. El impacto de la mejoras se
en las reducciones decoste_ty coste_s. Además, una reorganización de los bucles imbricad
ha permitido ahorrar muchas operaciones en la fase (a), con la consiguiente reducc
coste_t, coste_sy coste_e. Globalmente, este conjunto de mejoras ha dividido el tiempo
ejecución del caso práctico por un factor 3.06.
El último paso ha sido la paralelización de la rutina LOAD_COEFF. Ha resultado
identificar el bucle a paralelizar y determinar que, por ser variable el coste de cada iteraci
bucle paralelo, la planificación dinámica (opción DYNAMIC) es la más adecuada. El prob
más significativo ha sido la detección y eliminación de fallos de cache debidos a compar
falsa. Para resolver el problema se han probado dos alternativas. La primera alternativa
requerido la modificación del código. Simplemente se ha usado opción de planific
CHUNK=16, que ha permitido una reducción importante de la compartición pero a costa
incremento en el desequilibrio de carga y, sobre todo, un aumento de la sobreca
planificación con respecto a la estrategia dinámica pura, que resulta especialmente efici
el ORIGIN. Una segunda alternativa ha consistido en una reorganización de las estrucu
datos y de algunas sentencias, que ha eliminado completamente la compartición fals
permitido volver a usar la planificación dinámica pura. Como conclusión, el impacto d
paralelización, de acuerdo con esta segunda alternativa, es que, con 8 procesadores, e
de ejecución del caso disponible se ha dividido por 7.64. Este factor es cercano al óptim
sería 8. Por tanto, la paralelización ha resultado razonablemente eficiente.
28
endo
s han
del
os de
o de
lsa
de los
ar la
velado
eneraban
en el
n este
r,”
he
Durante el proceso de paralelización han resultado muy útiles las herramientasperfexy
SpeedShop, que permiten contabilizar eventos tales como fallos de cache, TLB, etc, poni
de manifiesto los problemas del código analizado. Concretamente, las herramienta
resultado particularmente útiles para:
(a) Determinar que los fallos de TLB eran el problema más importante
código original
(b) Determinar las secciones de código en las que se concentran los fall
TLB
(c) Determinar las causas de una paralelización ineficiente (desequilibri
carga, sobrecarga de planificación o compartición falsa)
(d) Determinar las secciones de código responsables de la compartición fa
En algunos casos, una simple inspección del código ya había revelado algunos
problemas (es el caso de los fallos de TLB). Las herramientas han permitido confirm
hipótesis y revelar la magnitud del problema. En otros casos, las herramientas han re
problemas que habían pasado desapercibidos (es el caso de las dos sentencias que g
muchos fallos de compartición falsa).
Finalmente, hay que señalar que se han realizado otras mejoras cuyo impacto
rendimiento del código ha sido poco significativo. Por este motivo no se han descrito e
informe, aunque sí se han incluido en el código final.
7 Referencias
[LaLe97] J. Laudon, D. Lenoski, “The SGI Origin: A ccNUMA Highly Scalable Serve
24th Int’l Symp. on Computer Architecture, 1997, pp. 241-251.
[Yeag96] K.C. Yeager, “The MIPS R10000 Superscalar Microprocessor,”
IEEE Micro, Abril 1996, pp. 28-40.
[ZLTI96] M. Zagha, B. Larson, S. Turner, M. Itzkowitz, “Performance Analysis Using t
MIPS R10000 Performance Counters”
Supercomputing’96
29
30
Anexo 1
El informe que se muestra en este anexo se ha obtenido mediante el comando:
%perfex -a -y new-dim
El informa muestra una contabilización de diferentes eventos, con una aproximación del
impacto de cada tipo de evento en el tiempo de ejecución. Los eventos se contabilizan
mediante los contadores hardware disponibles en el procesador R10000. Estos contadores se
multiplexan durante la ejecución del programa y, por tanto, los valores del informe son
proyecciones estadísticas, sujetas a errores de predicción. En el caso de que se desee una
contabilización más precisa de un evento en particular, puede usarse el comando:
%perfex -e X -y new-dim
siendo X el identificador del evento a contabilizar. La columna de la izquierda en el informe
muestra los identificadores de todos los eventos que pueden contabilizarse.
El informe muestra el peso abrumador de los fallos de TLB. En la segunda parte del
informe se muestran algunas estadísticas que, si bien no han resultado particularmente útiles
durante el trabajo realizado, sí que pueden serlo en general.
31
WARNING: Multiplexing events to project totals--inaccuracy possible.
Based on 195 MHz IP27 Typical Minimum Maximum Event Counter Name Counter Value Time (sec) Time (sec) Time (sec)=================================================================================================================== 0 Cycles...................................................... 6253742080 32.070472 32.070472 32.07047216 Cycles...................................................... 6253742080 32.070472 32.070472 32.07047223 TLB misses.................................................. 149723216 52.280276 52.280276 52.280276 2 Issued loads................................................ 1934377792 9.919886 9.919886 9.91988625 Primary data cache misses................................... 139268688 6.434928 2.014039 6.43492818 Graduated loads............................................. 1036942976 5.317656 5.317656 5.317656 6 Decoded branches............................................ 765756384 3.926956 3.926956 3.92695621 Graduated floating point instructions....................... 437530528 2.243746 1.121873 116.674807 3 Issued stores............................................... 424030848 2.174517 2.174517 2.17451719 Graduated stores............................................ 291896848 1.496907 1.496907 1.49690724 Mispredicted branches....................................... 34131072 0.248544 0.112020 0.91366322 Quadwords written back from primary data cache.............. 10250336 0.202378 0.165057 0.23391826 Secondary data cache misses................................. 261568 0.101274 0.066210 0.112675 9 Primary instruction cache misses............................ 729712 0.067433 0.021068 0.067433 7 Quadwords written back from scache.......................... 1157952 0.038005 0.025119 0.03800510 Secondary instruction cache misses.......................... 2688 0.001041 0.000680 0.00115830 Store/prefetch exclusive to clean block in scache........... 5600 0.000029 0.000029 0.00002931 Store/prefetch exclusive to shared block in scache.......... 720 0.000004 0.000004 0.000004 1 Issued instructions......................................... 7556009120 0.000000 0.000000 38.748765 4 Issued store conditionals................................... 0 0.000000 0.000000 0.000000 5 Failed store conditionals................................... 0 0.000000 0.000000 0.000000 8 Correctable scache data array ECC errors.................... 0 0.000000 0.000000 0.00000011 Instruction misprediction from scache way prediction table.. 19376 0.000000 0.000000 0.00009912 External interventions...................................... 57792 0.000000 0.000000 0.00000013 External invalidations...................................... 165168 0.000000 0.000000 0.00000014 Virtual coherency conditions................................ 0 0.000000 0.000000 0.00000015 Graduated instructions...................................... 4270124128 0.000000 0.000000 21.89807217 Graduated instructions...................................... 4292009104 0.000000 0.000000 22.01030320 Graduated store conditionals................................ 0 0.000000 0.000000 0.00000027 Data misprediction from scache way prediction table......... 3135936 0.000000 0.000000 0.01608228 External intervention hits in scache........................ 56736 0.000000 0.000000 0.00000029 External invalidation hits in scache........................ 74048 0.000000 0.000000 0.000000
32
Statistics=========================================================================================Graduated instructions/cycle................................................ 0.682811Graduated floating point instructions/cycle................................. 0.069963Graduated loads & stores/cycle.............................................. 0.212487Graduated loads & stores/floating point instruction......................... 5.390272Mispredicted branches/Decoded branches...................................... 0.044572Graduated loads/Issued loads................................................ 0.536060Graduated stores/Issued stores.............................................. 0.688386Data mispredict/Data scache hits............................................ 0.022560Instruction mispredict/Instruction scache hits.............................. 0.026651L1 Cache Line Reuse......................................................... 8.541555L2 Cache Line Reuse......................................................... 531.437791L1 Data Cache Hit Rate...................................................... 0.895195L2 Data Cache Hit Rate...................................................... 0.998122Time accessing memory/Total time............................................ 2.046463L1--L2 bandwidth used (MB/s, average per process)........................... 144.076562Memory bandwidth used (MB/s, average per process)........................... 1.621677MFLOPS (average per process)................................................ 13.642784
33
Anexo 2
Para obtener el informe que se muestra en este anexo se requieren dos pasos. En primer lugar,
se ejecuta el comando:
%ssrun -tlb_hwc new-dim
Esto produce un fichero de nombrenew-dim.tlb_hwc.xxx, con información sobre fallos
de TLB. Después, el comando:
%prof new-dim.tlb_hwc.xxx -h
genera el informe, en el que se muestra, por una parte, la distribución de fallos de TLB por
subrutinas y, por otra parte, las líneas de código responsables de la mayor parte de los fallos.
Este informe permitió determinar que el motivo del gran número de fallos de TLB era la
organización de la matriz EFORSEL.
El mismo tipo de informe puede obtenerse para otros tipos de eventos. Basta usar la
opción adecuada en el comandossrun. Las opciones más útiles son:
-pcsamp distribución de ciclos
-dc_hwc distribución de fallos de cache L1
-dsc_hwc distribución de fallos de cache L2
34
-------------------------------------------------------------------------------Profile listing generated Thu Feb 12 11:55:51 1998 with: prof new-dim.tlb_hwc.m19034 -h-------------------------------------------------------------------------------
Counter : TLB missesCounter overflow value: 257Total number of ovfls : 580567CPU : R10000FPU : R10010Clock : 195.0MHzNumber of CPUs : 32
------------------------------------------------------------------------------- -p[rocedures] using counter overflow. Sorted in descending order by the number of overflows in each procedure. Unexecuted or inlined procedures are excluded.-------------------------------------------------------------------------------
overflows(%) cum overflows(%) procedure (dso:file)
565358( 97.4) 565358( 97.4) LOAD_COEFF (new-dim:/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f) 15197( 2.6) 580555(100.0) SANDWICH_MS (new-dim:/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f) 5( 0.0) 580560(100.0) ELEM_ULOADS (new-dim:/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f) 3( 0.0) 580563(100.0) rd_F (/usr/lib32/libftn.so:/comp56/mtibuild/v72/workarea/v7.2/libI77/rdfmt.c) 1( 0.0) 580564(100.0) do_fio64_mp (/usr/lib32/libftn.so:/comp56/mtibuild/v72/workarea/v7.2/libI77/fmt.c) 1( 0.0) 580565(100.0) rd_ned (/usr/lib32/libftn.so:/comp56/mtibuild/v72/workarea/v7.2/libI77/rdfmt.c) 1( 0.0) 580566(100.0) f_duped (/usr/lib32/libftn.so:/comp56/mtibuild/v72/workarea/v7.2/libI77/open.c) 1( 0.0) 580567(100.0) WRITE_OUT (new-dim:/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f)
580567(100.0) TOTAL
35
------------------------------------------------------------------------------- -h[eavy] using counter overflow. Sorted in descending order by the number of overflows in each line. Lines with no overflows are excluded.-------------------------------------------------------------------------------
overflows(%) cum overflows(%) procedure (file:line)
90850( 15.6) 90850( 15.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1055) 66683( 11.5) 157533( 27.1) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1080) 65730( 11.3) 223263( 38.5) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1049) 27161( 4.7) 250424( 43.1) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1061) 26923( 4.6) 277347( 47.8) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1075) 26168( 4.5) 303515( 52.3) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1073) 25015( 4.3) 328530( 56.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1063) 24834( 4.3) 353364( 60.9) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1062) 24670( 4.2) 378034( 65.1) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1067) 24332( 4.2) 402366( 69.3) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1065) 24272( 4.2) 426638( 73.5) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1064) 23625( 4.1) 450263( 77.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1066) 23530( 4.1) 473793( 81.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1068) 18814( 3.2) 492607( 84.8) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1044) 17672( 3.0) 510279( 87.9) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1074) 9133( 1.6) 519412( 89.5) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1089) 6389( 1.1) 525801( 90.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1099) 6157( 1.1) 531958( 91.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1092) 5892( 1.0) 537850( 92.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1060) 5883( 1.0) 543733( 93.7) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1079) 5753( 1.0) 549486( 94.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1054) 5496( 0.9) 554982( 95.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1048) 3098( 0.5) 558080( 96.1) SANDWICH_MS (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1260) 3022( 0.5) 561102( 96.6) SANDWICH_MS (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1290) 2759( 0.5) 563861( 97.1) SANDWICH_MS (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1288) 2746( 0.5) 566607( 97.6) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1111) 2738( 0.5) 569345( 98.1) SANDWICH_MS (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1261) 2727( 0.5) 572072( 98.5) SANDWICH_MS (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1249) 2716( 0.5) 574788( 99.0) LOAD_COEFF (/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new1-dim.f:1103)
36
Anexo 3
Para obtener el informe que se muestra en este anexo, debe ejecutarse primero el comando:
%ssrun -pcsamp new-dim
Este comando genera tantos ficheros de tiponew-dim.pcsamp.xxx como procesadores
han participado en la ejecución (4 en el ejemplo). Después, con el comando:
%prof new-dim.pcsamp.xxx
puede obtenerse un informe para cada procesador, con información sobre la distribución de
tiempo empleado por el procesador en cada una de las rutinas. En el caso del informe de este
anexo se ve cómo el procesador en cuestión ha empleado 30.49 segundos ejecutando código
útil (código de la rutina LOAD_COEFF) y ha estado 1.53 segundos inactivo por falta de
trabajo. Este tipo de informe es muy útil para determinar las causas de una paralelización
ineficiente (desequilibrio de carga, sobrecarga de planificación, compartición falsa, etc).
El mismo tipo de informe puede obtenerse para otros eventos (igual que el informe del
anexo 2).
37
-------------------------------------------------------------------------------Profile listing generated Thu Feb 12 16:34:29 1998 with:prof new-dim.pcsamp.p16894-------------------------------------------------------------------------------
samples time CPU FPU Clock N-cpu S-interval Countsize 3202 32.02s R10000 R10010 195.0MHz 31 10.0ms 2(bytes)
Each sample covers 4 bytes for every 10.0ms ( 0.03% of 32.0200s)
------------------------------------------------------------------------------- -p[rocedures] using pc-sampling. Sorted in descending order by the number of samples in each procedure. Unexecuted or inlined procedures are excluded.-------------------------------------------------------------------------------
samples time(%) cum time(%) procedure (dso:file)
3049 30.49s( 95.2) 30.49s( 95.2) __mpdo_load_coeff_1 (new-dim:/user1/uni/upc/ac/miguel/ESTRUCTURAS/curso/new6-dim.f) 153 1.53s( 4.8) 32.02s(100.0) __mp_slave_wait_for_work (/usr/lib32/libmp.so:/comp56/mtibuild/v72/workarea/v7.2/libmp/mp_parallel_do.s)
3202 32.02s(100.0) 32.02s(100.0) TOTAL
38
Listado del Código Optimizado
