Aplicaciones Multimedia en Pentium II: Impacto en el

X JORNADAS DE PARALELISMO, LA MANGA DEL MAR MENOR
- MURCIA, SEPTIEMBRE 1999
Aplicaciones Multimedia en Pentium II:
Impacto en el Rendimiento de su Cache de Datos.
Enrique F. Torres, José Luis Briz, Olaya Pastor y Víctor Viñals.
Resumen— Las aplicaciones multimedia empiezan a
ser importantes en la carga de trabajo de un computador
de sobremesa y se prevé que predominarán en un futuro
próximo. Estas aplicaciones tienen en común algunas características que no figuraban entre las que guiaron el diseño de los procesadores actuales. Este trabajo estudia el
impacto de ocho aplicaciones multimedia pertenecientes
al Conjunto MediaBench sobre la jerarquía de memoria
de un procesador Celeron (core Mendocino) de Intel. Estas aplicaciones utilizan de forma notable los servicios de
entrada/salida del sistema operativo, de modo que para
estudiar a fondo su comportamiento es preciso monitorizar la actividad en el mismo, bien simulando el código en
modo sistema, bien utilizando registros específicos provistos en algunos procesadores recientes. En este caso hacemos uso de los Contadores Hardware del Pentium II para
obtener datos a partir de ejecuciones reales. La conclusión
principal es que la presión ejercida sobre el subsistema de
memoria es muy débil, y además insensible a la complejidad del conjunto de datos de entrada. Parece por tanto
aconsejable una revisión profunda de estos benchmarks y
de otros similares, dada su importancia para el diseño de
futuras jerarquías de memoria optimizadas para carga
multimedia.
I. I NTRODUCCIÓN
que una aplicación es multimedia si está
D
relacionada con la imagen o el sonido en cantidades y velocidades similares a las que entiende o
ECIMOS
produce una persona. Entre ellas podemos incluir el
procesado y reconocimiento de documentos, la generación de imágenes (gráficos), la compresión (transmisión y almacenamiento de imagen y sonido), el
reconocimiento de voz, el cifrado, etc.
Desde el punto de vista del procesador, las aplicaciones multimedia tienen características similares [1]:
• Datos de poca precisión (8 ó 16 bits), organizados
en estructuras grandes.
• Cálculos regulares y simples, con paralelismo
inherente,
• Requisitos de Tiempo Real,
• Múltiples flujos concurrentes (p.ej. video y audio).
Este trabajo ha sido financiado en el marco del proyecto TIC980511-C02 de la CICYT. Los autores trabajan en el Depto. de
Informática e Ing. de Sistemas de la Univ. de Zaragoza, y pueden ser
contactados en {ktm, briz,victor}@posta.unizar.es
.
• Elevados caudales (anchos de banda, MB/s) entre el
procesador y la memoria; pobre localidad temporal.
Las características de tiempo real y los altos anchos
de banda requeridos están dificultando la integración
de aplicaciones que precisen a la vez visualización, cálculo, almacenamiento y transmisión. Aunque la industria produce equipos con el doble de potencia y la
mitad de coste cada 18 meses, la demanda multimedia
precisa un crecimiento aún más rápido [7].
Sin embargo las características anteriores no dominan en los benchmarks utilizados en el diseño de los
actuales procesadores de propósito general, principalmente basados en aplicaciones de cálculo científico[4].
Todo ello está motivando la elaboración de benchmarks alternativos. Uno de ellos es el denominado
MediaBench [3], que reúne 19 aplicaciones representativas de la carga multimedia actual, escritas en C y por
tanto fácilmente portables a otras máquinas. Por otra
parte, se estima que las aplicaciones multimedia se ejecutarán mayoritariamente en sistemas de sobremesa y
con arquitectura Intel, pero los estudios publicados han
sido realizados siempre sobre plataformas HP, Alpha o
SPARC [3, 8, 5, 6].
Por todo lo anterior, el objeto de este trabajo ha sido
examinar el comportamiento de algunas aplicaciones
del MediaBench sobre la jerarquía de memoria de un
procesador Intel orientado a sistemas de sobremesa de
bajo coste. Hemos elegido el Intel Celeron core Mendocino, que comparte núcleo con el Pentium II y posee dos
niveles de cache integrados en el chip. El primer nivel
está partido (16 KBd + 16 KBi), con asociatividades 2
(cache de datos) y 4 (cache de instrucciones). El segundo nivel (128 KB) está unificado y tiene asociatividad
4. El tamaño de bloque es en ambos casos 32B [9].
Las aplicaciones multimedia utilizan de forma notable los servicios de entrada/salida del sistema operativo. Para estudiar a fondo su comportamiento es
preciso monitorizar la actividad en el mismo, bien simulando el código en modo sistema, bien utilizando registros específicos provistos en algunos procesadores
recientes. No se dispone hasta la fecha de simuladores
de la arquitectura Intel que permitan simular código de
sistema operativo con eficiencia. Sin embargo el Pentium II, como todos los procesadores Intel a partir del
Pentium, está dotado de una serie de registros que permiten monitorizar su actividad interna. En consecuencia hemos optado por utilizar algunos de estos
ENRIQUE F. TORRES, JOSÉ LUIS BRIZ, OLAYA PASTOR Y VÍCTOR VIÑALS.
registros, adecuados para el estudio de los accesos a
memoria.
cartando aquellas cuyo tiempo de ejecución se desvía
mucho de la media.
En lo que sigue se introduce la metodología utilizada (Sección II ), se describe la carga de trabajo
(Sección III ) y se discuten los resultados (Sección IV).
La Sección V cierra la comunicación recogiendo las
principales conclusiones.
III. C ARGA DE TRABAJO.
TABLA I
EVENTOS SELECCIONADOS
INST_RETIRED
Número total de instrucciones
retiradas
DATA_MEM_REF
Todos los loads y stores, no incluye
referencias a e/s.
DCU_LINES_IN
Total de líneas que han sido
introducidas en la cache de datos.
CPU_CLK_UNHALTED
Ciclos con el procesador no parado,
permite discernir ejecución en modo
usuario y modo privilegiado.
Las mediciones pueden variar por diversos factores. Para poder unificar y comparar entre diferentes
ejecuciones se han realizado múltiples muestras, des-
G721
Cto. De Datos
GSM
Hemos desarrollado herramientas para acceder a
los contadores bajo el sistema operativo Microsoft
Windows NT, pero en este sistema no ha sido posible
aislar la actividad de e/s ni controlar los cambios de
contexto. Hemos elegido Linux porque la disponibilidad de su código fuente nos ha permitido realizar las
modificaciones necesarias en el núcleo para conseguir
lo anterior. También se ha modificado e instalado un
driver que permite el acceso a los contadores hardware
desde una aplicación de usuario, ya que las instrucciones que escriben tanto los contadores como los registros de control deben ejecutarse en modo
privilegiado. Los detalles de este trabajo se describen
en [11]. De todos los eventos que se pueden medir con
estos registros se han seleccionado los muestrados en
la Tabla I; cada uno se ha monitorizado en modo
usuario y en modo sistema.
TABLA II
RESUMEN APLICACIONES ELEGIDAS, DATOS EN MILLONES.
JPEG
De entre los registros específicos del Celeron core
Mendocino, se han utilizado los PMC (Performance
Monitoring Counters), que permiten monitorizar el
comportamiento del procesador [10]. El denominado
TSC (Time Stamp Counter) tiene 64 bits, y cuenta los
ciclos de reloj que lleva el procesador en marcha.
Otros dos registros (CTR0 y CTR1) permiten contar
las ocurrencias o la duración de eventos como el
número de instrucciones ejecutadas, las referencias a
memoria, los fallos en cache de datos o instrucciones,
etc. Dos registros de control indican qué eventos se
deben monitorizar, si se computan ocurrencias o
duración y en que modo de ejecución hacerlo (Usuario
o Sistema).
MPEG2
II. M ETODOLOGÍA
De entre los 19 programas del MediaBench se han
seleccionado los 8 que figuran en la Tabla II, que
resume el número de instrucciones ejecutadas por cada
benchmark según la carga de entrada. Se han escogido
porque son representativos del MediaBench en cuanto
a tasa de fallos, y porque van acompañados de dos o
más conjuntos de datos de entrada. Corresponden a la
pareja codificador – decodificador de las siguientes
aplicaciones
clinton.g721
S_16_44.g721
clinton.g721.pcm
g721e
S_16_44.pcm
clinton.pcm.gsm
gsmd
S_16_44.pcm.gsm
clinton.pcm
gsme
S_16_44.pcm
testimg.jpg
jpegd
monalisa.jpg
testimg.ppm
jpege
monalisa.ppm
test.m2v
mpeg2d mei16v2.m2v
tek.m2v
test.m2v
mpeg2e mei16v2.m2v
tek.m2v
g721d
Nº de Instrucciones
USR
SO
Total
271
0,6
272
412
1
413
285
0,3
286
455
0,5
455
73
1
75
116
2
118
177
0,68
179
281
1
282
6
0,32
6
41
2
43
16
0,19
16
126
0,51
126
21
0,34
22
142
1
144
1.002
6 1.008
162
0,52
162
1.336
1 1.337
5.076
11 5.086
• G.721: Implementación de referencia del estándar
de compresión de voz del ITU.
• GSM: Codificador de voz del estándar Europeo de
telefonía móvil digital GSM.
• JPEG: Estándar de compresión de imágenes.
• MPEG2: Estándar actual dominante para la transmisión de video de alta calidad.
Inicialmente el MediaBench disponía de un juego
de pruebas de tamaño muy reducido [2, 6]. Sus integradores presentaron posteriormente un segundo juego
con tamaños mayores. En el estudio presentamos datos
de ambos. Así por ejemplo, en el primer conjunto de
datos proporcionado, la imagen suministrada para
JPEG tenia unas dimensiones de 227x149 pixels (5756
bytes codificada y 101484 bytes decodificada), mientras que con el segundo se incluye una imagen más
compleja, y de 459x703 pixels (31074 y 968046 bytes
respectivamente). Para MPEG2 en ambos casos se
trata de un video formado por 4 imágenes de 352x240
pixels (calidad similar a VHS) en la primera entrega y
de 720x486 pixels (Broadcast) en la segunda. A estos
X JORNADAS DE PARALELISMO, LA MANGA DEL MAR MENOR
- MURCIA, SEPTIEMBRE 1999
CPI
CPI Total
25,000
1,600000
USR
1,400000
SO
Total
20,000
1,200000
15,000
1,000000
0,800000
10,000
0,600000
0,400000
5,000
0,200000
jpe
ge
2
m
pe
g2
d1
m
pe
g2
d2
m
pe
g2
d3
m
pe
g2
e1
m
pe
g2
e2
m
pe
g2
e3
jpe
gd
2
jpe
ge
1
jpe
gd
1
gs
m
e2
gs
m
e1
gs
m
d2
gs
m
d1
g7
21
d
g7 1
21
d
g7 2
21
e
g7 1
21
e
gs 2
m
d
gs 1
m
d
gs 2
m
e
gs 1
m
e
jpe 2
gd
jpe 1
gd
jpe 2
ge
jpe 1
m ge2
pe
g
m 2d1
pe
g
m 2d2
pe
g
m 2d3
pe
g
m 2e1
pe
g
m 2e2
pe
g2
e3
g7
21
d1
g7
21
d2
g7
21
e1
g7
21
e2
0,000
0,000000
RPI
RPI Total
1,6000
0,900000
USR
SO
1,4000
0,800000
0,700000
1,2000
0,600000
1,0000
0,500000
0,400000
0,8000
Total
0,6000
0,300000
jpe
ge
2
m
pe
g2
d1
m
pe
g2
d2
m
pe
g2
d3
m
pe
g2
e1
m
pe
g2
e2
m
pe
g2
e3
jpe
gd
2
jpe
ge
1
jpe
gd
1
gs
m
e2
g7
21
d
g7 1
21
d
g7 2
21
e
g7 1
21
e
gs 2
m
d
gs 1
m
d
gs 2
m
e
gs 1
m
e
jpe 2
gd
jpe 1
gd
jpe 2
ge
jpe 1
m ge2
pe
g
m 2d1
pe
g
m 2d2
pe
g
m 2d3
pe
g
m 2e1
pe
g
m 2e2
pe
g2
e3
gs
m
e1
0,0000
gs
m
d2
0,2000
0,000000
g7
21
d1
g7
21
d2
g7
21
e1
g7
21
e2
0,100000
gs
m
d1
0,4000
0,200000
Tasa de Fallos
Tasa de Fallos Total
0,160000
0,030000
0,140000
0,025000
0,120000
0,020000
0,100000
0,015000
0,080000
USR
SO
Total
0,060000
0,010000
jpe
gd
1
jpe
gd
2
jpe
ge
1
jpe
ge
2
m
pe
g2
d1
m
pe
g2
d2
m
pe
g2
d3
m
pe
g2
e1
m
pe
g2
e2
m
pe
g2
e3
g7
21
d1
g7
21
d2
g7
21
e1
g7
21
e2
gs
m
d1
gs
m
d2
0,000000
g7
21
d
g7 1
21
d
g7 2
21
e
g7 1
21
e
gs 2
m
d
gs 1
m
d
gs 2
m
e
gs 1
m
e
jpe 2
gd
jpe 1
gd
jpe 2
ge
jpe 1
m ge2
pe
g
m 2d1
pe
g
m 2d2
pe
g
m 2d3
pe
g
m 2e1
pe
g
m 2e2
pe
g2
e3
0,020000
0,000000
gs
m
e1
gs
m
e2
0,040000
0,005000
Fig.1. Resultados: CPI, RPI Y Tasa de fallos Agregadas y Disgregadas en modo Usuario (USR), modo Sistema Operativo
(S.O.) y su relacción con el total.
dos conjuntos de datos se ha añadido uno más pequeño
(128x128) suministrado junto con el código para comprobar el correcto funcionamiento y que puede ser representativo de video de baja calidad para su
transmisión por Internet.
IV. RESULTADOS
La Figura 1 resume los resultados obtenidos. El
sufijo de cada aplicación indica el conjunto de datos
seleccionado. Las métricas obtenidas son : Ciclos por
Instrucción (CPI), Referencias por Instrucción (RPI) y
tasa de fallos en la memoria cache de datos de primer
nivel. Nótense las diferencias de escala entre las graficas de la izquierda y las de la derecha. Comentaremos
en primer lugar las actividades de usuario y sistema
operativo agregadas. Posteriormente estudiaremos por
separado el comportamiento de ambos y su interacción.
A Actividad agregada
Se distinguen claramente dos grupos de programas,
bien diferenciados según su tasa de fallos. En cualquiera de los casos no se llega al 3% y la mayoría no
superan un 0,5% de fallos. Sólo parece existir una
dependencia evidente entre tasa de fallos y CPI en el
decodificador de MPEG2 (mpeg2d). Ateniéndonos al
comportamiento experimentado por las aplicaciones
según la carga de trabajo se puede observar que la tasa
de fallos apenas varía — incluso disminuye, al aumentar la complejidad de los datos— y en cualquier caso
no cambia de forma significativa su valor absoluto.
Ocurre en general lo mismo para el CPI, exceptuando
las aplicaciones mpeg2e y g721d.
Si se tiene en cuenta que aproximadamente el 50%
de las instrucciones hacen referencia a memoria
debería existir una correlación clara entre fallos y CPI.
Esto ocurre en jpegd2, jpege2 y mpegd2 al variar la
carga de trabajo, lo cual indica que efectivamente
puede existir dependencia entre prestaciones y jerarquía de memoria, pero su contribución es relativamente pequeña.
ENRIQUE F. TORRES, JOSÉ LUIS BRIZ, OLAYA PASTOR Y VÍCTOR VIÑALS.
B Actividad disgregada
Las tasas de fallos en modo sistema son muy superiores a las del modo usuario. Sin embargo las métricas
globales o agregadas están determinadas de forma casi
exclusiva por la actividad en modo usuario, debido a
que el número de instrucciones ejecutadas en este
último modo es de dos o tres ordenes de magnitud
mayor (salvo en el caso jpegd). Por otra parte, al atenernos a los fallos en modo sistema no se observan los
dos grupos diferenciables anteriormente según su tasa
global de fallos.
Tanto en absoluto como en relativo existe una correlación muy evidente entre CPI y tasa de fallos en todas
las aplicaciones y bajo cualquier carga de trabajo (salvo
quizás en mpeg2e3, cuyo elevado CPI (~21) no guarda
relación con su modesta tasa de fallos (~4,5%). El CPI
en modo sistema supera en todos los casos ampliamente
el valor de 3 (dando de media un 5,39). Ello es posiblemente debido a las instrucciones de movimiento de
cadena, que se contabilizan como una única instrucción,
aunque cada una de ellas realizan múltiples operaciones
y referencias a memoria. Estas instrucciones también
explican que la tasa de referencias a memoria por
instrucción (rpi) sea también mayor en modo sistema,
ya que son las instrucciones que realizan las transferencias entre el buffer de usuario y la buffer-cache de
Linux.
V. CONCLUSIONES Y LÍNEAS ABIERTAS
El MediaBench es una de las propuestas recientes
de benchmark multimedia que ha comenzado a utilizarse en estudios sobre procesadores y jerarquías de
memoria orientados al desarrollo de sistemas capaces
de responder con eficiencia a los requerimientos de las
aplicaciones multimedia. Hemos analizado aquí el
comportamiento de ocho de los programas que componen este benchmark, sobre la jerarquía de memoria
de un procesador Celeron core Mendocino, utilizando
algunos de sus registros específicos. La presión ejercida sobre el subsistema de memoria ha resultado ser
muy débil, incluso al considerardatos de entrada más
complejos que los inicialmente propuestos en el benchmark.
Sin embargo, MediaBench está siendo utilizado
para dimensionar o proponer mecanismos relacionados
con la jerarquía de memoria, por ejemplo, anchos de
banda entre niveles [2,5] o algoritmos de prebúsqueda
para la cache de datos [8]. En ninguno de estos trabajos
se observa el impacto de sus propuestas en el tiempo de
ejecución, impacto que en Pentium, y a la luz de los
resultados que presentamos puede presumirse pequeño.
Las aplicaciones del MediaBench fueron seleccionadas por estar escritas en alto nivel y ser fácilmente portables a distintas máquinas, y por ello no
están optimizadas para ninguna implementación. Su
sintonización y el uso de las distintas extensiones multimedia (MMX, VIS, MAX) puede hacer que dejen de
estar limitadas por CPU y pasen a estar limitadas por
memoria [6]. Pero en cualquier caso, parece conveniente proceder a una revisión profunda de las aplicaciones de prueba necesarias para guiar el diseño de una
jerarquía de memoria optimizada para carga multimedia.
REFERENCIAS
[1]
K. Diefendorff y Pradeep K. Dubey. How Multimedia Workloads Will Change Processor Design. IEEE Computer, Sep. 97,
p.43-45
[2] Jason Fritts, Wayne Wolf and Bede Liu. Understanding Multimedia Application Characteristics for Designing Programable
Processors, SPIE Photonics West, Media Processors, Jan 99.
[3] Chunho Lee, Miodrag Potkonjak, and William H. MangioneSmith. MediaBench: A Tool for Evaluating and Synthesizing
Multimedia and Communications Systems. Proc IEEE/ACM
Int. Symp. Micro-architecture (Micro 30), IEEE Press New
York, 1997.
[4] Ruby B. Lee and Michael D. Smith, Media Processing : A New
Design Target. IEEE Micro, August 1996, pp.6-9.
[5] Peter Soderquist and Miriam Leeser, Optimizing the Data
Cache Performance of a Software MPEG2 Video Decoder.,
ACM Multimedia 97, Nov. 1997.
[6] Parthasarathy Ranganathan, Sarita Adve and Norman P.
Jouppi, Performance of Image and Video Procesing with General-Purpose Processors and Media ISA Extensions. 26th
ISCA, May 1999
[7] Albert Yu, The Future of Microprocessors. IEEE Micro, Dec
1996, pp. 46-53
[8] D.F. Zucker, M.J. Flynn and R.B. Lee, A Comparison of Hardware Prefetching Techniques For Multimedia Benchmarks.
Technical Report CSL-TR-95-683, Diciembre 1995
[9] Intel Corp. Intel® Celeron™ at 266 MHz, 300 MHz, 300A
MHz,333 MHz, 366 MHz and 400 Mhz. Intel Application Note
245088 1999.
[10] Pentium Processor Family Developer Manual. Intel, Chapter
16, 1997
[11] Olaya Pastor Ibanez. Medidas de Rendimiento en Pentium con
contadores hardware: Métodos e Interpretación. Proyecto
Final de Carrera, Centro Politécnico Superior, Universidad de
Zaragoza. c/María de Luna, 3 50015 Zaragoza. Julio 1999