ACTAS DE LAS XVI JORNADAS DE PARALELISMO (JP2005)

ORGANIZADAS POR:
Grupo de Investigación en Circuitos y Sistemas para el Procesamiento de la
Información (CASIP)
Departamento de Arquitectura y Tecnología de Computadores de la Universidad
de Granada
COMITÉ DE COORDINACIÓN
Ramón Beivide Palacios (UC)
Jesús Carretero Pérez (UCIII)
José Duato Marín (UPV)
Inmaculada García Fernández (UAL)
Emilio López Zapata (UMA)
Emilio Luque Fadón (UAB)
Pedro de Miguel Anasagasti (UPM)
Alberto Prieto Espinosa (UGR)
Ana Ripoll Aracil (UAB)
Francisco Tirado Fernández (UCM)
Mateo Valero Cortés (UPC)
Victor Viñals Yúfera (UZ)
COMITÉ ORGANIZADOR (UGR)
Julio Ortega Lopera
Mancia Anguita López
Pedro A. Castillo Valdivieso
Antonio Cañas Vargas
Antonio F. Díaz García
Jesús González Peñalver
Francisco Illeras García
Manuel Rodríguez Álvarez
Moisés Salmerón Campos
Presentación
Bienvenidos a Granada, a esta nueva edición de las Jornadas de Paralelismo que
vuelven a celebrarse aquí, en este caso junto con otros 24 simposios que
conforman la primera edición del Congreso Español de Informática (CEDI).
En estos años, el interés y la relevancia del paralelismo han seguido
creciendo. Aunque en algunos casos se considera una técnica limitada al ámbito
de los supercomputadores, actualmente los computadores paralelos son
imprescindibles, no sólo para el desarrollo de la ciencia y la ingeniería, sino
también para muchos aspectos de la vida cotidiana. De hecho, el paralelismo,
junto con la localidad de acceso a los datos, puede ser considerado uno de los
principios a través de los que la arquitectura del computador ha evolucionado,
traduciendo las posibilidades que ofrece la tecnología en capacidades de
cómputo y prestaciones cada vez mayores. La asignación de recursos para
implementar el paralelismo y mejorar la localidad es una tarea esencial, que
debe realizarse a partir de la comprensión de los efectos en las prestaciones del
sistema de la interacción entre paralelismo y localidad, que se da en el
computador a todas las escalas.
Por tanto, el ámbito de estudio del paralelismo incluye tanto el diseño de
nuevos procesadores, jerarquías de memoria, redes y sistemas de interconexión
y de E/S de altas prestaciones, como la creación de entornos de desarrollo y de
gestión de recursos a través de sistemas operativos eficientes, y requiere la
cooperación de especialistas en las áreas mencionadas. En este contexto, las
iv Presentación
Jornadas de Paralelismo, que vienen celebrándose anualmente desde 1990,
constituyen el punto de encuentro de los grupos de investigación españoles que
trabajan en los distintos ámbitos del paralelismo.
En estas Actas de las XVI Jornadas de Paralelismo se recogen 93 trabajos que
se han clasificado en siete apartados. Dentro del epígrafe Procesadores
paralelos y Multiprocesadores se han incluido 12 trabajos que describen
diversos aspectos del paralelismo en la microarquitectura del procesador y en la
arquitectura de los multiprocesadores. En el apartado relacionado con las
Tecnologías de Grid, los Clusters y las Plataformas Distribuidas, se han
incluido 18 trabajos que tratan problemas relacionados con la gestión, la
evaluación de prestaciones, y la utilización eficiente de estas plataformas. En
otra sección, denominada Redes y Comunicación, se incluyen 23 trabajos que
abordan, entre otras, cuestiones relacionadas con la calidad de servicio, la
problemática del encaminamiento, la externalización de protocolos, etc.
También se han presentado trabajos que analizan aspectos relacionados con la
docencia en arquitectura de computadores (7 trabajos en el apartado de
Docencia en Arquitectura y Tecnología de Computadores) y con el desarrollo de
modelos analíticos o de simulación para evaluar prestaciones (7 trabajos sobre
Evaluación de Prestaciones, Modelado y Simulación).
Tampoco pueden faltar los trabajos que abordan cuestiones relacionadas con
los algoritmos paralelos y las técnicas de programación paralela (6 trabajos en la
sección de Algoritmos y Técnicas de Programación Paralela) ni los que
describen aplicaciones que aprovechan el paralelismo (20 trabajos en el apartado
de Aplicaciones). Precisamente, las perspectivas en arquitectura de
computadores están determinadas, además de por las posibilidades que ofrecen
las mejoras tecnológicas, por los condicionantes de las aplicaciones dominantes
XVI Jornadas de Paralelismo v
en el mercado: la evolución futura de los computadores depende de las
interacciones entre la tecnología, la arquitectura, las aplicaciones y el mercado.
Junto con las 15 sesiones en las que se expondrán los 92 trabajos que hemos
indicado, también se incluye una sesión de ponencias de empresas vinculadas
con el paralelismo y una conferencia a cargo del profesor Gurindar S. Sohi.
Esperamos que estas Jornadas os resulten provechosas. Como comentamos al
iniciar esta presentación, en esta ocasión, las Jornadas se llevan a cabo en
paralelo con otros 24 simposios en el contexto del Congreso Español de
Informática (CEDI). Se trata de una buena oportunidad para que, a través de las
sesiones plenarias, las mesas redondas, etc., podamos intercambiar ideas,
proyectos, y planteamientos con otros compañeros de otras áreas de la
investigación en informática. Esperamos que esta interesante iniciativa se
consolide a lo largo de sucesivas ediciones.
Finalmente, os deseamos que estos días os resulten agradables, y disfrutéis de
la belleza y el ambiente de Granada.
Granada, junio de 2005
Comité Organizador
CONTENIDOS
Arquitectura del Procesador y Multiprocesadores..........................................1
Predicting two streams per cycle...........................................................................3
Oliverio J. Santana, Alex Ramírez, Mateo Valero
Eficacia vs. Eficiencia: Una Decisión de Diseño en RunAhead..........................11
Tanausú Ramírez García, Adrián Cristal, Oliverio J. Santana, Alex Pajuelo,
Mateo Valero
A Per-Module Adaptive Fetch Mechanism.........................................................19
Daniel Chaver, Miguel Ángel Rojas, Luis Piñuel, Manuel Prieto, Francisco
Tirado
Gestión eficiente de la LSQ basada en mecanismos de filtrado..........................27
Fernando Castro Rodríguez, Daniel Chaver, Luis Piñuel, Manuel Prieto,
Francisco Tirado
Performing fair comparison studies of leakage reduction policies......................35
Salvador Petit, Julio Sahuquillo
Toward the Loop Processor Architecture (LPA).................................................43
Alejandro García Arbelo, Oliverio J. Santana, Pedro Medina, Enrique
Fernández García, Adrián Cristal, Mateo Valero
Dynamically Controlled Resource Allocation in SMT Processors.....................51
Francisco Javier Cazorla Almeida, Enrique Fernández García, Alex Ramírez,
Mateo Valero
hdSMT: An Heterogeneity-Aware Simultaneous Multithreading Architecture..59
Carmelo Alexis Acosta Ojeda, Ayose Falcón, Alex Ramírez, Mateo Valero
Metrics for the Evaluation of SMT Processors Performance..............................67
Stéphan Mir, Francisco Javier Cazorla Almeida, Alex Ramírez, Mateo Valero
Arquitectura Asimétrica Clusterizada Basada en el Contenido...........................75
Rubén González García, Adrián Cristal, Miquel Pericás, Mateo Valero, Alex
Veidenbaum
KIMP: Multicheckpointing Multiprocessors.......................................................83
Enrique Vallejo Gutiérrez, Marco Galluzzi, Adrián Cristal, Per Stenström,
James E. Smith, Mateo Valero
Diseño y evaluación de una arquitectura de directorio ligero para
multiprocesadores de memoria compartida escalables........................................91
Alberto Ros Bardisa, Manuel Eugenio Acacio Sánchez, José Manuel García
Carrasco
Redes y Comunicación......................................................................................99
Estudio y evaluación del encaminamiento multidestino en arquitecturas
cc-NUMA con directorios comprimidos...........................................................101
Alejandro Orozco López, Manuel Eugenio Acacio Sánchez, José Manuel
García
Simulación de redes de interconexión utilizando tráfico real............................109
Jose Miguel-Alonso, Francisco Javier Ridruejo Pérez
Modelo de AS orientado al desarrollo de mecanismos de gestión....................117
Antonio Robles Gómez, Eva M. García, Aurelio Bermúdez, Rafael Casado,
Francisco J. Quiles
Gaussian Interconnection Networks..................................................................125
Carmen Martínez Fernández, Ramon Beivide, Enrique Vallejo Gutiérrez, Jaime
Gutiérrez, Cruz Izu
viii Contenidos
Hierarchical Topologies for Large-scale Two-level Networks.........................133
Miquel Moretó Planas, Carmen Martínez, Enrique Vallejo Gutiérrez, Ramon
Beivide, Mateo Valero
Segment-Based Routing: Un Nuevo Algoritmo de Encaminamiento Agnóstico a
la Topología.......................................................................................................141
Andrés Mejía, José Flich, José Duato Marín
Dimensionamiento eficiente en mallas mediante una técnica escalable de
eliminación del HOL blocking..........................................................................149
Pedro Javier García García, Francisco J. Quiles, José Flich, José Duato Marín,
Ian Johnson, Finbar Naven
HOL Blocking reduction with a New Cost-Effective Strategy in Multistage
Networks............................................................................................................157
Teresa Nachiondo Farinos, José Flich, José Duato Marín
An Effective Routing Strategy for Direct Interconnection Networks...............165
María Engracia Gómez Requena, Pedro López, José Duato Marín
Reachability-Based Fault-Tolerant Routing Methodology...............................173
Jose Miguel Montañana Aliaga, José Flich, Antonio Robles, José Duato Marín
Reducción del consumo de potencia en redes de interconexión construidas con
conmutadores de alto grado...............................................................................181
Marina Alonso Díaz, Juan Miguel Martínez, Vicente Santonja, Pedro López,
José Duato Marín
MVCM: A Packet Marking/Validation Mechanism for Congestion Management
in InfiniBand......................................................................................................189
Joan-Lluís Ferrer i Pérez, Elvira Baydal, Antonio Robles Gómez, Pedro López,
José Duato Marín
XVI Jornadas de Paralelismo, JP '2005 ix
Efficient collective communication in the Quadrics network...........................197
Salvador Coll Arnau, Francisco J. Mora Más, José Duato Marín
Cluster Computing with QsNetII.......................................................................205
Pablo E. García Palacios, Juan Fernández Peinador, José Manuel García
Carrasco, Fabrizio Petrini
Análisis de la externalización de protocolos mediante simulación HDL..........213
Antonio F. Díaz, Julio Ortega, Alberto Prieto, Andrés Ortiz
Un nuevo algoritmo de CAC para redes multimedia de altas prestaciones.......221
Agustín C. Caminero Herráez, Blanca Caminero Herráez, Carmen Carrión
Espinosa
Transmisión Multicast en Tiempo Real de Vídeo MPEG-4..............................229
José Miguel Dana Pérez, Vicente González Ruiz, Manuel Francisco López
Martínez, Sebastián García Rodríguez, Juan Pablo García Ortiz, Inmaculada
García Fernández
Proporcionar calidad de servicio en Advanced Switching................................235
Raúl Martínez Moráis, Francisco José Alfaro Cortés, José Luis Sánchez García
Calidad de Servicio en Entornos Virtuales Distribuidos...................................243
Juan Manuel Orduña Huertas, Paloma Moreno, Pedro Morillo, José Duato
Marín
Algoritmos Genéticos para proporcionar QoS en Entornos Virtuales
Distribuidos: SEGA...........................................................................................251
Juan Manuel Orduña Huertas, Silvia Rueda, Pedro Morillo, José Duato Marín
x Contenidos
Reducción del Número de Canales Virtuales para Soportar Calidad de Servicio
en Clusters.........................................................................................................259
Alejandro Martínez Vicente, Francisco José Alfaro Cortés, José Luis Sánchez
García, José Duato Marín
Estudio de QoS en WLANs IEEE 802.11e.......................................................267
José Miguel Villalón Millán, Pedro Cuenca Castillo, Luis Orozco-Barbosa
Provisión de QoS en servidores de Internet en el contexto de múltiples
Servidores Virtuales...........................................................................................275
Juan Antonio Villar Ortiz, Francisco José Alfaro Cortés, José Luis Sánchez
García, José Duato Marín
Evaluación de Prestaciones, Modelado y Simulación...................................283
Performance Evaluation of a Bus-Based 16-core Chip-Multiprocessor............285
Francisco Javier Villa Aroca, Manuel Eugenio Acacio Sánchez, José Manuel
García Carrasco
Adaptación de un Simulador de Potencia para Unidades Funcionales en
Procesadores de Alto Rendimiento....................................................................293
Guadalupe Miñana Ropero, Oscar Garnica, J. Ignacio Hidalgo, Juan Lanchares,
J. Manuel Colmenar
Simulating complex systems with a low-detail model......................................301
Ramon Nou Castell, Jordi Guitart, Vicenç Beltran, David Carrera, Lídia
Montero, Jordi Torres
Simulador de referencias a memoria en sistemas caché multinivel a través de
Internet...............................................................................................................309
Miguel Ángel Herrera Díaz, José Manuel Palomares Muñoz, Ezequiel Herruzo
Gómez, José Ignacio Benavides Benítez
XVI Jornadas de Paralelismo, JP '2005 xi
Medición de los contadores hardware del procesador en modo exclusivo........313
Ezequiel Herruzo Gómez, Pedro Navajas Modelo, José Ignacio Benavides
Benítez
Modelado Analítico Automático del Comportamiento de la Caché para Códigos
con Indirecciones...............................................................................................321
Basilio B. Fraguela Rodríguez, Diego Andrade, Ramón Doallo
Cálculo del Peor Caso en la Cache de Datos.....................................................329
Juan Segarra, Luis Carlos Aparicio, José Luis Villarroel, Víctor Viñals
Tecnologías Grid, Clusters y Plataformas Distribuidas...............................337
Entorno Basado en Tecnologías Grid y Servicios Web para Registración de
Imágenes Médicas.............................................................................................339
Ferran Mas Doménech, Ignacio Blanquer Espert, Vicente Hernández García,
Damià Segrelles Quilis
Incremento de prestaciones en el acceso en Grid de datos................................347
José María Pérez Menor, Felix García Carballeira, Jesús Carretero Pérez, José
Daniel García Sánchez, Alejandro Calderón Mateos
Evaluación del Uso Coordinado de Infraestructuras Grid.................................355
José Luis Vázquez Poletti, Antonio Fuentes, Eduardo Huedo, Rubén S.
Montero, Ignacio M. Llorente
Predicción del rendimiento de una aplicación Grid para el control de
inundaciones......................................................................................................363
Julio López Albín, Diego Rodríguez Martínez, Marcos Boullón Magán, José
Carlos Cabaleiro Domínguez, Tomás Fernández Pena, Francisco Fernández
Rivera
xii Contenidos
Comparativa de metaheurísticas utilizando Grid Computing............................371
Jesús Sánchez Allende, Pilar Moreno Díaz, Gabriel Huecas Fernandez-Toribio,
Carlos de la Viesca Santafé, Almudena García Manso
Soporte para el análisis de workloads en el proyecto eNANOS........................379
Iván Rodero Castro, Julita Corbalán, Alejandro Durán, Jesús Labarta
Asignación de réplicas en un Cluster Web basado en replicación parcial de
contenidos..........................................................................................................387
José Daniel García Sánchez, Jesús Carretero Pérez, Félix García, José María
Pérez, María Soledad Escolar
Evaluación de un cluster OpenMosix para entornos de alta productividad y de
alto rendimiento.................................................................................................395
David Hernández Sanz, Rafael Menéndez de Llano Rozas, Pablo Abda Fidalgo
Experiences parallelizing a web server with OpenMP......................................403
Jairo Balart, Alejandro Durán, Marc González, Xavier Martorell, Eduard
Ayguade, Jesús Labarta
OpenMP para clusters........................................................................................411
Francisco de Sande, Antonio J. Dorta, José M. Badía, Enrique S. Quintana
Running BT Multi-Zone on non-shared memory machines with OpenMP SDSM
instead of MPI....................................................................................................419
David Ródenas Picó, Xavier Martorell, Juan José Costa, Toni Cortés, Jesús
Labarta
Workload analysis of networking applications..................................................427
Javier Verdu, Jorge García, Mario Nemirovsky, Mateo Valero
XVI Jornadas de Paralelismo, JP '2005 xiii
Analyzing LoadLeveler historical information for performance prediction.....435
Francesc Guim Bernat, Julita Corbalán, Jesús Labarta
Balanceo de carga en sistemas distribuidos Master - Worker...........................443
Andreu Moreno Vendrell, Eduardo Cesar, Joan Sorribes, Tomàs Margalef,
Emilio Luque
Optimizing Latency under Throughput Requirements for Streaming
Applications.......................................................................................................451
Fernando Guirado Fernández, Ana Ripoll, Concepció Roig, Emilio Luque
Políticas de información para algoritmos de equilibrio de carga......................459
Marta Beltrán Pardo, José Luis Bosque, Antonio Guzmán Sacristán
Exploración Evolutiva del Equilibrado de Carga Dinámico y Distribuido.......467
Mohammed Aldasht, Julio Ortega, Carlos G. Puntonet, Antonio F. Díaz, Juan
Manuel Górriz
Distributed System for Remote Programming of Multiple Network Robots:
System Performance & Parallization Issues......................................................477
Raul Wirz, Raul Marín, Enrique S. Quintana
Algoritmos y Técnicas de Programación Paralela........................................485
Análisis del uso de factorizaciones ILU en la resolución paralela de sistemas no
lineales mediante métodos iterativos de Newton en dos etapas........................487
Héctor F. Migallón Gomis, Josep Arnal García, Violeta Migallón Gomis, José
Penadés Martínez, Vicente Galiano Ibarra
An Approach to Structured Parallel Programming Based on a Composition of
Parallel Objects..................................................................................................495
Mario Rossainz López, Manuel Isidoro Capel Tuñón
xiv Contenidos
Búsquedas A*: un esqueleto paralelo................................................................503
Gara Miranda Valladares, Coromoto León Hernández
Diseño, creación y evaluación de las interfaces de alto nivel para BLACS y
PBLAS de PyACTS...........................................................................................511
Vicente Galiano Ibarra, Héctor F. Migallón Gomis, Violeta Migallón Gomis,
José Penadés Martínez
Comparison between C and C++ implementations of Branch-and-Bound
Skeletons............................................................................................................519
María Isabel Dorta González, Coromoto León Hernández
Esqueletos de alto nivel para la Programación Dinámica.................................527
Francisco Almeida, Ignacio Peláez, Daniel González
Aplicaciones......................................................................................................535
FSVC: Un Nuevo Codificador de Vídeo Escalable...........................................537
Manuel Francisco López Martínez, Vicente González Ruiz, Sebastián García
Rodríguez, José Miguel Dana Pérez, Juan Pablo García Ortiz, Inmaculada
García Fernández
On the use of parallel computing to process multichannel imagery via extended
morphological operations..................................................................................545
Antonio Plaza Miguel, Pablo Martínez, David Valencia, Isabel García, Javier
Plaza
Coprocesador consejero para la compresión de imágenes en sistemas de
observación terrestre..........................................................................................553
Antonio Guzmán Sacristán, Marta Beltrán Pardo
XVI Jornadas de Paralelismo, JP '2005 xv
Multiprocessing of Anisotropic Nonlinear Diffusion for filtering 3D images..561
Siham Tabik, Ester Martín Garzón, Inmaculada García Fernández, Jose Jesus
Fernández Rodriguez
Implementación de dos algoritmos paralelos para la detección automática del
Plano Sagital Medio en Imágenes de Resonancia Magnética...........................569
Ivan Lausuch Sales, Mª Carmen Juan, Antonio Vidal
Procesamiento de imágenes según LogGP: un estudio analítico.......................577
Pere Millán Marco, Eduard Montseny
Evaluación de Clusters aplicados a imagen médica..........................................585
Juan Díaz García, Pedro Prieto Gómez, Manuel Peña Taveras, Rafael Ávila
Bermúdez, Víctor Potenciano Enciso
Paralelización del codificador H.264 con estimación de movimiento adaptativa
en clusters de PCs..............................................................................................591
Alberto González Téllez, Abelardo Rodriguez León, Manuel Pérez Malumbres,
Jesus Peinado Pinilla, Juan Carlos Fernández Fernández
Paralelización de técnicas de compensación local de movimiento mediante
OpenMP.............................................................................................................599
José Manuel Palomares Muñoz, Daniel Sánchez Salido, Joaquín Olivares
Bueno, Edmundo Sáez Peña
El Problema del Código Corrector de Errores: paralelización de algoritmos
exactos con OpenMP y MPI..............................................................................607
Jorge Rodríguez Pedrianes, Sandra Martín Ruiz, Gara Miranda Valladares,
Coromoto León Hernández, Casiano Rodríguez León
xvi Contenidos
Paralelización del cálculo de volcanes para usos criptográficos.......................615
Santi Martínez Rodríguez, Rosana Tomàs, Concepció Roig, Magda Valls,
Francesc Giné
S2F2M - Sistema Estadístico para la Predicción de Incendios Forestales........623
German Bianchini, Ana Cortés, Tomàs Margalef, Emilio Luque
A study of real-time compliance and parallelization for the purpose of surface
grading...............................................................................................................631
Fernando López García, José Miguel Valiente González, Gabriela Andreu
García
Parallel implementation of CTC algorithm for a customer fidelisation
problem..............................................................................................................639
José Ignacio Martín, Jesús Mª Pérez, Javier Muguerza, Olatz Arbelaitz, Ibai
Gurrutxaga
Paralelización de un algoritmo de búsqueda de localizaciones bajo competencia
espacial en precios.............................................................................................647
Juana López Redondo, Pilar Martínez Ortigosa, Inmaculada García Fernández,
Blas Pelegrín, Pascual Fernández
Balanceo de Carga y Minimización de Comunicaciones en Redes...................655
Raul Baños Navarro, Consolación Gil, Julio Gómez, Julio Ortega
Paralelismo y Computación Evolutiva en Optimización Multiobjetivo.
Aplicaciones en Arquitectura de Computadores...............................................663
Francisco J. de Toro, Julio Ortega, Eduardo Ros, Sonia Mota
Distributed Simulation of Ecologic Systems.....................................................671
Diego Mostaccio, Remo Suppi, Emilio Luque
XVI Jornadas de Paralelismo, JP '2005 xvii
Algoritmos evolutivos en Java: resolución del TSP usando DREAM..............677
Juan Luis Jiménez Laredo, Víctor Martín Molina, Juan Julián Merelo Guervós,
Maribel García Arenas
Optimizaciones de entrada/salida para aplicaciones de dinámica molecular....685
David Expósito Singh, María Blanca Ibáñez, Florin Isaila, Félix García, Jesús
Carretero
Docencia en Arquitectura y Tecnología de Computadores.........................693
Gestión de la interconexión de una red de múltiples tecnologías: planteamiento
práctico en el laboratorio...................................................................................695
Nuria Rodríguez, Xabier Subijana, Nuria Cañamares, Enrique Reina, Paul
Bustamante
Una aproximación a la ejecución en cadena de instrucciones...........................703
Carlos Rioja del Río, José María Rodríguez Corral, Antón Civit Balcells
Simulador de Máquina Sencilla.........................................................................713
Juan Antonio Ortega Lalmolda, Natalia Ayuso Escuer, Luis M. Ramos
Martínez
Las asignaturas de sistemas operativos en Ingeniería Electrónica de la
ETSETB-UPC: un mismo curso en modalidad semipresencial, presencial y por
proyectos............................................................................................................717
Pau Bofill Soliguer, Montse Farreras, Maribel March, Enric Morancho
Segmentación de Cauce del Computador Didáctico Elemental CODE-2.........725
Juan I. López Martínez, Javier Díaz Alonso, Francisco J. Pelayo, Alberto
Prieto, Julio Ortega
xviii Contenidos
Entorno web para la generación y correción automatizada de exámenes basado
en XML y Java...................................................................................................733
Alberto González Téllez, Miguel Angel Carcelen
Enseñando Paralelismo con una consola PlayStation2......................................741
Jesús González Peñalver, David Rubio, Raúl Tovar
XVI Jornadas de Paralelismo, JP '2005 xix
Arquitectura del Procesador
y Multiprocesadores

        
 
    
    
                     !  "    #    $ %     &     
' ( ) * + , * - ( . , / 0
1
+ 2 3 4 , ( 5 , 3 + * / ( 6 7 - ) 3 , * / 7 + 8
9 . 4 : ( + 8 4 , * , ; 7 < 4 , = 5 . 4 5 * / ( 6 * , * < 3 . > *
? * + 5 ( < 7 . * @ A ) * 4 .
B C D E F G E F E H E I E J K I L M H J E G L C N O
* 5 P 3 ) 5 P ( / 3
Q R S T U V W T
X Y Z [ Z \ ] ^ ] _ Z ` a b _ Z c d e ] f _ d ^ ` [ ` e e g _ ` ] Z
h
_ ` [ e Y b _ Z c d e ] f _ ] Y ` ] b _ f i d c Z ^ ^ ] _ Z ` a j Z i Z j
^ Z k g Z [ e d [ l m n i Z _ o b _ Z c d e ] d f [ e f [ ] ` d [ ^ ` p g j j
^ ] _ Z ` a f p d [ ^ ] _ g e ] d f [ ^ q ] Y ` ] d ^ q ` ^ Z k g Z [ e Z f p
d [ ^ ] _ g e ] d f [ ^ p _ f a ] Y Z ] ` _ l Z ] f p ` ] ` r Z [
h
_ ` [ e Y
] f ] Y Z [ Z \ ] ] ` r Z [
h
_ ` [ e Y q b f ] Z [ ] d ` j j o e f [ s
] ` d [ d [ l a g j ] d b j Z
h
` ^ d e
h
j f e r ^ m t [ ] Y d ^ b ` b Z _ q
u
Z b _ f b f ^ Z ] Y Z a g j ] d b j Z ^ ] _ Z ` a b _ Z c d e ] f _ q `
[ f i Z j a Z e Y ` [ d ^ a ] Y ` ] b _ Z c d e ] ^ ]
u
f ^ ] _ Z ` a ^
` ] ` ] d a Z m v Z ^ Y f
u
] Y ` ] f g _ b _ Z c d e ] f _ b _ f s
i d c Z ^ Z [ f g l Y d [ ^ ] _ g e ] d f [ ^ ] f ] f j Z _ ` ] Z ] Y Z b _ Z s
c d e ] d f [ ] `
h
j Z ` e e Z ^ ^ j ` ] Z [ e o
u
d ] Y f g ] _ Z k g d _ d [ l
] Y Z e f a b j Z \ d ] o e ` g ^ Z c
h
o ` c c d ] d f [ ` j Y ` _ c
u
` _ Z
a Z e Y ` [ d ^ a ^ j d r Z b _ Z c d e ] d f [ f i Z _ _ d c d [ l m
w x y
T U z { | W T } z
y
~ d l Y b Z _ p f _ a ` [ e Z ^ g b Z _ ^ e ` j ` _ b _ f e Z ^ ^ f _ ^ _ Z s
k g d _ Z Y d l Y p Z ] e Y
h
` [ c
u
d c ] Y ] f Z \ b j f d ] ` j j ] Y Z
` i ` d j `
h
j Z d [ ^ ] _ g e ] d f [ s j Z i Z j b ` _ ` j j Z j d ^ a m X Y Z
c Z i Z j f b a Z [ ] f p ` e e g _ ` ] Z
h
_ ` [ e Y b _ Z c d e ] d f [
a Z e Y ` [ d ^ a ^ Y ` ^ b _ f i d c Z c d a b f _ ] ` [ ] d a b _ f i Z s
a Z [ ] ^ d [ ] Y Z p Z ] e Y Z [ l d [ Z b Z _ p f _ a ` [ e Z m ~ f
u
s
Z i Z _ q d ] Y ` ^ ` j ^ f d [ e _ Z ` ^ Z c ] Y Z p Z ] e Y ` _ e Y d ] Z e s
] g _ Z e f a b j Z \ d ] o m  g _ ` b b _ f ` e Y ] f ` e Y d Z i Z Y d l Y
p Z ] e Y
h
` [ c
u
d c ] Y q
u
Y d j Z a ` d [ ] ` d [ d [ l ] Y Z e f a s
b j Z \ d ] o g [ c Z _ e f [ ] _ f j q d ^ ] Y Z ^ ] _ Z ` a p Z ] e Y Z [ s
l d [ Z €  q ‚ ƒ m
X Y d ^ p Z ] e Y Z [ l d [ Z c Z ^ d l [ d ^
h
` ^ Z c f [ ] Y Z [ Z \ ]
^ ] _ Z ` a b _ Z c d e ] f _ q ` [ ` e e g _ ` ] Z
h
_ ` [ e Y b _ Z c d e s
] d f [ a Z e Y ` [ d ^ a ] Y ` ] g ^ Z ^ d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^
` ^ ] Y Z
h
` ^ d e b _ Z c d e ] d f [ g [ d ] m v Z e ` j j ^ ] _ Z ` a ] f
` ^ Z k g Z [ e Z f p d [ ^ ] _ g e ] d f [ ^ p _ f a ] Y Z ] ` _ l Z ] f p `
] ` r Z [
h
_ ` [ e Y ] f ] Y Z [ Z \ ] ] ` r Z [
h
_ ` [ e Y q b f ] Z [ s
Control Flow Code Layout
A
B C
D
A
C
B
D
Possible Streams
A
B
D
A C D
Not a Stream
B
D
A
B
„ 4 … 3 + ( † ‡ ˆ ‰ * - ) < ( 7 Š 4 . 8 , + 3 5 , 4 7 . 8 , + ( * - 8 P
] d ` j j o e f [ ] ` d [ d [ l a g j ] d b j Z
h
` ^ d e
h
j f e r ^ m ‹ d l g _ Z
Œ
^ Y f
u
^ ` [ Z \ ` a b j Z e f [ ] _ f j  f
u
l _ ` b Y p _ f a
u
Y d e Y
u
Z
u
d j j Ž [ c ] Y Z b f ^ ^ d
h
j Z ^ ] _ Z ` a ^ m X Y Z
Ž l g _ Z ^ Y f
u
^ ` j f f b e f [ ] ` d [ d [ l ` [ d p s ] Y Z [ s Z j ^ Z
^ ] _ g e ] g _ Z m  Z ] g ^ ^ g b b f ^ Z ] Y ` ] f g _ b _ f Ž j Z c ` ] `
^ Y f
u
^ ] Y ` ]
A → B → D
d ^ ] Y Z a f ^ ] p _ Z k g Z [ ] j o
p f j j f
u
Z c b ` ] Y ] Y _ f g l Y ] Y Z j f f b m  ^ d [ l ] Y d ^
d [ p f _ a ` ] d f [ q
u
Z j ` o f g ] ] Y Z e f c Z ^ f ] Y ` ] ] Y Z
b ` ] Y
A → B
l f Z ^ ] Y _ f g l Y ` [ f ] s ] ` r Z [
h
_ ` [ e Y q
` [ c p ` j j ^ s ] Y _ f g l Y p _ f a
B → D
m ‘ ` ^ d e
h
j f e r
C
d ^ a ` b b Z c ^ f a Z
u
Y Z _ Z Z j ^ Z q ` [ c e ` [ f [ j o
h
Z
_ Z ` e Y Z c ] Y _ f g l Y ` ] ` r Z [
h
_ ` [ e Y ` ] ] Y Z Z [ c f p
h
` ^ d e
h
j f e r
A
m
‹ _ f a ] Y Z _ Z ^ g j ] d [ l e f c Z j ` o f g ]
u
Z a ` o Z [ s
e f g [ ] Z _ p f g _ b f ^ ^ d
h
j Z ^ ] _ Z ` a ^ e f a b f ^ Z c
h
o
h
` s
^ d e
h
j f e r ^
ABD
q
A
q
C
q ` [ c
D
m X Y Z Ž _ ^ ] ^ ] _ Z ` a
e f _ _ Z ^ b f [ c ^ ] f ] Y Z ^ Z k g Z [ ] d ` j b ` ] Y ^ ] ` _ ] d [ l ` ]
h
` ^ d e
h
j f e r
A
` [ c l f d [ l ] Y _ f g l Y ] Y Z p _ Z k g Z [ ]
b ` ] Y p f g [ c
h
o f g _ b _ f Ž j Z m ‘ ` ^ d e
h
j f e r
A
d ^ ] Y Z
] ` _ l Z ] f p ` ] ` r Z [
h
_ ` [ e Y q ` [ c ] Y Z [ Z \ ] ] ` r Z [
h
_ ` [ e Y d ^ p f g [ c ` ] ] Y Z Z [ c f p
h
` ^ d e
h
j f e r
D
m
’ Z d ] Y Z _ ] Y Z ^ Z k g Z [ e Z
AB
q [ f _ ] Y Z ^ Z k g Z [ e Z
BD
e ` [
h
Z e f [ ^ d c Z _ Z c ^ ] _ Z ` a ^
h
Z e ` g ^ Z ] Y Z
Ž _ ^ ] f [ Z c f Z ^ [ f ] Z [ c d [ ` ] ` r Z [
h
_ ` [ e Y q ` [ c
] Y Z ^ Z e f [ c f [ Z c f Z ^ [ f ] ^ ] ` _ ] d [ ] Y Z ] ` _ l Z ] f p `
] ` r Z [
h
_ ` [ e Y m X Y Z d [ p _ Z k g Z [ ] e ` ^ Z p f j j f
u
^ ] Y Z
] ` r Z [
h
_ ` [ e Y ` ] ] Y Z Z [ c f p
A
q l f Z ^ ] Y _ f g l Y
C
q
` [ c “ g a b ^
h
` e r d [ ] f
h
` ^ d e
h
j f e r
D
m
”
j ] Y f g l Y ` p Z ] e Y Z [ l d [ Z
h
` ^ Z c f [ ^ ] _ Z ` a ^ d ^
[ f ] `
h
j Z ] f p Z ] e Y d [ ^ ] _ g e ] d f [ ^
h
Z o f [ c ` ] ` r Z [
h
_ ` [ e Y d [ ` ^ d [ l j Z e o e j Z q ^ ] _ Z ` a ^ ` _ Z j f [ l
Z [ f g l Y ] f b _ f i d c Z Y d l Y p Z ] e Y
h
` [ c
u
d c ] Y m t [
` c c d ] d f [ q ^ d [ e Z ^ ] _ Z ` a ^ ` _ Z ^ Z k g Z [ ] d ` j j o ^ ] f _ Z c
d [ ] Y Z d [ ^ ] _ g e ] d f [ e ` e Y Z q ] Y Z ^ ] _ Z ` a p Z ] e Y Z [ s
l d [ Z c f Z ^ [ f ] [ Z Z c ` ^ b Z e d ` j s b g _ b f ^ Z ^ ] f _ ` l Z q
[ f _ ` e f a b j Z \ c o [ ` a d e
h
g d j c d [ l Z [ l d [ Z m ~ f
u
s
Z i Z _ q ] ` r d [ l d [ ] f ` e e f g [ ] e g _ _ Z [ ] ] Z e Y [ f j f l o
] _ Z [ c ^ q ` e e g _ ` ] Z
h
_ ` [ e Y b _ Z c d e ] d f [ ` [ c Y d l Y
p Z ] e Y
h
` [ c
u
d c ] Y d ^ [ f ] Z [ f g l Y m X Y Z e f [ ] d [ s
g f g ^ d [ e _ Z ` ^ Z d [ b _ f e Z ^ ^ f _ e j f e r p _ Z k g Z [ e o q ` ^
u
Z j j ` ^ ] Y Z j ` _ l Z _
u
d _ Z c Z j ` o ^ e ` g ^ Z c
h
o a f c s
Z _ [ ] Z e Y [ f j f l d Z ^ q b _ Z i Z [ ]
h
_ ` [ e Y b _ Z c d e ] d f [ ] ` s
h
j Z ^ p _ f a
h
Z d [ l ` e e Z ^ ^ Z c d [ ` ^ d [ l j Z e o e j Z €
Œ
q • ƒ m
X Y d ^ p ` e ] j d a d ] ^ p Z ] e Y Z [ l d [ Z b Z _ p f _ a ` [ e Z
h
Z s
e ` g ^ Z Z ` e Y
h
_ ` [ e Y b _ Z c d e ] d f [ c Z b Z [ c ^ f [ ] Y Z
b _ Z i d f g ^ f [ Z q ] Y ` ] d ^ q ] Y Z ] ` _ l Z ] ` c c _ Z ^ ^ f p `
h
_ ` [ e Y b _ Z c d e ] d f [ d ^ ] Y Z ^ ] ` _ ] d [ l ` c c _ Z ^ ^ f p ] Y Z
p f j j f
u
d [ l f [ Z m
”
e f a a f [ ^ f j g ] d f [ p f _ ] Y d ^ b _ f
h
j Z a d ^ ] Y Z
b _ Z c d e ] d f [ f i Z _ _ d c d [ l ] Z e Y [ d k g Z € • q
Œ Œ
ƒ m
”
^ a ` j j ` [ c p ` ^ ] b _ Z c d e ] f _ d ^ g ^ Z c ] f f
h
] ` d [ `
Ž _ ^ ] b _ Z c d e ] d f [ d [ ` ^ d [ l j Z e o e j Z m
”
^ j f
u
Z _
h
g ] a f _ Z ` e e g _ ` ] Z b _ Z c d e ] f _ b _ f i d c Z ^ ` [ Z
u
b _ Z c d e ] d f [ ^ f a Z e o e j Z ^ j ` ] Z _ q f i Z _ _ d c d [ l ] Y Z
Ž _ ^ ] b _ Z c d e ] d f [ d p ] Y Z o c d – Z _ m X Y d ^ a Z e Y ` [ d ^ a
b ` _ ] d ` j j o Y d c Z ^ ] Y Z
h
_ ` [ e Y b _ Z c d e ] f _ ` e e Z ^ ^ j ` s
] Z [ e o m ~ f
u
Z i Z _ q d ] ` j ^ f e ` g ^ Z ^ ` [ d [ e _ Z ` ^ Z d [
] Y Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z e f a b j Z \ d ] o q ^ d [ e Z b _ Z s
c d e ] d f [ f i Z _ _ d c d [ l _ Z k g d _ Z ^ ` e f a b j Z \ _ Z e f i Z _ o
a Z e Y ` [ d ^ a ] f c d ^ e ` _ c ] Y Z
u
_ f [ l ^ b Z e g j ` ] d i Z
u
f _ r
h
` ^ Z c f [ f i Z _ _ d c c Z [ b _ Z c d e ] d f [ ^ m
”
[ ` j ] Z _ [ ` ] d i Z ] f ] Y Z f i Z _ _ d c d [ l a Z e Y ` [ d ^ a
d ^ g ^ d [ l j f [ l
h
` ^ d e b _ Z c d e ] d f [ g [ d ] ^ m
”
^ ] _ Z ` a
b _ Z c d e ] d f [ e f [ ] ` d [ ^ Z [ f g l Y d [ ^ ] _ g e ] d f [ ^ ] f p Z Z c
] Y Z Z \ Z e g ] d f [ Z [ l d [ Z c g _ d [ l a g j ] d b j Z e o e j Z ^ € ‚ ƒ m
X Y Z _ Z p f _ Z q ] Y Z j f [ l Z _ ` ^ ] _ Z ` a d ^ q ] Y Z a f _ Z e o s
e j Z ^ ] Y Z Z \ Z e g ] d f [ Z [ l d [ Z
u
d j j
h
Z
h
g ^ o
u
d ] Y f g ]
_ Z k g d _ d [ l ` [ Z
u
b _ Z c d e ] d f [ m t p ^ ] _ Z ` a ^ ` _ Z j f [ l
Z [ f g l Y q ] Y Z Z \ Z e g ] d f [ Z [ l d [ Z f p ] Y Z b _ f e Z ^ ^ f _
e ` [
h
Z r Z b ]
h
g ^ o c g _ d [ l a g j ] d b j Z e o e j Z ^
u
Y d j Z
` [ Z
u
b _ Z c d e ] d f [ d ^
h
Z d [ l l Z [ Z _ ` ] Z c m  i Z _ s
j ` b b d [ l ] Y Z Z \ Z e g ] d f [ f p ` b _ Z c d e ] d f [
u
d ] Y ] Y Z
l Z [ Z _ ` ] d f [ f p ] Y Z p f j j f
u
d [ l b _ Z c d e ] d f [ ` j j f
u
^ ] f
b ` _ ] d ` j j o Y d c Z ]
Y Z ` e e Z ^ ^ c Z j ` o f p ] Y d ^ ^ Z e f [ c
b _ Z c d e ] d f [ q _ Z a f i d [ l ] Y Z [ Z Z c p f _ ` [ f i Z _ _ d c s
d [ l a Z e Y ` [ d ^ a q ` [ c ] Y g ^ _ Z c g e d [ l ] Y Z p Z ] e Y
Z [ l d [ Z e f a b j Z \ d ] o m
—
d [ e Z d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^ ` _ Z j d a d ] Z c
h
o
] ` r Z [
h
_ ` [ e Y Z ^ q ` l f f c
u
` o ] f f
h
] ` d [ j f [ l Z _
^ ] _ Z ` a ^ d ^ _ Z a f i d [ l ] ` r Z [
h
_ ` [ e Y Z ^ ] Y _ f g l Y
e f c Z f b ] d a d ˜ ` ] d f [ ^ m ™ f c Z j ` o f g ] f b ] d a d ˜ ` s
] d f [ ^ Y ` i Z `
h
Z [ Z Ž e d ` j Z – Z e ] f [ ] Y Z j Z [ l ] Y
f p d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^ € ‚ ƒ m X Y Z ^ Z f b ] d a d ˜ ` s
] d f [ ^ ] _ o ] f a ` b ] f l Z ] Y Z _ ] Y f ^ Z
h
` ^ d e
h
j f e r ^
] Y ` ] ` _ Z p _ Z k g Z [ ] j o Z \ Z e g ] Z c ` ^ ` ^ Z k g Z [ e Z m
X Y Z _ Z p f _ Z q a f ^ ] e f [ c d ] d f [ ` j
h
_ ` [ e Y Z ^ d [ f b ] d s
a d ˜ Z c e f c Z ` _ Z [ f ] ] ` r Z [ q Z [ j ` _ l d [ l d [ ^ ] _ g e s
] d f [ ^ ] _ Z ` a ^ m ~ f
u
Z i Z _ q e f c Z j ` o f g ] f b ] d a d ˜ ` s
] d f [ ^ ` _ Z [ f ] Z [ f g l Y p f _ ] Y Z ^ ] _ Z ` a p Z ] e Y Z [ s
l d [ Z ] f e f a b j Z ] Z j o f i Z _ e f a Z ] Y Z [ Z Z c p f _ ` [
f i Z _ _ d c d [ l a Z e Y ` [ d ^ a €
Œ š
ƒ m t [ f _ c Z _ ] f f i Z _ s
e f a Z ] Y d ^ b _ f
h
j Z a q
u
Z b _ Z ^ Z [ ] ] Y Z a g j ] d b j Z
^ ] _ Z ` a b _ Z c d e ] f _ q ` [ f i Z j b _ Z c d e ] f _ ] Y ` ] e f [ s
e ` ] Z [ ` ] Z ^ ] Y f ^ Z ^ ] _ Z ` a ^ ] Y ` ] ` _ Z p _ Z k g Z [ ] j o
Z \ Z e g ] Z c ` ^ ` ^ Z k g Z [ e Z m X Y d ^ [ f i Z j b _ Z c d e s
] f _ c Z ^ d l [ d ^ `
h
j Z ] f b _ f i d c Z Z [ f g l Y d [ ^ ] _ g e s
] d f [ ^ ] f ` e Y d Z i Z ` b Z _ p f _ a ` [ e Z ^ d a d j ` _ ] f b _ Z s
c d e ] d f [ f i Z _ _ d c d [ l ` ] ` a g e Y j f
u
Z _ d a b j Z a Z [ s
] ` ] d f [ e f ^ ] ` [ c e f a b j Z \ d ] o m
› œ  ž Ÿ
U }  
Ÿ y
T V ¡ ¢
Ÿ
T £ z { z ¡ z ¤ ¥
X Y Z _ Z ^ g j ] ^ d [ ] Y d ^ b ` b Z _ Y ` i Z
h
Z Z [ f
h
] ` d [ Z c
g ^ d [ l ] _ ` e Z c _ d i Z [ ^ d a g j ` ] d f [ f p ` ^ g b Z _ ^ e ` j ` _
b _ f e Z ^ ^ f _ m  g _ ^ d a g j ` ] f _ g ^ Z ^ ` ^ ] ` ] d e
h
` ^ d e
h
j f e r c d e ] d f [ ` _ o ] f ` j j f
u
^ d a g j ` ] d [ l ] Y Z Z – Z e ]
f p
u
_ f [ l b ` ] Y Z \ Z e g ] d f [ m X Y d ^ a f c Z j d [ e j g c Z ^
] Y Z ^ d a g j ` ] d f [ f p
u
_ f [ l ^ b Z e g j ` ] d i Z b _ Z c d e ] f _
Y d ^ ] f _ o g b c ` ] Z ^ q ` ^
u
Z j j ` ^ ] Y Z b f ^ ^ d
h
j Z d [ ] Z _ s
p Z _ Z [ e Z ` [ c b _ Z p Z ] e Y d [ l Z – Z e ] ^ f [ ] Y Z d [ ^ ] _ g e s
] d f [ e ` e Y Z m v Z p Z Z c f g _ ^ d a g j ` ] f _
u
d ] Y ] _ ` e Z ^
f p •
š š
a d j j d f [ d [ ^ ] _ g e ] d f [ ^ e f j j Z e ] Z c p _ f a ] Y Z
— ¦
n ™ §
š š š
d [ ] Z l Z _
h
Z [ e Y a ` _ r ^ ¨ g ^ d [ l ] Y Z © ª
« ¬
ª © ª ­ ® ª d [ b g ] ^ Z ] m X f Ž [ c ] Y Z a f ^ ] _ Z b _ Z s
^ Z [ ] ` ] d i Z Z \ Z e g ] d f [ ^ Z l a Z [ ]
u
Z Y ` i Z ` [ ` j o ˜ Z c
] Y Z c d ^ ] _ d
h
g ] d f [ f p
h
` ^ d e
h
j f e r ^ ` ^ c Z ^ e _ d
h
Z c
d [ €
Œ
§ ƒ m
¯ ° ± ± ² ³ ´ µ ¶ ± ¶ · ¸ · ¹ º »
¼ ½
± ³ ¾ µ ¿ ± À Á ¿ Â ± Ã Ä Å Ã Æ ¾ Ç ³ ± À ¿
È
± Ã É ´ À Æ À Á ± ¶
½
É ¶ ¾ Á ¾ ³ ¾ ³ Ê ± Æ À ¿ ¿ ± ¿ Ë
½
± À Ç Ì À Ç ¿ ± Ç ¿ À Á À
È
±
Á Å ³ Ê ¾ Ç Ì ± ¿ À Ç Á Ê ± Ä ± Á ³ Ê ¾ Ã ³ Ê À Á ± ³ Á µ Ã ± Í
4 Arquitectura del Procesador y Multiprocesadores
¼ Î Ï
» Ð Ñ Ò
Î Ó Ô
º
Î
Ñ
Ô Ó Õ
» Ö º º ×
Ï Ø
×
Õ Ï
Ð Ù À Ç ¿ Á Ã µ ³ Á À Å Ç ¿
×
Ó Ï Î
Ú
Î
Ò
Ô Ó Õ Û
Ö
Ô Ï
×
Ó
Ú Ü
Ö ×
Ó Ï
× Ý Ý Þ
Î Ø
×
Õ Ï
Ð Ù À Ç ¿ Á Ã µ ³ Á À Å Ç ¿
ß
Ö
Ô Õ
à
Ý
Ï
Ö Ò
Î
× Ý Ý Þ
Î Ø
×
Õ Ï
Ð á À Ç ¿ Á Ã µ ³ Á À Å Ç ¿
¼ Î Ï
» Ð
Ï Ô
Ò
Ú
Î Ï â
Þ
Î
Þ
Î
Ù ± Ç Á Ã À ± ¿
×
Ó
Ý
Ï
Ò Þ »
Ï
× Ö
Ó ¼ Î Ï
» Ð
â
Þ
Î
Þ
Î ã ä
± Ç Á Ã À ± ¿
×
Ó Ï Î
Ú
Î
Ò Ñ
Û
Ö
Ô Ï
×
Ó
Ú Ü
Ö ×
Ó Ï
Ñ
Ô Ó Õ
ß
Ö
Ô Õ
à
Ý
Ï
Ö Ò
Î
× Ý Ý Þ
Î â
Þ
Î
Þ
Î
Ý å á ± Ç Á Ã À ± ¿
Ò
Î
Ö Ò
Õ Î
Ò æ Þ ç
Î
Ò
ä è
å ± Ç Á Ã À ± ¿
×
Ó Ï Î
Ú
Î
Ò
Ô Ó Õ Û
Ö
Ô Ï
×
Ó
Ú Ü
Ö ×
Ó Ï
Ò
Î
Ú
× Ý
Ï Î
Ò Ý é å ê
ë
· ×
Ó
Ý
Ï
Ò Þ »
Ï
× Ö
Ó
»
Ô
» Ð
Î
å á ì
ã ä í î
Ë
ä ï ð
¾ É ¾ ¿ ¿ Å ³ À ¾ Á À
È
± Ë é
ä
Ù
½
É Á ±
½
´ Å ³ ñ Ë
ã
³ É ³ ´ ± ´ ¾ Á ± Ç ³ É
ë
·
Õ Ô Ï Ô
»
Ô
» Ð
Î
å á
í î
Ë
ä ï ð
¾ É ¾ ¿ ¿ Å ³ À ¾ Á À
È
± Ë å á
½
É Á ±
½
´ Å ³ ñ Ë
ã
³ É ³ ´ ± ´ ¾ Á ± Ç ³ É
ë ò
Þ
Ó
×
ó Î Õ
»
Ô
» Ð
Î
é ô
î
Ë á
ï ð
¾ É ¾ ¿ ¿ Å ³ À ¾ Á À
È
± Ë é
ä
Ù
½
É Á ±
½
´ Å ³ ñ Ë é å ³ É ³ ´ ± ´ ¾ Á ± Ç ³ É
º
Ô
×
Ó
º
Î
º Ö Ò õ
ß
Ô Ï Î Ó
» õ
ã è
ê ³ É ³ ´ ± ¿
º
Ô ö
× º Þ º
Ï
Ò
Ô
»
Î
Ý × ÷
Î ã ä
À Ç ¿ Á Ã µ ³ Á À Å Ç ¿ ø é ê
½
à ¾ Ç ³ Ê ± ¿ ù
ó
ß
Ï Î
Ò
Ô Ó Õ
º
Ô
×
Ó Ï
Ò
Ô
»
Î
»
Ô
» Ð
Î
Ý é
ä
Ù Á Ã ¾ ³ ± ¿ Ë á
ï ð
¾ É ¾ ¿ ¿ Å ³ À ¾ Á À
È
±
X `
h
j Z
Œ ú
™ f [ Ž l g _ ` ] d f [ f p ] Y Z ^ d a g j ` ] Z c b _ f e Z ^ ^ f _
—
d [ e Z b _ Z i d f g ^
u
f _ r € ‚ ƒ Y ` ^ ^ Y f
u
[ ] Y ` ] e f c Z
j ` o f g ] f b ] d a d ˜ ` ] d f [ ^ ` _ Z `
h
j Z ] f Z [ j ` _ l Z d [ s
^ ] _ g e ] d f [ ^ ] _ Z ` a ^ q
u
Z b _ Z ^ Z [ ] c ` ] ` p f _
h
f ] Y
`
h
` ^ Z j d [ Z ` [ c ` [ f b ] d a d ˜ Z c e f c Z j ` o f g ] m X Y Z
h
` ^ Z j d [ Z e f c Z j ` o f g ]
u
` ^ l Z [ Z _ ` ] Z c g ^ d [ l ] Y Z
™ f a b ` k ™ û  m ü s
š Œ
 e f a b d j Z _ f [ ™ f a b ` k
 ’ t ý û þ m
š
m X Y Z f b ] d a d ˜ Z c e f c Z j ` o f g ]
u
` ^
l Z [ Z _ ` ] Z c
u
d ] Y ] Y Z
—
b d r Z ] f f j ^ Y d b b Z c
u
d ] Y
™ f a b ` k X _ g ÿ þ  [ d \  m
Œ
m  b ] d a d ˜ Z c e f c Z l Z [ s
Z _ ` ] d f [ d ^
h
` ^ Z c f [ b _ f Ž j Z d [ p f _ a ` ] d f [ e f j s
j Z e ] Z c
h
o ] Y Z
¦
d \ d Z û  m § ] f f j g ^ d [ l ] Y Z ©
 ­
d [ b g ] ^ Z ] m
     
      
 g _ ^ d a g j ` ] d f [ ^ Z ] g b e f _ _ Z ^ b f [ c ^ ] f ` [ ` l s
l _ Z ^ ^ d i Z ü s
u
d c Z ^ g b Z _ ^ e ` j ` _ b _ f e Z ^ ^ f _ m X Y Z
a ` d [ i ` j g Z ^ f p ] Y d ^ ^ Z ] g b ` _ Z ^ Y f
u
[ d [ X ` s
h
j Z
Œ
m v Z e f a b ` _ Z f g _ ^ ] _ Z ` a p Z ] e Y ` _ e Y d s
] Z e ] g _ Z
u
d ] Y ] Y _ Z Z f ] Y Z _ ^ ] ` ] Z s f p s ] Y Z s ` _ ] p Z ] e Y
` _ e Y d ] Z e ] g _ Z ^
ú
` p Z ] e Y ` _ e Y d ] Z e ] g _ Z g ^ d [ l ` [ d [ s
] Z _ j Z ` i Z c ‘ X ‘  d ‘ X ‘  ` [ c ` §
h
e l ^ r Z
u
b _ Z s
c d e ] f _ €
Œ Œ
ƒ q ] Y Z p Z ] e Y ] ` _ l Z ]
h
g – Z _  ‹ X ‘  ` _ s
e Y d ] Z e ] g _ Z € ÿ ƒ g ^ d [ l ` b Z _ e Z b ] _ f [ b _ Z c d e ] f _ € þ ƒ q
` [ c ] Y Z ] _ ` e Z e ` e Y Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z g ^ d [ l `
] _ ` e Z b _ Z c d e ] f _ € § ƒ m
”
j j ] Y Z ^ Z ` _ e Y d ] Z e ] g _ Z ^ g ^ Z
` [ ü s Z [ ] _ o p Z ] e Y ] ` _ l Z ] k g Z g Z  ‹ X   € ÿ ƒ ] f c Z s
e f g b j Z
h
_ ` [ e Y b _ Z c d e ] d f [ p _ f a ] Y Z d [ ^ ] _ g e ] d f [
e ` e Y Z ` e e Z ^ ^ m
 g _ d [ ^ ] _ g e ] d f [ e ` e Y Z ^ Z ] g b g ^ Z ^
u
d c Z e ` e Y Z
j d [ Z ^ q ] Y ` ] d ^ q þ ] d a Z ^ ] Y Z b _ f e Z ^ ^ f _ p Z ] e Y
u
d c ] Y €  ƒ q ` [ c ÿ þ  ‘ ] f ] ` j Y ` _ c
u
` _ Z
h
g c l Z ] m
X Y Z ] _ ` e Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z d ^ ` e ] g ` j j o Z i ` j s
g ` ] Z c g ^ d [ l ` • §  ‘ d [ ^ ] _ g e ] d f [ e ` e Y Z q
u
Y d j Z
] Y Z _ Z a ` d [ c Z _ • §  ‘ ` _ Z c Z i f ] Z c ] f ] Y Z ] _ ` e Z
e ` e Y Z m X Y d ^ Y ` _ c
u
` _ Z
h
g c l Z ] d ^ Z k g ` j j o c d s
i d c Z c d [ ] f ` Ž j ] Z _ ] _ ` e Z e ` e Y Z €  ƒ ` [ c ` a ` d [
] _ ` e Z e ` e Y Z m
          

X Y Z ^ ] _ Z ` a p Z ] e Y Z [ l d [ Z €  q ‚ ƒ a f c Z j d ^ ^ Y f
u
[
d [ ‹ d l g _ Z § m ` m X Y Z ^ ] _ Z ` a b _ Z c d e ] f _ ` e e Z ^ ^ d ^
c Z e f g b j Z c p _ f a ] Y Z d [ ^ ] _ g e ] d f [ e ` e Y Z ` e e Z ^ ^
g ^ d [ l ` [ ‹ X  m X Y Z ^ ] _ Z ` a b _ Z c d e ] f _ l Z [ Z _ ` ] Z ^
_ Z k g Z ^ ] ^ q e f a b f ^ Z c
h
o ` p g j j ^ ] _ Z ` a f p d [ ^ ] _ g e s
] d f [ ^ q
u
Y d e Y ` _ Z ^ ] f _ Z c d [ ] Y Z ‹ X  m X Y Z ^ Z _ Z s
k g Z ^ ] ^ ` _ Z g ^ Z c ] f c _ d i Z ] Y Z d [ ^ ] _ g e ] d f [ e ` e Y Z q
f
h
] ` d [ ` j d [ Z p _ f a d ] q ` [ c ^ Z j Z e ]
u
Y d e Y d [ ^ ] _ g e s
] d f [ ^ p _ f a ] Y Z j d [ Z ^ Y f g j c
h
Z Z \ Z e g ] Z c m t [ ] Y Z
^ ` a Z
u
` o q ] Y Z _ Z a ` d [ c Z _ ] Y _ Z Z p Z ] e Y a f c Z j ^
g ^ Z ` [ ‹ X  ] f c Z e f g b j Z ] Y Z
h
_ ` [ e Y b _ Z c d e ] d f [
^ ] ` l Z p _ f a ] Y Z p Z ] e Y ^ ] ` l Z m
 g _ d ‘ X ‘ p Z ] e Y a f c Z j d ^ d [ ^ b d _ Z c
h
o ] Y Z
n û ü p Z ] e Y Z [ l d [ Z c Z ^ d l [ c Z ^ e _ d
h
Z c d [ €
Œ Œ
ƒ m
t [ ` c c d ] d f [ q ] Y Z d ‘ X ‘ a f c Z j c Z e f g b j Z ^ ] Y Z
h
_ ` [ e Y b _ Z c d e ] d f [ a Z e Y ` [ d ^ a p _ f a ] Y Z d [ s
^ ] _ g e ] d f [ e ` e Y Z g ^ d [ l ` [ ‹ X  m
”
[ d [ ] Z _ j Z ` i Z c
‘ X ‘ d ^ g ^ Z c ] f ` j j f
u
] Y Z b _ Z c d e ] d f [ f p a g j ] d s
b j Z
h
_ ` [ e Y Z ^ g [ ] d j ` ] ` r Z [
h
_ ` [ e Y d ^ b _ Z c d e ] Z c q
f _ g [ ] d j ` [ ` j d l [ Z c ü s d [ ^ ] _ g e ] d f [
h
j f e r d ^ e f a s
b j Z ] Z c m X Y Z
h
_ ` [ e Y b _ Z c d e ] d f [ Y d ^ ] f _ o d ^ g b s
c ` ] Z c g ^ d [ l ` ^ d [ l j Z
h
d ] p f _ b _ Z c d e ] d f [
h
j f e r q
u
Y d e Y e f a
h
d [ Z ^ ] Y Z f g ] e f a Z f p ] Y Z j ` ^ ]
h
_ ` [ e Y
d [ ] Y Z
h
j f e r
u
d ] Y b ` ] Y d [ p f _ a ` ] d f [ €
Œ Œ
ƒ m  g _
‹ X ‘ a f c Z j d ^ ^ d a d j ` _ ] f ] Y Z f [ Z c Z ^ e _ d
h
Z c
d [ € ÿ ƒ
h
g ] g ^ d [ l ` b Z _ e Z b ] _ f [
h
_ ` [ e Y b _ Z c d e s
] f _ € þ ƒ ] f b _ Z c d e ] ] Y Z c d _ Z e ] d f [ f p e f [ c d ] d f [ ` j
h
_ ` [ e Y Z ^ m ‹ d l g _ Z § m
h
^ Y f
u
^ ` c d ` l _ ` a _ Z b _ Z s
^ Z [ ] d [ l ] Y Z ^ Z ]
u
f p Z ] e Y ` _ e Y d ] Z e ] g _ Z ^ m
XVI Jornadas de Paralelismo, JP '2005 5
Fetch
Address Next
Stream
Predictor
FTQ
RAS
Instruction
Cache
STREAM
 ` 
—
] _ Z ` a p Z ] e Y Z [ l d [ Z
Instruction
Cache
Fetch
Address
interleaved BTB / FTB
FTQ
Next Address Logic
2bcgskew / perceptron
RAS
Fetch
Block
indirect branch predictor

h
 d ‘ X ‘  ‹ X ‘ p Z ] e Y ` _ e Y d ] Z e ] g _ Z
Trace Cache
Trace
Identifier
Next Trace
Predictor
Interleaved BTB
Instruction Cache
Trace
Buffers
FTQ
RHS
RAS
TRACE
 e  X _ ` e Z e ` e Y Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z
„ 4 … 3 + (  ‡ „ ( , 5  - 7 / ( < 8 ( : * < 3 * , ( / P
 g _ ] _ ` e Z e ` e Y Z p Z ] e Y a f c Z j d ^ ^ d a d j ` _ ] f
] Y Z f [ Z c Z ^ e _ d
h
Z c d [ € ü ƒ
h
g ] Z [ Y ` [ e Z c g ^ d [ l ` [
‹ X  € ÿ ƒ ] f c Z e f g b j Z ] Y Z ] _ ` e Z b _ Z c d e ] f _ p _ f a
] Y Z ] _ ` e Z e ` e Y Z q ` ^ ^ Y f
u
[ d [ ‹ d l g _ Z § m e m X _ ` e Z
b _ Z c d e ] d f [ ^ ` _ Z ^ ] f _ Z c d [ ] Y Z ‹ X  q
u
Y d e Y p Z Z c ^
] Y Z ] _ ` e Z e ` e Y Z
u
d ] Y ] _ ` e Z d c Z [ ] d Ž Z _ ^ m
”
[ d [ ] Z _ s
j Z ` i Z c ‘ X ‘ d ^ g ^ Z c ] f
h
g d j c ] _ ` e Z ^ d [ ] Y Z e ` ^ Z
f p ` ] _ ` e Z e ` e Y Z a d ^ ^ m X Y d ^ ‘ X ‘ g ^ Z ^ § s
h
d ]
^ ` ] g _ ` ] d [ l e f g [ ] Z _ ^ ] f b _ Z c d e ] ] Y Z c d _ Z e ] d f [ f p
e f [ c d ] d f [ ` j
h
_ ` [ e Y Z ^
u
Y Z [ ` ] _ ` e Z b _ Z c d e ] d f [
d ^ [ f ] ` i ` d j `
h
j Z m t [ ` c c d ] d f [ q ` [ ` l l _ Z ^ ^ d i Z § s
u
` o d [ ] Z _ j Z ` i Z c d [ ^ ] _ g e ] d f [ e ` e Y Z d ^ g ^ Z c ] f ` j s
j f
u
] _ ` e Z ^ ] f
h
Z
h
g d j ] ` ^ p ` ^ ] ` ^ b f ^ ^ d
h
j Z m X Y d ^
a Z e Y ` [ d ^ a d ^ `
h
j Z ] f f
h
] ` d [ g b ] f ` p g j j e ` e Y Z
j d [ Z d [ ` e o e j Z q d [ c Z b Z [ c Z [ ] f p
¦
™ ` j d l [ a Z [ ] m
     !   "        !    
v Z Y ` i Z Z i ` j g ` ] Z c ] Y Z p f g _ ^ d a g j ` ] Z c p Z ] e Y
Z [ l d [ Z ^ i ` _ o d [ l ] Y Z ^ d ˜ Z f p ] Y Z
h
_ ` [ e Y b _ Z c d e s
] f _ p _ f a ^ a ` j j ` [ c p ` ^ ] ] `
h
j Z ^ ] f
h
d l ` [ c ^ j f
u
] `
h
j Z ^ m v Z g ^ Z _ Z ` j d ^ ] d e b _ Z c d e ] d f [ ] `
h
j Z ` e s
e
Z ^ ^ j ` ] Z [ e d Z ^ e ` j e g j ` ] Z c g ^ d [ l ] Y Z ™
”
™ X t • m
š
] f f j €
Œ
• ƒ m v Z a f c d Ž Z c ™
”
™ X t ] f a f c Z j ] ` l s
j Z ^ ^
h
_ ` [ e Y b _ Z c d e ] f _ ^ q ` [ c ] f
u
f _ r
u
d ] Y ^ Z s
] g b ^ Z \ b _ Z ^ ^ Z c d [
h
d ] ^ d [ ^ ] Z ` c f p
h
o ] Z ^ m # ` ] `
u
Z Y ` i Z f
h
] ` d [ Z c e f _ _ Z ^ b f [ c ^ ] f
š
m
Œ š
µ
a ] Z e Y s
[ f j f l o m ‹ f _ ] _ ` [ ^ j ` ] d [ l ] Y Z ` e e Z ^ ^ ] d a Z p _ f a
[ ` [ f ^ Z e f [ c ^ ] f e o e j Z ^ q
u
Z ` ^ ^ g a Z c ` [ ` l l _ Z ^ s
^ d i Z ü p ` [ s f g ] s f p s p f g _ c Z j ` o ^ e j f e r b Z _ d f c q d m Z m q
` • m þ  $ ~ ˜ e j f e r p _ Z k g Z [ e o ` ^ _ Z b f _ ] Z c d [ €
Œ
ƒ m
v Z Y ` i Z p f g [ c ] Y ` ] ] Y Z
h
Z ^ ] b Z _ p f _ a ` [ e Z d ^
` e Y d Z i Z c g ^ d [ l ] Y _ Z Z s e o e j Z j ` ] Z [ e o ] `
h
j Z ^ €
Œ š
ƒ m
”
j ] Y f g l Y
h
d l l Z _ b _ Z c d e ] f _ ^ ` _ Z ^ j d l Y ] j o a f _ Z
` e e g _ ` ] Z q ] Y Z d _ d [ e _ Z ` ^ Z c ` e e Z ^ ^ c Z j ` o Y ` _ a ^
b _ f e Z ^ ^ f _ b Z _ p f _ a ` [ e Z m  [ ] Y Z f ] Y Z _ Y ` [ c q
b _ Z c d e ] f _ ^
u
d ] Y ` j f
u
Z _ j ` ] Z [ e o ` _ Z ] f f ^ a ` j j
` [ c ` e Y d Z i Z b f f _ b Z _ p f _ a ` [ e Z m X Y Z _ Z p f _ Z q
u
Z
Y ` i Z e Y f ^ Z [ ] f ^ d a g j ` ] Z ` j j
h
_ ` [ e Y b _ Z c d e ] f _ ^
g ^ d [ l ] Y Z
h
d l l Z _ ] `
h
j Z ^ ] Y ` ] e ` [
h
Z ` e e Z ^ ^ Z c
d [ ] Y _ Z Z e o e j Z ^ m X `
h
j Z § ^ Y f
u
^ ] Y Z e f [ Ž l g _ ` s
] d f [ f p ] Y Z ^ d a g j ` ] Z c b _ Z c d e ] f _ ^ m v Z Y ` i Z Z \ s
b j f _ Z c `
u
d c Z _ ` [ l Z f p Y d ^ ] f _ o j Z [ l ] Y ^ q ` ^
u
Z j j
` ^ #   ™ d [ c Z \ € § ƒ e f [ Ž l g _ ` ] d f [ ^ q ` [ c ^ Z j Z e ] Z c
] Y Z
h
Z ^ ] f [ Z p f g [ c p f _ Z ` e Y ^ Z ] g b m X `
h
j Z § ` j ^ f
^ Y f
u
^ ] Y Z ` b b _ f \ d a ` ] Z Y ` _ c
u
` _ Z
h
g c l Z ] p f _
Z ` e Y b _ Z c d e ] f _ m
—
d [ e Z
u
Z ^ d a g j ` ] Z ] Y Z j ` _ l Z _
] Y _ Z Z e o e j Z j ` ] Z [ e o ] `
h
j Z ^ q ] Y Z ] f ] ` j Y ` _ c
u
` _ Z
h
g c l Z ] c Z i f ] Z c ] f Z ` e Y b _ Z c d e ] f _ d ^ c d – Z _ Z [ ] m
X Y Z ^ ] _ Z ` a p Z ] e Y Z [ l d [ Z _ Z k g d _ Z ^ j Z ^ ^ Y ` _ c
u
` _ Z
_ Z ^ f g _ e Z ^
h
Z e ` g ^ Z d ] g ^ Z ^ ` ^ d [ l j Z b _ Z c d e ] d f [
a Z e Y ` [ d ^ a q
u
Y d j Z ] Y Z f ] Y Z _ Z i ` j g ` ] Z c p Z ] e Y ` _ s
e Y d ] Z e ] g _ Z ^ g ^ Z ^ f a Z ^ Z b ` _ ` ] Z ^ ] _ g e ] g _ Z ^ m
 g _ p Z ] e Y a f c Z j ^ ` j ^ f g ^ Z ` [ f i Z _ _ d c d [ l
a Z e Y ` [ d ^ a € • q
Œ Œ
ƒ ] f e f a b j Z ] Z `
h
_ ` [ e Y b _ Z s
c d e ] d f [ Z ` e Y e o e j Z m
”
^ a ` j j
h
_ ` [ e Y b _ Z c d e ] f _ q
^ g b b f ^ Z c ] f
h
Z d a b j Z a Z [ ] Z c g ^ d [ l i Z _ o p ` ^ ]
Y ` _ c
u
` _ Z q l Z [ Z _ ` ] Z ^ ] Y Z [ Z \ ] p Z ] e Y ` c c _ Z ^ ^ d [
` ^ d [ l j Z e o e j Z m
”
j ] Y f g l Y
h
Z d [ l p ` ^ ] q ] Y d ^ b _ Z s
c d e ] f _ Y ` ^ j f
u
` e e g _ ` e o q ^ f ] Y Z a ` d [ b _ Z c d e ] f _
d ^ g ^ Z c ] f b _ f i d c Z ` [ ` e e g _ ` ] Z
h
` e r s g b b _ Z c d e s
] d f [ m X Y d ^ b _ Z c d e ] d f [ d ^ f
h
] ` d [ Z c ] Y _ Z Z e o e j Z ^
j ` ] Z _ ` [ c e f a b ` _ Z c
u
d ] Y ] Y Z b _ Z c d e ] d f [ b _ f s
i d c Z c
h
o ] Y Z ^ d [ l j Z s e o e j Z b _ Z c d e ] f _ m t p
h
f ] Y
b _ Z c d e ] d f [ ^ c d – Z _ q ] Y Z [ Z
u
b _ Z c d e ] d f [ f i Z _ _ d c Z ^
] Y Z b _ Z i d f g ^ f [ Z q c d ^ e ` _ c d [ l ] Y Z ^ b Z e g j ` ] d i Z
u
f _ r c f [ Z
h
` ^ Z c f [ d ] m X Y Z e f [ Ž l g _ ` ] d f [ f p
] Y Z ^ d [ l j Z s e o e j Z b _ Z c d e ] f _ ^ g ^ Z c d ^ ^ Y f
u
[ d [ X ` s
h
j Z § m
6 Arquitectura del Procesador y Multiprocesadores
% & ' & ( ) * + , - . + , % * ) + * / . ) 0 - 1 1 . 2 3 4 5 5 6 7 & 8
ä ½
³ Ì ¿ ñ ±
ð
 à ± ¶ À ³ Á Å Ã À Ç Á ± à ´ ± ¾
È
± ¶
î 9 î
À Ç ¶ À Ã ± ³ Á Â Ã ± ¶ À ³ Á Å Ã é
ï
³ É ³ ´ ± Â Ã ± ¶ À ³ Á Å Ã
Ä Å µ Ã å á
í
± Ç Á Ã É Á ¾
½
´ ± ¿ á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É å á ± Ç Á Ã É Ì ¿ Ê ¾ Ã ±
é å
½
À Á Ê À ¿ Á Å Ã É ; < = > é á
ï ä ï
á
ï
é ê å
ï ½
À Á Ê À ¿ Á Å Ã É
ø
½
À Æ Å ¶ ¾ ´ ê
½
À Á ¿ ù
ã ä
± Ç Á Ã É Ë é
ï ð
¾ É Ë
î 9 î
?
' & ( ) * + , - . + , % * ) + * / . ) 0 - 1 1 . 2 3 4 @ A 7 & 8
 ± à ³ ±  Á Ã Å Ç Â Ã ± ¶ À ³ Á Å Ã B
9 î
À Ç ¶ À Ã ± ³ Á Â Ã ± ¶ À ³ Á Å Ã é
ï
³ É ³ ´ ± Â Ã ± ¶ À ³ Á Å Ã
ä è
å Â ± Ã ³ ± Â Á Ã Å Ç ¿ á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É å á ± Ç Á Ã É Ì ¿ Ê ¾ Ã ±
á ê : å ² é á
½
À Á ´ Å ³ ¾ ´ ¾ Ç ¶ ; < = > é á
ï ä ï
á
ï
é ê å
ï ½
À Á Ê À ¿ Á Å Ã É
á ê
½
À Á Ì ´ Å
½
¾ ´ Ê À ¿ Á Å Ã É
ã ä
± Ç Á Ã É Ë é
ï ð
¾ É Ë
î 9 î
C * . ) - D ( ) * + , - . + , % * ) + * / . ) 0 - 1 1 . 2 3 4 E F 7 & 8
Ç ± ² Á ¿ Á Ã ± ¾ Æ Â Ã ± ¶ À ³ Á Å Ã é
ï
³ É ³ ´ ± Â Ã ± ¶ À ³ Á Å Ã
é ê
ä
á ± Ç Á Ã É Ë á
ï ð
¾ É Ë G Ã ¿ Á ´ ±
È
± ´
ã ä
± Ç Á Ã É Ë é
ï ð
¾ É Ë ¿ Â Ã ± ¶
á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É Ë ¿ ± ³ Å Ç ¶ ´ ±
È
± ´ ; < = > ê
ï
ê
ï
ê
ï è
; < = > é å
ï ä ï
á
ï
é ê
' . - + ) ( ) * + , - . + , % * ) + * / . ) 0 - 1 1 . 2 3 4 H A 7 & 8
Ç ± ² Á Á Ã ¾ ³ ± Â Ã ± ¶ À ³ Á Å Ã À Ç Á ± Ã ´ ± ¾
È
± ¶
î 9 î
é
ï
³ É ³ ´ ± Â Ã ± ¶ À ³ Á Å Ã
ä
ê á Ù ± Ç Á Ã É Ë á
ï ð
¾ É Ë G Ã ¿ Á ´ ±
È
± ´ á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É
ã ä
± Ç Á Ã É Ë é
ï ð
¾ É Ë Á Â Ã ± ¶
á ê : å ± Ç Á Ã É Ë á
ï ð
¾ É Ë ¿ ± ³ Å Ç ¶ ´ ±
È
± ´ ; < = > ê
ï
ê
ï
ê
ï è
; < = > é ê
ï
á
ï I ï
: Â ± Ã Ä ± ³ Á
î 9 î
Å
È
± Ã Ã À ¶ ±
X `
h
j Z §
ú
™ f [ Ž l g _ ` ] d f [ f p ] Y Z ^ d a g j ` ] Z c
h
_ ` [ e Y b _ Z c d e ] f _ ^ m
J
¢ | ¡ T }
ž
¡
Ÿ K
T U
Ÿ
V   L U
Ÿ
{ } W T } z
y
X Y Z [ Z \ ] ^ ] _ Z ` a b _ Z c d e ] f _ €  q ‚ ƒ q
u
Y d e Y d ^
^ Y f
u
[ d [ ‹ d l g _ Z • m ` q d ^ ` ^ b Z e d ` j d ˜ Z c
h
_ ` [ e Y
b _ Z c d e ] f _ ] Y ` ] b _ f i d c Z ^ ^ ] _ Z ` a j Z i Z j ^ Z k g Z [ e s
d [ l m $ d i Z [ ` p Z ] e Y ` c c _ Z ^ ^ q d m Z m q ] Y Z e g _ _ Z [ ]
^ ] _ Z ` a ^ ] ` _ ] d [ l ` c c _ Z ^ ^ q ] Y Z ^ ] _ Z ` a b _ Z c d e ] f _
b _ f i d c Z ^ ] Y Z e g _ _ Z [ ] ^ ] _ Z ` a j Z [ l ] Y q
u
Y d e Y d [ c d s
e ` ] Z ^
u
Y Z _ Z d ^ ] Y Z ] ` r Z [
h
_ ` [ e Y ] Y ` ] Ž [ ` j d ˜ Z ^
] Y Z ^ ] _ Z ` a m X Y Z b _ Z c d e ] f _ ` j ^ f b _ f i d c Z ^ ] Y Z
[ Z \ ] ^ ] _ Z ` a ^ ] ` _ ] d [ l ` c c _ Z ^ ^ q
u
Y d e Y d ^ g ^ Z c
` ^ ] Y Z p Z ] e Y ` c c _ Z ^ ^ p f _ ] Y Z [ Z \ ] e o e j Z m X Y Z
e g _ _ Z [ ] ^ ] _ Z ` a ^ ] ` _ ] d [ l ` c c _ Z ^ ^ ` [ c ] Y Z e g _ s
_ Z [ ] ^ ] _ Z ` a j Z [ l ] Y p f _ a ` p Z ] e Y _ Z k g Z ^ ] ] Y ` ] d ^
^ ] f _ Z c d [ ] Y Z ‹ X  m X Y Z p Z ] e Y _ Z k g Z ^ ] ^ ^ ] f _ Z c
d [ ] Y Z ‹ X  ` _ Z ] Y Z [ g ^ Z c ] f c _ d i Z ] Y Z d [ ^ ] _ g e s
] d f [ e ` e Y Z m
”
e ] g ` j j o q ] Y Z ^ ] _ Z ` a b _ Z c d e ] f _ d ^ e f a b f ^ Z c
h
o ]
u
f e ` ^ e ` c Z c ] `
h
j Z ^
ú
` Ž _ ^ ] j Z i Z j ] `
h
j Z d [ s
c Z \ Z c f [ j o
h
o ] Y Z p Z ] e Y ` c c _ Z ^ ^ q ` [ c ` ^ Z e f [ c
j Z i Z j ] `
h
j Z d [ c Z \ Z c g ^ d [ l b ` ] Y e f _ _ Z j ` ] d f [ m
”
^ ] _ Z ` a d ^ f [ j o d [ ] _ f c g e Z c d [ ] Y Z ^ Z e f [ c j Z i Z j d p
d ] d ^ [ f ] ` e e g _ ` ] Z j o b _ Z c d e ] Z c
h
o ] Y Z Ž _ ^ ] j Z i Z j m
X Y Z _ Z p f _ Z q ] Y f ^ Z ^ ] _ Z ` a ^ ] Y ` ] c f [ f ] [ Z Z c e f _ s
_ Z j ` ] d f [ ` _ Z r Z b ] d [ ] Y Z Ž _ ^ ] j Z i Z j q ` i f d c d [ l g [ s
[ Z e Z ^ ^ ` _ o ` j d ` ^ d [ l m t [ f _ c Z _ ] f l Z [ Z _ ` ] Z ` b _ Z s
c d e ] d f [ q
h
f ] Y j Z i Z j ^ ` _ Z j f f r Z c g b d [ b ` _ ` j j Z j m
t p ] Y Z _ Z d ^ ` ^ Z e f [ c j Z i Z j ] `
h
j Z Y d ] q d ] ^ b _ Z c d e s
] d f [ d ^ g ^ Z c m  ] Y Z _
u
d ^ Z q ] Y Z b _ Z c d e ] d f [ f p ] Y Z
Ž _ ^ ] j Z i Z j ] `
h
j Z d ^ g ^ Z c m X Y Z ^ Z e f [ c j Z i Z j b _ Z s
c d e ] d f [ d ^ b _ d f _ d ] d ˜ Z c
h
Z e ` g ^ Z d ] d ^ ^ g b b f ^ Z c ] f
h
Z a f _ Z ` e e g _ ` ] Z ] Y ` [ ] Y Z Ž _ ^ ] j Z i Z j c g Z ] f
] Y Z g ^ Z f p b ` ]
Y e f _ _ Z j ` ] d f [ m
   M   
  
       "       
X Y Z f
h
“ Z e ] d i Z f p f g _ a g j ] d b j Z ^ ] _ Z ` a b _ Z c d e ] f _
d ^ b _ Z c d e ] d [ l ] f l Z ] Y Z _ ] Y f ^ Z ^ ] _ Z ` a ^ ] Y ` ] ` _ Z
p _ Z k g Z [ ] j o Z \ Z e g ] Z c ` ^ ` ^ Z k g Z [ e Z m  [ j d r Z ] Y Z
] _ ` e Z e ` e Y Z q ] Y Z d [ ^ ] _ g e ] d f [ ^ e f _ _ Z ^ b f [ c d [ l ] f
` ^ Z k g Z [ e Z f p ^ ] _ Z ` a ^ ` _ Z [ f ] ^ ] f _ Z c ] f l Z ] Y Z _
d [ ` ^ b Z e d ` j b g _ b f ^ Z
h
g – Z _ m X Y Z d [ ^ ] _ g e ] d f [
^ ] _ Z ` a ^
h
Z j f [ l d [ l ] f ` b _ Z c d e ] Z c ^ Z k g Z [ e Z ` _ Z
^ ] d j j ^ Z b ` _ ` ] Z ^ ] _ Z ` a ^ ^ ] f _ Z c d [ ] Y Z d [ ^ ] _ g e ] d f [
e ` e Y Z m X Y Z _ Z p f _ Z q ] Y Z a g j ] d b j Z ^ ] _ Z ` a b _ Z c d e s
] f _ c f Z ^ [ f ] Z [ `
h
j Z ] Y Z `
h
d j d ] o f p p Z ] e Y d [ l d [ s
^ ] _ g e ] d f [ ^
h
Z o f [ c ` ] ` r Z [
h
_ ` [ e Y d [ ` ^ d [ l j Z
e o e j Z m X Y Z
h
Z [ Z Ž ] f p f g _ ] Z e Y [ d k g Z e f a Z ^ p _ f a
l _ f g b d [ l b _ Z c d e ] d f [ ^ q ` j j f
u
d [ l ] f ] f j Z _ ` ] Z ] Y Z
b _ Z c d e ] d f [ ] `
h
j Z ` e e Z ^ ^ j ` ] Z [ e o m
‹ d l g _ Z • m
h
^ Y f
u
^ ] Y Z Ž Z j c ^ _ Z k g d _ Z c
h
o ` § s
^ ] _ Z ` a a g j ] d b j Z b _ Z c d e ] f _ m  d r Z ] Y Z f _ d l d [ ` j
^ d [ l j Z ^ ] _ Z ` a b _ Z c d e ] f _ q ` § s ^ ] _ Z ` a b _ Z c d e ] f _
_ Z k g d _ Z ^ ` ^ d [ l j Z ] ` l Ž Z j c q
u
Y d e Y e f _ _ Z ^ b f [ c ^
] f ] Y Z ^ ] ` _ ] d [ l ` c c _ Z ^ ^ f p ] Y Z ^ ] _ Z ` a ^ Z k g Z [ e Z m
~ f
u
Z i Z _ q ] Y Z _ Z ^ ] f p ] Y Z Ž Z j c ^ ^ Y f g j c
h
Z c g s
b j d e ` ] Z c m X Y Z ] ` l ` [ c j Z [ l ] Y Ž Z j c ^ c Z ] Z _ a d [ Z
] Y Z Ž _ ^ ] ^ ] _ Z ` a ] Y ` ] ^ Y f g j c
h
Z Z \ Z e g ] Z c m X Y Z
] ` _ l Z ] f p ] Y d ^ ^ ] _ Z ` a q c Z ] Z _ a d [ Z c
h
o ] Y Z [ Z \ ]
^ ] _ Z ` a Ž Z j c q d ^ ] Y Z ^ ] ` _ ] d [ l ` c c _ Z ^ ^ f p ] Y Z ^ Z e s
XVI Jornadas de Paralelismo, JP '2005 7
Previous Stream
Previous Stream
Previous Stream
Current Address
hash
Tag Length Next Stream
Address Indexed Table
Path Indexed Table
Hysteresis
Tag Length Next Stream Hysteresis
 `  e ` ^ e ` c Z c b _ Z c d e ] f _ c Z ^ d l [
Tag
Length
Next Stream
Hysteresis
Single Stream
Predictor
Tag
Length
Next Stream
Hysteresis
2-Stream
Predictor
Length 2
Next Stream 2
Hysteresis 2

h
 Ž Z j c ^ _ Z k g d _ Z c p f _ a g j ] d b j Z b _ Z c d e ] d f [
„ 4 … 3 + ( N ‡ O  ( . ( ‰ , 8 , + ( * - ) + ( / 4 5 , 7 + P
f [ c ^ ] _ Z ` a q
u
Y f ^ Z j Z [ l ] Y d ^ l d i Z [
h
o ] Y Z ^ Z e s
f [ c j Z [ l ] Y Ž Z j c m X Y Z ^ Z e f [ c [ Z \ ] ^ ] _ Z ` a Ž Z j c
d ^ ] Y Z ] ` _ l Z ] f p ] Y Z ^ Z e f [ c ^ ] _ Z ` a q ` [ c ] Y g ^
] Y Z [ Z \ ] p Z ] e Y ` c c _ Z ^ ^ m
t [ ] Y d ^
u
` o q ` ^ d [ l j Z b _ Z c d e ] d f [ ] `
h
j Z j f f r g b
b _ f i d c Z ^ ]
u
f ^ Z b ` _ ` ] Z ^ ] _ Z ` a b _ Z c d e ] d f [ ^ q
u
Y d e Y ` _ Z ^ g b b f ^ Z c ] f
h
Z Z \ Z e g ] Z c ^ Z k g Z [ s
] d ` j j o m
”
p ] Z _ ` a g j ] d b j Z ^ ] _ Z ` a b _ Z c d e ] d f [ q Z i s
Z _ o ^ ] _ Z ` a
h
Z j f [ l d [ l ] f ` b _ Z c d e ] Z c ^ Z k g Z [ e Z
d ^ ^ ] f _ Z c ^ Z b ` _ ` ] Z j o d [ ] Y Z ‹ X  q
u
Y d e Y d [ i f j i Z ^
] Y ` ] g ^ d [ l ] Y Z a g j ] d b j Z s ^ ] _ Z ` a b _ Z c d e ] f _ c f Z ^
[ f ] _ Z k g d _ Z ` c c d ] d f [ ` j e Y ` [ l Z ^ d [ ] Y Z b _ f e Z ^ s
^ f _ p _ f [ ] s Z [ c m n \ ] Z [ c d [ l ] Y d ^ a Z e Y ` [ d ^ a p f _
b _ Z c d e ] d [ l ] Y _ Z Z f _ a f _ Z ^ ] _ Z ` a ^ b Z _ ^ Z k g Z [ e Z
u
f g j c
h
Z ^ ] _ ` d l Y ] p f _
u
` _ c q
h
g ]
u
Z Y ` i Z p f g [ c
] Y ` ] ^ Z k g Z [ e Z ^ Y ` i d [ l a f _ Z ] Y ` [ ]
u
f ^ ] _ Z ` a ^
c f [ f ] b _ f i d c Z ` c c d ] d f [ ` j
h
Z [ Z Ž ] m
   
  
       "        P    Q !
¦
_ f i d c d [ l ]
u
f ^ ] _ Z ` a ^ b Z _ b _ Z c d e ] d f [ [ Z Z c ^
c g b j d e ` ] d [ l ] Y Z b _ Z c d e ] d f [ ] `
h
j Z ^ d ˜ Z m t [ f _ c Z _
] f ` i f d c ` [ Z l ` ] d i Z d a b ` e ] f [ ] Y Z b _ Z c d e ] d f [
] `
h
j Z ` e e Z ^ ^ j ` ] Z [ e o ` [ c Z [ Z _ l o e f [ ^ g a b ] d f [ q
u
Z f [ j o ^ ] f _ Z a g j ] d b j Z ^ ] _ Z ` a ^ d [ ] Y Z Ž _ ^ ] s j Z i Z j
] `
h
j Z f p ] Y Z e ` ^ e ` c Z c ^ ] _ Z ` a b _ Z c d e ] f _ q
u
Y d e Y
d ^ ^ a ` j j Z _ ] Y ` [ ] Y Z ^ Z e f [ c s j Z i Z j ] `
h
j Z m
—
d [ e Z
] Y Z ^ ] _ Z ` a ^
h
Z j f [ l d [ l
] f ` ^ Z k g Z [ e Z ` _ Z ^ g b s
b f ^ Z c ] f
h
Z p _ Z k g Z [ ] j o Z \ Z e g ] Z c ] f l Z ] Y Z _ q d ] d ^
j d r Z j o ] Y ` ] q l d i Z [ ` p Z ] e Y ` c c _ Z ^ ^ q ] Y Z Z \ Z e g ] Z c
^ Z k g Z [ e Z d ^ ` j
u
` o ^ ] Y Z ^ ` a Z m ™ f [ ^ Z k g Z [ ] j o q
^ ] _ Z ` a ^ Z k g Z [ e Z ^ c f [ f ] [ Z Z c e f _ _ Z j ` ] d f [ ] f
h
Z e f _ _ Z e ] j o b _ Z c d e ] Z c q ` [ c ] Y g ^ r Z Z b d [ l ] Y Z a
d [ ] Y Z Ž _ ^ ] j Z i Z j ] `
h
j Z c f Z ^ [ f ] j d a d ] ] Y Z ` e Y d Z i s
`
h
j Z
h
Z [ Z Ž ] m
t [ f _ c Z _ ] f ] ` r Z a ` \ d a g a ` c i ` [ ] ` l Z f p ] Y Z
` i ` d j `
h
j Z ^ b ` e Z d [ ] Y Z Ž _ ^ ] j Z i Z j ] `
h
j Z q
u
Z g ^ Z
Y o ^ ] Z _ Z ^ d ^ e f g [ ] Z _ ^ ] f c Z ] Z e ] p _ Z k g Z [ ] j o Z \ Z s
e g ] Z c ^ ] _ Z ` a ^ Z k g Z [ e Z ^ m n i Z _ o ^ ] _ Z ` a d [ `
^ Z k g Z [ e Z Y ` ^ ` Y o ^ ] Z _ Z ^ d ^ e f g [ ] Z _ ` ^ ^ f e d ` ] Z c
] f d ] m
”
j j Y o ^ ] Z _ Z ^ d ^ e f g [ ] Z _ ^
h
Z Y ` i Z j d r Z ] Y Z
e f g [ ] Z _ g ^ Z c
h
o ] Y Z f _ d l d [ ` j ^ ] _ Z ` a b _ Z c d e s
] f _ ] f c Z e d c Z
u
Y Z ] Y Z _ ` ^ ] _ Z ` a ^ Y f g j c
h
Z _ Z s
b j ` e Z c p _ f a ] Y Z b _ Z c d e ] d f [ ] `
h
j Z € ‚ ƒ m v Y Z [ ] Y Z
b _ Z c d e ] f _ d ^ g b c ` ] Z c
u
d ] Y ` [ Z
u
^ ] _ Z ` a q ] Y Z
e f _ _ Z ^ b f [ c d [ l e f g [ ] Z _ d ^ d [ e _ Z ` ^ Z c d p ] Y Z [ Z
u
^ ] _ Z ` a a ` ] e Y Z ^
u
d ] Y ] Y Z ^ ] _ Z ` a ` j _ Z ` c o ^ ] f _ Z c
d [ ] Y Z ^ Z j Z e ] Z c Z [ ] _ o m  ] Y Z _
u
d ^ Z q ] Y Z e f g [ ] Z _
d ^ c Z e _ Z ` ^ Z c ` [ c q d p d ] _ Z ` e Y Z ^ ˜ Z _ f q ] Y Z
u
Y f j Z
b _ Z c d e ] f _ Z [ ] _ o d ^ _ Z b j ` e Z c
u
d ] Y ] Y Z [ Z
u
c ` ] ` q
^ Z ] ] d [ l ] Y Z e f g [ ] Z _ ] f f [ Z m t p ] Y Z c Z e _ Z ` ^ Z c
e f g [ ] Z _ c f Z ^ [ f ] _ Z ` e Y ˜ Z _ f q ] Y Z [ Z
u
c ` ] ` d ^
c d ^ e ` _ c Z c m v Z Y ` i Z p f g [ c ] Y ` ] • s
h
d ] Y o ^ ] Z _ Z s
^ d ^ e f g [ ] Z _ ^ q d [ e _ Z ` ^ Z c
h
o f [ Z ` [ c c Z e _ Z ` ^ Z c
h
o ]
u
f q b _ f i d c Z ] Y Z
h
Z ^ ] _ Z ^ g j ] ^ p f _ ] Y Z a g j ] d s
b j Z ^ ] _ Z ` a b _ Z c d e ] f _ m
v Y Z [ ] Y Z b _ Z c d e ] d f [ ] `
h
j Z d ^ j f f r Z c g b q
] Y Z Ž _ ^ ] ^ ] _ Z ` a d ^ ` j
u
` o ^ b _ f i d c Z c m ~ f
u
s
Z i Z _ q ] Y Z ^ Z e f [ c ^ ] _ Z ` a d ^ f [ j o b _ Z c d e ] Z c d p ] Y Z
e f _ _ Z ^ b f [ c d [ l Y o ^ ] Z _ Z ^ d ^ e f g [ ] Z _ d ^ ^ ` ] g _ ` ] Z c q
] Y ` ] d ^ q d p ] Y Z e f g [ ] Z _ Y ` ^ _ Z ` e Y Z c d ] ^ a ` \ d s
a g a i ` j g Z m X Y Z _ Z p f _ Z q d p ] Y Z ^ Z e f [ c Y o ^ ] Z _ Z ^ d ^
e f g [ ] Z _ d ^ [ f ] ^ ` ] g _ ` ] Z c q ] Y Z a g j ] d b j Z ^ ] _ Z ` a
b _ Z c d e ] f _ b _ f i d c Z ^ ` ^ d [ l j Z ^ ] _ Z ` a b _ Z c d e ] d f [
` ^ d ]
u
f g j c
h
Z c f [ Z
h
o ] Y Z f _ d l d [ ` j ^ ] _ Z ` a b _ Z s
c d e ] f _ m  [ ] Y Z e f [ ] _ ` _ o q d p ] Y Z ]
u
f Y o ^ ] Z _ Z ^ d ^
e f g [ ] Z _ ^ ` _ Z ^ ` ] g _ ` ] Z c q ] Y Z [ ` p _ Z k g Z [ ] j o Z \ Z s
e g ] Z c ^ Z k g Z [ e Z Y ` ^
h
Z Z [ c Z ] Z e ] Z c q ` [ c ] Y Z ]
u
f
^ ] _ Z ` a ^
h
Z j f [ l d [ l ] f ] Y d ^ ^ Z k g Z [ e Z ` _ Z d [ ] _ f s
c g e Z c d [ ] Y Z ‹ X  m
R
L
Ÿ
U S z U   V
y
W
Ÿ œ T
V ¡ | V T } z
y
‹ d l g _ Z þ ^ Y f
u
^ ] Y Z ` i Z _ ` l Z b _ f e Z ^ ^ f _ b Z _ p f _ s
a ` [ e Z ` e Y d Z i Z c
h
o ] Y Z p f g _ Z i ` j g ` ] Z c p Z ] e Y ` _ s
e Y d ] Z e ] g _ Z ^ q p f _
h
f ] Y ] Y Z
h
` ^ Z j d [ Z ` [ c ] Y Z f b ] d s
8 Arquitectura del Procesador y Multiprocesadores
„ 4 … 3 + ( U ‡ ; + 7 5 ( 8 8 7 + ) ( + Š 7 + - * . 5 ( V  ( . 3 8 4 . … W Š 3 < <
X
* + Y * . / . 7 , 3 8 4 . … W 8  * / 7 V ( /
X
* + Y 7 : ( + + 4 / 4 . … P
a d ˜ Z c e f c Z j ` o f g ] m v Z Y ` i Z Z i ` j g ` ] Z c `
u
d c Z
_ ` [ l Z f p b _ Z c d e ] f _ ^ Z ] g b ^ ` [ c ^ Z j Z e ] Z c ] Y Z
h
Z ^ ]
f [ Z p f g [ c p f _ Z ` e Y Z i ` j g ` ] Z c b _ Z c d e ] f _ m ‘ Z s
^ d c Z ^ ] Y Z b Z _ p f _ a ` [ e Z f p ] Y Z p f g _ p Z ] e Y Z [ l d [ Z ^
g ^ d [ l f i Z _ _ d c d [ l q ] Y Z b Z _ p f _ a ` [ e Z ` e Y d Z i Z c
h
o
] Y Z ] _ ` e Z e ` e Y Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z ` [ c ] Y Z
^ ] _ Z ` a p Z ] e Y Z [ l d [ Z [ f ] g ^ d [ l f i Z _ _ d c d [ l d ^ ` j ^ f
^ Y f
u
[ m t [ ] Y Z j ` ] ] Z _ e ` ^ Z q ] Y Z ^ ] _ Z ` a p Z ] e Y Z [ s
l d [ Z g ^ Z ^ ` § s ^ ] _ Z ` a a g j ] d b j Z b _ Z c d e ] f _ d [ ^ ] Z ` c
f p ] Y Z f _ d l d [ ` j ^ d [ l j Z s ^ ] _ Z ` a b _ Z c d e ] f _ m
X Y Z a ` d [ f
h
^ Z _ i ` ] d f [ p _ f a ‹ d l g _ Z þ d ^ ] Y ` ]
] Y Z a g j ] d b j Z ^ ] _ Z ` a b _ Z c d e ] f _
u
d ] Y f g ] f i Z _ _ d c s
d [ l b _ f i d c Z ^ ` b Z _ p f _ a ` [ e Z i Z _ o e j f ^ Z ] f ] Y Z
f _ d l d [ ` j ^ d [ l j Z s ^ ] _ Z ` a b _ Z c d e ] f _ g ^ d [ l f i Z _ _ d c s
d [ l m X Y Z b Z _ p f _ a ` [ e Z ` e Y d Z i Z c
h
o ] Y Z a g j s
] d b j Z ^ ] _ Z ` a b _ Z c d e ] f _
u
d ] Y f g ] f i Z _ _ d c d [ l d ^
Z [ f g l Y ] f f g ] b Z _ p f _ a
h
f ] Y ] Y Z d ‘ X ‘ ` [ c ] Y Z
‹ X ‘ p Z ] e Y ` _ e Y d ] Z e ] g _ Z ^ q Z i Z [
u
Y Z [ ] Y Z o c f
g ^ Z f i Z _ _ d c d [ l m X Y Z b Z _ p f _ a ` [ e Z f p ] Y Z a g j ] d s
b j Z ^ ] _ Z ` a b _ Z c d e ] f _
u
d ] Y f g ] f i Z _ _ d c d [ l d ^ ` j ^ f
e j f ^ Z ] f ` ] _ ` e Z e ` e Y Z g ^ d [ l f i Z _ _ d c d [ l q
u
Y d j Z
_ Z k g d _ d [ l j f
u
Z _ e f a b j Z \ d ] o m
‹ d [ ` j j o q d ] ^ Y f g j c
h
Z ] ` r Z [ d [ ] f ` e e f g [ ] ] Y ` ]
] Y d ^ d a b _ f i Z a Z [ ] d ^ ` e Y d Z i Z c
h
o d [ e _ Z ` ^ d [ l ] Y Z
^ d ˜ Z f p ] Y Z Ž _ ^ ] j Z i Z j ] `
h
j Z m ‹ f _ ] g [ ` ] Z j o q ] Y Z
] ` l ` _ _ ` o d ^ g [ a f c d Ž Z c ` [ c [ f ` c c d ] d f [ ` j ` e s
e Z ^ ^ b f _ ] d ^ _ Z k g d _ Z c m v Z Y ` i Z e Y Z e r Z c g ^ d [ l
™
”
™ X t €
Œ
• ƒ ] Y ` ] ] Y Z d [ e _ Z ` ^ Z d [ ] Y Z b _ Z c d e ] f _
` _ Z ` d ^ j Z ^ ^ ] Y ` [
Œ
§ Z q ` ^
u
Z j j ` ^ ] Y ` ] ] Y Z b _ Z s
c d e ] d f [ ] `
h
j Z ` e e Z ^ ^ j ` ] Z [ e o d ^ [ f ] d [ e _ Z ` ^ Z c m
[ f _ Z f i Z _ q f g _ b _ f b f ^ ` j [ f ] f [ j o ` i f d c ^ ] Y Z
[ Z Z c p f _ ` e f a b j Z \ f i Z _ _ d c d [ l a Z e Y ` [ d ^ a q
h
g ]
` j ^ f _ Z c g e Z ^ ] Y Z b _ Z c d e ] f _ Z [ Z _ l o e f [ ^ g a b s
] d f [ m
”
j ] Y f g l Y ] Y Z
h
d l l Z _ Ž _ ^ ] j Z i Z j ] `
h
j Z e f [ s
^ g a Z ^ a f _ Z Z [ Z _ l o b Z _ ` e e Z ^ ^ q d ] d ^ e f a b Z [ s
^ ` ] Z c
u
d ] Y ] Y Z _ Z c g e ] d f [ d [ ] Y Z [ g a
h
Z _ f p b _ Z s
c d e ] d f [ ] `
h
j Z ` e e Z ^ ^ Z ^ m X Y Z `
h
d j d ] o f p b _ f i d c s
d [ l ]
u
f ^ ] _ Z ` a ^ b Z _ b _ Z c d e ] d f [ e ` g ^ Z ^
` •  Z
_ Z c g e ] d f [ d [ ] Y Z ] f ] ` j [ g a
h
Z _ f p b _ Z c d e ] d f [ ] ` s
h
j Z j f f r g b ^ ` [ g b c ` ] Z ^ q
u
Y d e Y j Z ` c ^ ] f `
Œ
§ Z
_ Z c g e ] d f [ d [ ] Y Z f i Z _ ` j j ^ ] _ Z ` a b _ Z c d e ] f _ Z [ s
Z _ l o e f [ ^ g a b ] d f [ m
\ ]
z
y
W ¡ | S } z
y
S
™ g _ _ Z [ ] ] Z e Y [ f j f l o ] _ Z [ c ^ l Z [ Z _ ` ] Z [ Z
u
e Y ` j s
j Z [ l Z ^ p f _ ] Y Z p Z ] e Y ` _ e Y d ] Z e ] g _ Z c Z ^ d l [ m ~ d l Y Z _
e j f e r p _ Z k g Z [ e d Z ^ ` [ c j ` _ l Z _
u
d _ Z c Z j ` o ^ e ` g ^ Z
h
_ ` [ e Y b _ Z c d e ] d f [ ] `
h
j Z ^ ] f _ Z k g d _ Z a g j ] d b j Z
e o e j Z ^ ] f
h
Z ` e e Z ^ ^ Z c €
Œ
q • ƒ q j d a d ] d [ l ] Y Z p Z ] e Y
Z [ l d [ Z b Z _ p f _ a ` [ e Z m X Y d ^ p ` e ] Y ` ^ j Z c ] f
] Y Z c Z i Z j f b a Z [ ] f p e f a b j Z \ Y ` _ c
u
` _ Z a Z e Y s
` [ d ^ a ^ q j d r Z b _ Z c d e ] d f [ f i Z _ _ d c d [ l € • q
Œ Œ
ƒ q ] f
Y d c Z ] Y Z b _ Z c d e ] d f [ ] `
h
j Z ` e e Z ^ ^ c Z j ` o m
X f ` i f d c ] Y d ^ d [ e _ Z ` ^ Z d [ ] Y Z p Z ] e Y Z [ l d [ Z
e f a b j Z \ d ] o q
u
Z b _ f b f ^ Z ] f g ^ Z j f [ l d [ ^ ] _ g e ] d f [
^ ] _ Z ` a ^ €  q ‚ ƒ ` ^
h
` ^ d e b _ Z c d e ] d f [ g [ d ] q
u
Y d e Y
a ` r Z ^ d ] b f ^ ^ d
h
j Z ] f Y d c Z ] Y Z b _ Z c d e ] d f [ ] `
h
j Z
` e e Z ^ ^ c Z j ` o m t p d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^ ` _ Z j f [ l
Z [ f g l Y q ] Y Z Z \ Z e g ] d f [ Z [ l d [ Z e ` [
h
Z r Z b ]
h
g ^ o
Z \ Z e g ] d [ l d [ ^ ] _ g e ] d f [ ^ p _ f a ` ^ ] _ Z ` a c g _ d [ l
a g j ] d b j Z e o e j Z ^ q
u
Y d j Z ` [ Z
u
^ ] _ Z ` a b _ Z c d e ] d f [
d ^
h
Z d [ l l Z [ Z _ ` ] Z c m v Z ] ` r Z a ` \ d a g a ` c i ` [ s
] ` l Z f p ] Y d ^ p ` e ] g ^ d [ l ] Y Z a g j ] d b j Z ^ ] _ Z ` a b _ Z s
c d e ] f _ q ` [ f i Z j b _ Z c d e ] f _ c Z ^ d l [ ] Y ` ] e f a
h
d [ Z ^
p _ Z k g Z [ ] j o Z \ Z e g ] Z c d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^ d [ ] f
j f [ l i d _ ] g ` j ^ ] _ Z ` a ^ m  g _ b _ Z c d e ] f _ b _ f i d c Z ^
d [ ^ ] _ g e ] d f [ ^ ] _ Z ` a ^ j f [ l Z [ f g l Y p f _ ` j j f
u
d [ l `
b _ f e Z ^ ^ f _ [ f ] g ^ d [ l f i Z _ _ d c d [ l ] f ` e Y d Z i Z ` b Z _ s
p f _ a ` [ e Z e j f ^ Z ] f ` b _ f e Z ^ ^ f _ g ^ d [ l b _ Z c d e ] d f [
f i Z _ _ d c d [ l q ] Y ` ] d ^ q
u
Z ` e Y d Z i Z ` i Z _ o ^ d a d j ` _
b Z _ p f _ a ` [ e Z ` ] ` a g e Y j f
u
Z _ e f a b j Z \ d ] o q ` j ^ f
_ Z k g d _ d [ l j Z ^ ^ Z [ Z _ l o e f [ ^ g a b ] d f [ m
Q W ^
y
z _ ¡
Ÿ
{ ¤
Ÿ
 
Ÿ y
T S
X Y d ^
u
f _ r Y ` ^
h
Z Z [ ^ g b b f _ ] Z c
h
o ] Y Z [ d [ s
d ^ ] _ o f p n c g e ` ] d f [ f p
—
b ` d [ g [ c Z _ e f [ ] _ ` e ]
X t ’ ` §
š š
þ `
š
  • ‚ ` ™
š
§ `
š Œ
q ] Y Z ~ d
¦
n
”
™ n g _ f s
b Z ` [ ’ Z ]
u
f _ r f p n \ e Z j j Z [ e Z q ] Y Z ™ n
¦
‘
”
q ] Y Z
‘ ` _ e Z j f [ `
—
g b Z _ e f a b g ] d [ l ™ Z [ ] Z _ q ` [ c ` [ t [ s
] Z j p Z j j f
u
^ Y d b m
XVI Jornadas de Paralelismo, JP '2005 9
a
Ÿ
S
Ÿ
U
Ÿ y
W
Ÿ
S
€
Œ
ƒ û m
”
l ` _
u
` j q [ m
—
m ~ _ d ^ Y d r Z ^ Y q
—
m v m
 Z e r j Z _ q ` [ c # m ‘ g _ l Z _ m ™ j f e r _ ` ] Z i Z _ s
^ g ^ t
¦
™
ú
X Y Z Z [ c f p ] Y Z _ f ` c p f _ e f [ i Z [ s
] d f [ ` j a d e _ f ` _ e Y d ] Z e ] g _ Z ^ m t [ b © c ® ª ª d  ­ e f
c
«
g ª h i g j ­ ª © ­
 c ­
k l m n o c f  p n c ­
q
c n o p ª © r © ® g  ª ® p © ª q §
š š š
m
€ § ƒ  m s ` e f
h
^ f [ q n m t f ] Z [
h
Z _ l q ` [ c s m n m
—
a d ] Y m
¦
` ] Y s
h
` ^ Z c [ Z \ ] ] _ ` e Z b _ Z c d e ] d f [ m
t [ b © c ® ª ª d  ­ e f c
«
g ª u v g j ­ ª © ­
 c ­
k
l m n o c f  p n c ­ w  ® © c
© ® g  ª ® p © ª q
Œ
‚ ‚  m
€ • ƒ # m
”
m s d a Z [ Z ˜ q
—
m v m  Z e r j Z _ q ` [ c ™ m  d [ m
X Y Z d a b ` e ] f p c Z j ` o f [ ] Y Z c Z ^ d l [ f p
h
_ ` [ e Y b _ Z c d e ] f _ ^ m t [ b © c ® ª ª d  ­ e f c
«
g ª u u © d j ­ ª © ­
 c ­
k l m n o c f  p n c ­ w 
¬
® © c
© ® g  ª ® p © ª q §
š š š
m
€ þ ƒ # m
”
m s d a Z [ Z ˜ ` [ c ™ m  d [ m # o [ ` a d e
h
_ ` [ e Y b _ Z c d e ] d f [
u
d ] Y b Z _ e Z b ] _ f [ ^ m t [
b © c ® ª ª d  ­ e f c
«
g ª i g j ­ ª © ­
 c ­
k
q
c ­
¬
«
ª © ª ­ ® ª c ­ x  e g b ª ©
«
c © n
­ ® ª
q
c n o p ª ©
r © ® g  ª ® p © ª q §
š š Œ
m
€  ƒ
”
m t ` a d _ Z ˜ q  m s m
—
` [ ] ` [ ` q s m  m  ` _ _ d
h
` s
¦
Z o q ` [ c [ m û ` j Z _ f m ‹ Z ] e Y d [ l d [ ^ ] _ g e ] d f [
^ ] _ Z ` a ^ m t [ b © c ® ª ª d  ­ e f c
«
g ª u y g j ­
¬
ª © ­
 c ­
k l m n o c f  p n c ­ w  ® © c
© ® g  ª ®
¬
p © ª q §
š š
§ m
€ ÿ ƒ $ m t Z d [ a ` [ q X m
”
g ^ ] d [ q ` [ c ‘ m ™ ` j c Z _ m
”
^ e ` j `
h
j Z p _ f [ ] s Z [ c ` _ e Y d ] Z e ] g _ Z p f _ p ` ^ ]
d [ ^ ] _ g e ] d f [ c Z j d i Z _ o m t [ b © c ® ª ª d  ­ e f c
«
g ª
h z g j ­ ª © ­
 c ­
k l m n o c f  p n c ­
q
c n
¬
o p ª © r © ® g  ª ® p © ª q
Œ
‚ ‚ ‚ m
€  ƒ t m t f ^ [ Z _ q
”
m [ Z [ c Z j ^ f [ q ` [ c t m t f s
[ Z [ m ‹ d j ] Z _ d [ l ] Z e Y [ d k g Z ^ ] f d a b _ f i Z ] _ ` e Z
e ` e Y Z Z { e d Z [ e o m t [ b © c ® ª ª d  ­ e f c
«
g ª | v g
j ­ ª © ­
 c ­
k
q
c ­
«
ª © ª ­ ® ª c ­ b
©
k k ª k r ©
¬
® g  ª ® p © ª f
­ d
q
c n o  k
 c ­ } ª ® g ­  ~ p ª f q
§
š š Œ
m
€ ü ƒ n m t f ] Z [
h
Z _ l q
—
m ‘ Z [ [ Z ] ] q ` [ c s m n m
—
a d ] Y m
”
] _ ` e Z e ` e Y Z a d e _ f ` _ e Y d ] Z e ] g _ Z
` [ c Z i
` j g ` ] d f [ m j    } ©
­ f
®  c ­ f c ­
q
c n o p ª © f q þ ü  §  q
Œ
‚ ‚ ‚ m
€ ‚ ƒ  m s m
—
` [ ] ` [ ` q
”
m t ` a d _ Z ˜ q s m  m  ` _ _ d
h
` s
¦
Z o q ` [ c [ m û ` j Z _ f m
”
j f
u
s e f a b j Z \ d ] o
p Z ] e Y ` _ e Y d ] Z e ] g _ Z p f _ Y d l Y s b Z _ p f _ a ` [ e Z
^ g b Z _ ^ e ` j ` _ b _ f e Z ^ ^ f _ ^ m r
q
w } ©
­ f
®
¬
 c ­ f c ­ r © ® g  ª ® p © ª
­ d
q
c d ª € o  n  

¬
 c ­ q
Œ
 §  q §
š š
þ m
€
Œ š
ƒ  m s m
—
` [ ] ` [ ` q
”
m t ` a d _ Z ˜ q ` [ c
[ m û ` j Z _ f m  ` ] Z [ e o ] f j Z _ ` [ ]
h
_ ` [ e Y
b _ Z c d e ] f _ ^ m t [ b © c ® ª ª d  ­ e f c
«
g ª j ­
¬
ª © ­
 c ­
k ‚ c © ƒ f g c o c ­ j ­ ­ c „
 „ ª
r © ® g  ª ® p © ª
«
c © … p p © ª † ª ­ ª ©
 c ­ x  e g
¬
b ª ©
«
c © n
­ ® ª b © c ® ª f f c © f
­ d l m f ª n f q
§
š š
• m
€
Œ Œ
ƒ
”
m
—
Z ˜ [ Z e q
—
m ‹ Z j d \ q û m  _ d ^ Y [ ` [ q ` [ c
‡ m
—
` ˜ Z d c Z ^ m # Z ^ d l [ ] _ ` c Z f – ^ p f _ ] Y Z
”
j b Y ` n û ü e f [ c d ] d f [ ` j
h
_ ` [ e Y b _ Z c d e s
] f _ m t [ b © c ® ª ª d  ­ e f c
«
g ª h ˆ g j ­ ª © ­

¬
 c ­
k l m n o c f  p n c ­
q
c n o p ª © r © ® g  ª ®
¬
p © ª q §
š š
§ m
€
Œ
§ ƒ X m
—
Y Z _
u
f f c q n m
¦
Z _ Z j a ` [ q ` [ c
‘ m ™ ` j c Z _ m ‘ ` ^ d e
h
j f e r c d ^ ] _ d
h
g ] d f [
` [ ` j o ^ d ^ ] f Ž [ c b Z _ d f c d e
h
Z Y ` i d f _ ` [ c
^ d a g j ` ] d f [ b f d [ ] ^ d [ ` b b j d e ` ] d f [ ^ m t [
b © c ® ª ª d  ­ e f c
«
g ª | v g j ­ ª © ­
 c ­
k
q
c ­
«
ª © ª ­ ® ª c ­ b
©
k k ª k r © ® g  ª ® p © ª f
­ d
q
c n o  k
 c ­ } ª ® g ­  ~ p ª f q §
š š Œ
m
€
Œ
• ƒ
¦
m
—
Y d i ` r g a ` _ ` [ c ’ m
¦
m s f g b b d m ™
”
™ X t
• m
š ú
` [ d [ ] Z l _ ` ] Z c e ` e Y Z ] d a d [ l q b f
u
Z _
` [ c ` _ Z ` a f c Z j m X Z e Y [ d e ` j t Z b f _ ]
§
š š Œ
 § q v Z ^ ] Z _ [ t Z ^ Z ` _ e Y  `
h
f _ ` ] f _ o q
§
š š Œ
m
10 Arquitectura del Procesador y Multiprocesadores
Eficacia vs. Eficiencia: Una Decisión de Diseño en RunAhead
Tanausú Ramírez, Adrián Cristal, Oliverio J. Santana, Alex Pajuelo y Mateo Valero
Departamento de Arquitectura de Computadores
UPC – Barcelona
{tramirez, adrian, osantana, mpajuelo, mateo}@ac.upc.edu
Resumen
Existe una gran diversidad de técnicas que
incrementan el rendimiento de las aplicaciones al
aliviar uno o varios de los problemas más
importantes de los procesadores actuales. Por
desgracia, muchas veces se descuida el estudio de
los posibles efectos colaterales que pueden causar
que los diseñadores de un procesador real decidan
no implementar un determinado mecanismo.
En este artículo presentamos, como caso
práctico, el análisis de los efectos colaterales
causados por un mecanismo ampliamente
conocido: RunAhead. Nuestra evaluación muestra
que RunAhead es eficaz incrementando el
rendimiento de aplicaciones en procesadores
superescalares (12% para SpecINT). Sin embargo,
lo hace de forma ineficiente, puesto que consume
4 veces más energía por instrucción retirada
comparado con un procesador superescalar sin
este mecanismo.
1. Introducción
Los procesadores superescalares actuales
presentan dos problemas graves que limitan el
rendimiento de las aplicaciones que ejecutan: la
predicción de saltos y la larga latencia de las
instrucciones que acceden a memoria para obtener
datos.
El primero de estos problemas reduce la
posibilidad de obtener suficientes instrucciones
del programa para llenar grandes ventanas de
instrucciones, especialmente en presencia de
saltos difíciles de predecir, y por tanto, reduce el
paralelismo a nivel de instrucción.
El segundo problema, conocido como memory
wall [19], se debe a la disparidad de aumento de
frecuencia entre el procesador y la memoria. Esto
hace que las instrucciones de acceso a memoria
cada vez presenten latencias más y más largas,
reduciendo considerablemente la posible
explotación del paralelismo a nivel de datos
presente en las aplicaciones. Si a esto le unimos la
naturaleza en orden de la etapa de commit de un
procesador superescalar, la situación se agrava
todavía más. Las instrucciones de larga latencia
retardan el commit de las instrucciones
posteriores, provocando que, antes o después, la
ventana de instrucciones se llene completamente,
lo que causará el bloqueo de la búsqueda,
decodificación y ejecución de nuevas
instrucciones, penalizando gravemente el
rendimiento.
Se han propuesto muchas técnicas para aliviar
estos problemas, y por tanto, incrementar el
rendimiento global de un procesador superescalar.
Pero muchas veces, en estas propuestas, no se
tiene en cuenta que atacar estos problemas
mediante mecanismos agresivos puede llevar a
que, dependiendo del escenario, una idea sea
inimplementable. Como claro ejemplo de esto, se
puede citar algunas técnicas que utilizan ejecución
especulativa. Estas técnicas se basan en ejecutar,
de forma especulativa, muchas más instrucciones
de las estrictamente necesarias, con el objetivo de
adelantar la obtención de datos críticos. Estas
instrucciones, por supuesto, consumen energía en
su ejecución, lo cual incrementa los requisitos de
energía de un procesador en el que se aplique un
mecanismo especulativo.
En este artículo se plantea la pregunta de si es
justificable o no este aumento de consumo para
obtener lo que a veces es un incremento marginal
del rendimiento. Para ello, hemos elegido como
caso de estudio un mecanismo ampliamente
conocido: RunAhead. Este mecanismo se basa en
ejecutar especulativamente las instrucciones
independientes de una instruccion de load con
larga latencia. Una vez este load es retirado, las
instrucciones ejecutadas de forma especulativa se
descartan, permaneciendo únicamente los cambios
que se hayan producido en la jerarquía de
memoria. De esta manera, RunAhead incrementa
eficazmente el rendimiento de ciertas aplicaciones
gracias a la prebúsqueda de datos. Por desgracia,
como efecto colateral se presenta el hecho de que
no es un mecanismo eficiente: para conseguir ese
incremento de rendimiento necesita consumir 4
veces más energía que un procesador superescalar
sin este mecanismo. Esto hace que RunAhead no
sea una buena alternativa en escenarios donde la
energía sea una limitación importante en el diseño
del procesador.
La estructura del resto de este artículo es la
siguiente. La Sección 2 resume el trabajo
realizado con anterioridad para aliviar el problema
de la latencia de memoria. La Sección 3 describe
el mecanismo de RunAhead. La metodología de
este estudio se encuentra en la Sección 4. La
Sección 5 evalúa RunAhead en términos de
rendimiento y eficiencia. Finalmente, la Sección 6
presenta nuestras conclusiones.
2. Trabajo relacionado
La técnica más utilizada para reducir los
tiempos de acceso a memoria es la incorporación ,
en el procesador, de pequeñas memorias con un
tiempo de acceso reducido, conocidas como
caches [3,12], que se basan en explotar la
localidad espacial y temporal de los datos. Su
principal inconveniente es que, si su tamaño no es
elegido cuidadosamente, podrían llegar a provocar
penalizaciones en el tiempo de ciclo del
procesador.
Desde otro punto de vista, los mecanismos de
prebúsqueda predicen la siguiente dirección
efectiva de una instrucción de acceso a memoria
para anticipar el acceso a sus datos. Estas técnicas
pueden clasificarse en diversas categorías. Las
técnicas de prebúsqueda software [6,17] están
basadas en introducir instrucciones de
prebúsqueda en tiempo de compilación. Por otro
lado, las técnicas de prebúsqueda hardware
[7,13,18] calculan las futuras direcciones efectivas
a las que puede acceder una instrucción
estudiando la historia de las ejecuciones previas
de esta instrucción.
Existen técnicas basadas en el uso de varios
contextos de ejecución o threads [5,9,11], como
los assisted-threads y helper threads que utilizan
un thread auxiliar para ejecutar secuencias de
código que realicen prebúsqueda, ayudando al
thread principal.
Por desgracia, existe el riesgo de que un mal
comportamiento de este mecanismo resulte
perjudicial, puesto que puede saturar el bus de
memoria accediendo a datos que no se van a
utilizar y, además, puede polucionar las caches del
procesador, causando más accesos a memoria al
reemplazar datos muy accedidos.
Trabajos recientes han propuesto nuevas
arquitecturas para aliviar el memory wall
alargando, virtualmente, la ventana de
instrucciones. Lebeck y otros [4] propusieron el
Waiting Instruction Buffer (WIB). Cuando se
encuentra un load de larga latencia, dicha
instrucción y sus correspondientes dependientes
son extraídas de la ventana de instrucciones y
ubicadas en el WIB hasta que se complete el
acceso a memoria. De esta forma se liberan
recursos que pueden ser utilizados por
instrucciones independientes de los loads de larga
latencia. Sin embargo, esta técnica necesita
incrementar el número de registros del procesador
para conseguir un rendimiento competitivo.
Los kilo-instruction processors [1] ocultan las
latencias de memoria largas manteniendo miles de
instrucciones en vuelo sin tener que incrementar
las estructuras del procesador más allá de un
tamaño razonable. Para ello, utilizan múltiples
checkpoints para permitir que las instrucciones
puedan retirarse del procesador fuera de orden y,
al mismo tiempo, manejar de forma inteligente el
resto de estructuras del procesador.
Con filosofía similar, la arquitectura
Continual Flow Pipelines [16] propone un diseño
sobre CPR [10] con estructuras escalables y multi-
checkpoint para ejecutar instrucciones
independientes de un load de larga latencia,
guardando las instrucciones dependientes en una
estructura auxiliar.
3. Caso de estudio: RunAhead
El mecanismo de RunAhead fue propuesto por
primera vez por Dundas y Mudge [8] para mejorar
el rendimiento de la cache de datos en un
procesador en orden. Posteriormente, Mutlu y
otros [14] lo adaptaron a procesadores con
ejecución fuera de orden para aliviar el problema
causado por las instrucciones de acceso a memoria
con latencias largas.
12 Arquitectura del Procesador y Multiprocesadores
La idea básica de RunAhead es realizar una
ejecución especulativa de las instrucciones
independientes a un load de larga latencia que,
potencialmente, pueda bloquear el procesador
debido a la falta de entradas en el reorder buffer.
Su funcionamiento es bastante simple. En el
momento que un load llega a ser la instrucción
más antigua de la ventana de instrucciones, se
realiza un checkpoint del estado actual del
procesador para, posteriormente, una vez que los
datos del load estén disponibles, recuperar el
estado correcto del procesador. En este checkpoint
se guarda el mapeo entre registros físicos y
lógicos, el registro de historia del predictor de
saltos, la Return Address Stack y la dirección de la
instrucción de load. A continuación, el load de
larga latencia se extrae de la ventana de
instrucciones y su registro destino se marca como
inválido, En este punto, el procesador entra en
modo RunAhead.
En este modo, las instrucciones que son
dependientes del load de larga latencia se eliminan
del procesador. Para conocer qué instrucciones
son dependientes de ese load, se modifica la tabla
de renombramiento de registros, extendiendo cada
entrada con un bit llamado INV. Las instrucciones
propagan el valor del bit INV a su operando
destino, haciendo un OR lógico con el valor de
este bit correspondiente a sus operandos fuente.
Las instrucciones que tengan un operando fuente,
o ambos, con el valor INV, son eliminadas. De
esta forma, se consigue impedir la ejecución de
toda la cadena de dependencias del load que causó
la entrada en modo RunAhead.
Para permitir que la ventana de instrucciones
avance todavía más, también se eliminan las
instrucciones con latencias largas junto con sus
instrucciones dependientes. El resto de
instrucciones son ejecutadas de forma
especulativa. Es necesario resaltar que la mayor
diferencia entre la ejecución especulativa y la no
especulativa radica en que, en la primera, las
instrucciones de store no modifican el contenido
de la memoria.
En el momento que los datos del load de larga
latencia están disponibles, el procesador sale del
modo RunAhead. Para esto se restaura el estado
del procesador en la instrucción de load que
desencadenó el modo RunAhead, utilizando el
checkpoint creado a tal efecto, y se descartan
todas las instrucciones que se han ejecutado en ese
modo.
Hay que tener en cuenta que, en realidad, no
se elimina todo el trabajo realizado durante el
modo RunAhead: los accesos a memoria
realizados por las instrucciones de load se
mantienen. Gracias a esto, durante el modo
RunAhead se realiza prebúsqueda de datos para
las instrucciones de load de larga latencia,
incrementando el rendimiento del procesador.
Una gran ventaja de RunAhead frente a
mecanismos clásicos de prebúsqueda es que
consigue, mediante esta ejecución especulativa,
adelantar los datos para cadenas dependientes de
loads. Esta diferencia es notable en códigos donde
se recorren listas enlazadas o estructuras de
árboles.
No obstante, la principal ventaja de este
mecanismo es que puede ser implementado con
una pequeña cantidad de hardware adicional. Lo
primero y más importante es incorporar el sistema
de checkpointing para guardar la información
necesaria para restaurar el estado del procesador.
El tipo concreto de checkpoint dependerá de la
microarquitectura del procesador. Por otro lado,
también hace falta un mecanismo que impida a las
instrucciones de store actualizar la memoria en
commit durante el modo RunAhead. Para tal fin se
puede utilizar un pequeño buffer que mantenga el
estado de los stores, y a su vez permita
proporcionar los datos correspondientes a los
loads que aparezcan posteriormente en modo
RunAhead. Los stores que fallan en el segundo
nivel de cache, en modo RunAhead, se convierten
en loads, es decir, se accede a la memoria para
prebuscar datos, pero no los modifican. Por
último, hace falta añadir el bit de invalidez (INV)
a la tabla de renombrado que permita identificar
cuando un registro es válido o inválido.
4. Metodología
Para la obtención de resultados hemos usado
el simulador SMTsim, [20] para modelar un
procesador con ejecución fuera de orden. El
simulador incluye un sistema de memoria
detallado, modelando aspectos importantes como
las latencias de cache, contención del bus,
conflictos entre bancos y retardos en la emisión de
las peticiones de memoria.
XVI Jornadas de Paralelismo, JP '2005 13
El mecanismo de RunAhead ha sido
implementado siguiendo [14]. La principal
diferencia es que no incorporamos, en este
estudio, ningún mecanismo de prebúsqueda
hardware. De esta forma conseguimos aislar los
beneficios del mecanismo de RunAhead.
La Tabla 1 muestra los parámetros de
configuración del procesador para la
configuración base. Algunos de estos parámetros
se modificarán durante la evaluación.
Parámetros Configuración base
Fetch Width 4
Funcional Units 6 INT / 3 FP/ 4 LD/ST
Registers 128 INT / 128 FP
ROB size 128
Issue Queues (IQ,FP,LQ) 32
Branch Predictor Gshare (2K) + BTB (1K)
Memory System
L1 Icache 64KB/2-way 64byte, 1 ciclo
L1 Dcache 64KB/2-way 64byte, 3 ciclos
L2 Cache 512KB/4-way 64byte, 10 ciclos
Mem Latency 500 ciclos
MSHRs 16
Tabla 1. Parámetros de configuración
Todos los experimentos fueron realizados
utilizando los benchmarks de SPEC 2000
compilados con el compilador de Compaq/Alpha
con todas las optimizaciones activadas. Para cada
Spec se simularon 300 millones de instrucciones
de una parte significativa del programa [2].
5. Evaluación
En esta sección mostraremos primero, cuan eficaz
es el mecanismo de RunAhead incrementando el
rendimiento y, en segundo lugar, su eficiencia
ejecutando instrucciones.
5.1. Rendimiento
En las Figuras 1 y 2 se muestra el rendimiento
(IPC) y el porcentaje de mejora para los
programas SpecINT y SpecFP respectivamente,
con los parámetros de la Tabla 1. Para cada Spec
se muestra el IPC del procesador superscalar
(baseline), del procesador superescalar con
RunAhead (RA) y el procesador superescalar con
memoria perfecta (bound), es decir, un procesador
con una cache de nivel 2 con capacidad infinita,
que utilizamos para mostrar el límite de la
ganancia alcanzable.
Figura 1. Rendimiento de RunAhead y SpeedUp
para los programas SPEC INT 2000
En la Figura 1 se puede observar como la
mejora en rendimiento con RunAhead no es muy
significativa para SpecINT, aproximadamente 8%,
excepto para los programas twolf (30%) y vpr
(28%). Esto se debe a la gran cantidad de
instrucciones inválidas que se encuentran en modo
RunAhead (65%). Entre ellas, el 23% son loads,
lo cual resta oportunidades a RunAhead para
hacer prebúsqueda de valores.
La Figura 2 muestra los datos para los
programas SpecFP. En este caso, el incremento de
rendimiento obtenido es importante: 27%. Esto se
debe a que el rendimiento de este conjunto de
programas es más dependiente de la configuración
de memoria, puesto que tienen un porcentaje
mayor de fallos en L2 (36% y 62% para SpecINT
y SpecFP respectivamente)., lo cual hace que la
prebúsqueda de datos sea muy eficaz.
Figura 2. Rendimiento de RunAhead y SpeedUp
para benchmarks SPEC FP 2000
14 Arquitectura del Procesador y Multiprocesadores
5.2. Importancia de la ventana de instrucciones
y de la latencia de memoria
Dos parámetros a tener en cuenta en el mecanismo
de RunAhead son: el tamaño del reorder buffer y
la latencia de memoria.
El número de entradas del reorder buffer tiene
gran influencia en un procesador superescalar
puesto que limita el número de instrucciones que
se pueden mantener en vuelo durante un acceso de
larga latencia a memoria y, por tanto, la cantidad
de paralelismo a nivel de instrucción explotable.
Con respecto a RunAhead, cuantas más entradas
estén disponibles en el reorder buffer más se
retrasará la puesta en marcha del mecanismo, ya
que se tiene que esperar a que el load de larga
latencia sea la instrucción más antigua y el reorder
buffer esté lleno. Por otro lado, esto se puede ver
contrarrestado con el aumento de paralelismo a
nivel de instrucción, gracias a una ventana de
instrucciones mayor.
La latencia de acceso a memoria afecta
directamente al rendimiento de la configuración
base, puesto que el tiempo de bloqueo del
procesador es más largo al producirse un fallo de
L2. En cuanto a RunAhead, una mayor latencia
con memoria significa que estará mayor
porcentaje de ciclos activado y, por tanto, serán
ejecutadas más instrucciones en modo RunAhead.
La Figura 3 muestra el impacto del tamaño del
reorder buffer y de la latencia de memoria. Para
ello se muestran cuatro configuraciones: conf1 y
conf2 (ambas con 128 entradas en el reorder
buffer y 500 y 800 ciclos de latencia con memoria
respectivamente), así como conf3 y conf4 (con
256 entradas y 500 y 800 ciclos de memoria
respectivamente), en media y para SpecINT y
SpecFP. Los otros parámetros de configuración no
se han modificado respecto a los de la Tabla 1
excepto el tamaño de las colas de emisión, que
han sido escaladas en igual proporción que el
reorder buffer.
Como se puede ver en la Figura 3,
modificando el tamaño del reorder buffer de 128 a
256 entradas y manteniendo la latencia con
memoria (por un lado conf1 y conf3 con 500
ciclos y por el otro, conf2 y conf4, con 800 ciclos)
se obtiene un aumento del incremento del
rendimiento del 1,5% comparando conf1 y conf3
y 3% comparando conf2 y conf4. Esto es debido,
como se comentó previamente, por que, aunque en
la configuración con más entradas en el reorder
buffer, las veces que se activa el mecanismo de
RunAhead es menor (131.700 veces comparando
conf1 y conf3, y 138.200 veces comparando conf2
con conf4), el aumento del paralelismo
contrarresta el efecto (0,12 para conf1-conf3 y
0,09 para conf2-conf4 instrucciones por ciclo más
son emitidas).
Figura 3. SpeedUp para distintas configuraciones
de ROB y latencia de memoria
Por otro lado, manteniendo el número de
entradas en el reorder buffer y variando la latencia
de memoria de 500 a 800 ciclos el incremento de
rendimiento obtenido por RunAhead es 3,5%
comparando conf2 con conf1 y 5% comparando
conf4 con conf3. Esto se debe a que el mecanismo
está en funcionamiento un 3,8% más del tiempo
de ejecución para el primer caso y 4,2% para el
segundo.
La Figura 4 muestra el motivo por el cual
RunAhead es capaz de incrementar el
rendimiento: la prebúsqueda. Debido a la
limitación de espacio, solamente se muestran el
porcentaje de fallos en el segundo nivel de cache,
para la configuración conf3 (128 entradas del
ROB y la latencia de memoria de 800 ciclos).
Figura 4. Porcentaje de fallos en la cache L2
XVI Jornadas de Paralelismo, JP '2005 15
En la Figura 4 se demuestra que existe una
clara reducción en los accesos no especulativos a
memoria. Del 49% de accesos de larga latencia
que se ejecutan en el procesador superescalar sin
RunAhead, el 19% han sido correctamente
prebúscados en modo RunAhead.
5.3. Número de Instrucciones
Hasta este punto se ha presentado una evaluación
de la eficacia del mecanismo de RunAhead, con
diversas configuraciones de tamaño de reorder
buffer y de latencia de memoria, mostrando que
esta técnica incrementa, eficazmente, el
rendimiento de un procesador superescalar. En
esta sección se evalúa el número de instrucciones
extra que se tienen que ejecutar para alcanzar tales
incrementos en rendimiento y que serán la base
para calcular la eficiencia del mecanismo en la
siguiente sección.
Las Figuras 5 y 6 muestran el número de
instrucciones extra ejecutadas debido a fallos de
predicción de saltos (wrong path), y a la ejecución
especulativa en modo RunAhead (RA) con
respecto al total de instrucciones útiles ejecutadas
(useful), para la configuración con 256 entradas
en el reorder buffer y 800 ciclos de latencia de
memoria. Para SpecINT (Figura 5) se observa que
casi la mitad de instrucciones que se ejecutan, han
sido creadas en modo RunAhead: 45%.
Figura 5. Instrucciones extras en RA para SpecINT
Para SpecFP (Figura 6), el porcentaje de
instrucciones extra en modo RunAhead es
sensiblemente menor: 32%. La disparidad de
porcentajes entre SpecINT y SpecFP se debe a dos
motivos: el primero es el porcentaje de tiempo que
el procesador permanece en modo RunAhead
(46% para SpecINT y 58% para SpecFP). El
segundo motivo es el número de instrucciones
especulativas que se ejecutan por período de
RunAhead (2605 para SpecINT y 682 para
SpecFP). Aunque el número de veces que se entra
en modo RunAhead en SpecINT es sensiblemente
inferior comparado con SpecFP, siempre se llega
más lejos en la ventana de instrucciones en los
SpecINT que en los SpecFP, lo que hace que, en
proporción se ejecuten más instrucciones
especulativas para SpecINT que para SpecFP.
Figura 6. Instrucciones extras en RA para SpecFP.
En la Tabla 2 se muestra el número de
instrucciones totales buscadas durante la ejecución
normal (TotalFetch), el número total de
instrucciones buscadas durante la ejecución en
modo RA (FetchedRA), y de estas cuantas han
hecho commit (Pseudo-Commit). Como se puede
ver, el número de instrucciones tanto en modo
normal como en modo RunAhead es claramente
superior para SpecINT (3573 millones y 3011
millones) que para SpecFP (570 millones y 224
millones). De entre las instrucciones traídas en
modo RunAhead, 2408 millones (67%) llegan a
completar su ejecución en SpecINT. Para SpecFP,
solamente 108 millones (39%) de instrucciones
especulativas consiguen completarse. Esto se debe
a que las instrucciones de coma flotante tienen,
normalmente, una latencia mayor que las enteras,
lo que provoca una saturación mayor de las
unidades de coma flotante que puede causar que el
reorder buffer se llene totalmente.
Stat INT FP
TotalFetch 3.573.954.281 570.334.978
FetchedRA 3.011.686.360 224.325.965
Pseudo-commit 2.408.649.828 108.743.847
% Valid 35% 66%
% INV 65% 34%
Tabla 2. Estadísticas de instrucciones en RA
16 Arquitectura del Procesador y Multiprocesadores
Por último, la Tabla 2 también muestra el
porcentaje de instrucciones válidas (%Valid) y el
de instrucciones que son eliminadas del
procesador (%INV) por que dependen directa o
indirectamente del load que causó la entrada en
modo RunAhead. El porcentaje de instrucciones
válidas en SpecFP es del 66% mientras que para
enteros es del 35%. Este mayor porcentaje nos
indica que para SpecFP hay más posibilidades de
efectuar prebúsquedas válidas, puesto que se
consigue calcular más direcciones efectivas de
loads. Como consecuencia, se obtiene un mejor
beneficio de RA, y por tanto, una mayor ganancia
de rendimiento en SpecFP que en SpecINT.
5.4. Eficiencia
Por último, en esta sección evaluamos si el
mecanismo de RunAhead es eficiente ejecutando
instrucciones. Para medir la eficiencia de los
mecanismos, normalmente se utiliza la métrica
Energy-Delay2
[15] que relaciona el consumo de
un procesador con su rendimiento. En nuestro
caso, mediremos el consumo en número de
instrucciones ejecutadas. Aunque el consumo
depende de la clase de instrucción ejecutada
supondremos, para simplificar el estudio, que
todas las instrucciones consumen la misma
cantidad de energía.
Por otro lado, el retardo (delay2
) lo mediremos
en CPI2
medio. Por tanto, la fórmula que
emplearemos será:
ED2
=#Instrucciones-ejecutadas x CPI2
Mediante esta fórmula compararemos cuantas
unidades de energía se consumen por instrucción
ejecutada. De esta forma, nos dará una
aproximación de cuan eficiente, en términos de
energía y consumo, es un procesador con
RunAhead ejecutando instrucciones.
Las Figuras 7 y 8 muestran los valores de ED2
del mecanismo de RunAhead normalizados al
procesador superescalar sin este mecanismo para
una configuración con un reorder buffer de 256
entradas y 800 ciclos de latencia con memoria. En
estas Figuras los valores por encima de 1
significan que se consume más energía por
instrucción ejecutada que en la configuración
base.
Figura 7. Energy-Delay2
SpecINT
Para SpecINT se observa claramente que el
mecanismo es poco eficiente ejecutando
instrucciones. En media, se necesita 4 veces más
energía para ejecutar una instrucción en
comparación con la configuración base.
Figura 8. Energy-Delay2
SpecFP
Por el contrario, para los SpecFP, el
mecanismo es más eficiente, obteniendo 0,9 ED2
.
Esto significa que, en promedio, se necesita
consumir menos energía por instrucción retirada
en el procesador con el mecanismo de RunAhead
que sin este mecanismo.
Por tanto, en determinados escenarios,
RunAhead puede ser al mismo tiempo eficiente y
eficaz. Sin embargo, no hay que olvidar que
RunAhead está lejos de ser eficaz en otros
escenarios. Por tanto, la eficacia de esta técnica es
un dato muy importante que debe ser analizado y
tenido en cuenta por los diseñadores de
procesadores.
XVI Jornadas de Paralelismo, JP '2005 17
6. Conclusiones
El consumo de energía, una característica no
contemplada en la evaluación de muchos
mecanismos propuestos en la literatura, empieza a
ser, cada vez más, un factor limitante en los
procesadores actuales. Un incremento importante
en el rendimiento de las aplicaciones, no tiene por
qué justificar la inclusión de un mecanismo en el
diseño de un procesador, si esto conlleva un
incremento en el consumo de energía.
Como caso práctico, en este artículo, hemos
evaluado en términos de rendimiento y eficiencia
una técnica para aliviar el problema de las largas
latencias causada por los accesos a memoria:
RunAhead. Este mecanismo incrementa un 24% el
rendimiento de un procesador con 256 entradas en
el reorder buffer y 800 ciclos de latencia con
memoria, gracias a la prebúsqueda especulativa de
datos para instrucciones de larga latencia. Como
contrapartida, la ejecución de instrucciones
especulativas aumenta el consumo de energía del
procesador.
En el caso de SpecINT, para obtener un
incremento medio de rendimiento del 12% se
necesita aproximadamente 4 veces más energía
por instrucción que en el procesador sin este
mecanismo. Esto lleva a la conclusión de que el
rendimiento obtenido podría no ser justificable, en
función de las características y objetivos del
procesador, debido a la gran cantidad de
instrucciones extra que tienen que ser ejecutadas.
Agradecimientos
Este trabajo ha estado apoyado por el
Ministerio de Educación y Cultura de España bajo
el contrato TIN2004-07739-C02-01, la Red
Europea de Excelencia HiPEAC, y el BSC-Centro
Nacional de Supercomputación.
Referencias
[1] A. Cristal, D. Ortega, J. Llosa and Mateo Valeo.
Out-of-Order commit processors. HPCA-10,
Febrero 2004.
[2] A. Falcón et al. Selecting Where to Simulate
SPEC2000 using stream analysis. XV Jornadas de
Paralelismo, Almeria, España.
[3] Alan J. Smith. Cache Memories. ACM Computing
Surveys, Septiembre 1982.
[4] A. R. Lebeck et al. A large, fast instruction window
for tolerating cache misses. 29th
ISCA-2002.
[5] C-K Luk. Tolerating memory latency through
software-controlled pre-execution in simultaneous
multithreading processors. 28th
ISCA- 01.
[6] D. Callahan et al. Software prefetching. 4th
ASPLOS, 1991.
[7] D. Joseph and D. Grunwald. Prefetching using
Markov predictors. 24th
ISCA-97
[8] J. Dundas and T. Mudge. Improving data cache
performance by pre-executing instructions under a
cache miss. ICS, Julio 1997.
[9] J.D. Collins et al., “Dynamic Speculative
Precomputation”. 34th International Symposium on
Microarchitecture (Micro-34), 2001..
[10] H. Akkary, R. Rajwar and S.T. Srinivasan.
Checkpoint processing and recovery: Towards
scalable large instruction window processors.
MICRO-36, 2003.
[11] M. Dubois and Y. Song, Assisted Execution,
technical report CENG 98-25, Dept. EE-Systems,
Univ. Southern California, 1998.
[12] M. Wilkes. Slave memories and dynamic storage
allocation. IEEE Transactions on Electronic
Computers, 1965.
[13] Norman P. Jouppi. Improving direct-mapped cache
performance by the addition of small fully-
associative cache and prefeth buffers. (ISCA 90).
[14] O. Mutlu, J. Stark, C. Wilkerson and Y. Patt.
RunAhead execution: An alternative to very large
instruction windows for out-of order processors.
HPCA-09, Febrero 2003.
[15] R. Gonzalez and M. Horowitz, Energy Dissipation
in General Purpose Microprocessors, IEEE J.
Solid-State Circuits, Vol. 31, No. 9, Sept. 1996.
[16] S.T. Srinivasan et al. Continual Flow Pipelines.
ASPLOS, 2004.
[17] T.C. Mowry et al. Design and evaluation of a
compiler algorithm for prefetching. 5th
International,
ASPLOS 1992.
[18] T. Sherwood et al. Predictor-Directed Stream
Buffers. 33rd
ACM/IEEE International Symposium
on Microarchitecture, MICRO-00
[19] W.A. Wulf and S.A. McKee, Hitting the Memory
Wall: Implications of the Obvious. ACM SIGARCH
Computer Architecture News, vol. 23, no. 1, March
1995, pp. 20-24.
[20] D.M. Tullsen. Simulation and Modeling of a
Simultaneous Multithreading Processor.,
22nd Annual Computer Measurement Group
Conference, December, 1996
18 Arquitectura del Procesador y Multiprocesadores
A Per-Module Adaptive Fetch Mechanism
Daniel Chaver, M. A. Rojas, L. Pinuel, M. Prieto, F. Tirado
Dept. de Arquitectura de Computadores y Automática
Universidad Complutense de Madrid
Ciudad Universitaria
28040 Madrid
{dani02, miguel.rojas, lpinuel, mpmatias, ptirado}@dacya.ucm.es
Abstract
A highly-efficient fetch unit is essential not only
to obtain good performance but also to achieve
energy efficiency. However, existing designs are
inflexible and depending on program behavior,
can be either insufficient or an overkill. We
introduce a phase-based adaptive fetch mechanism
that can be dynamically adjusted based on
feedback information of the program behavior.
This design adds very little hardware complexity
and relegates complex tasks to the software
components. It is also very effective: saving
26.8% and 34.1% fetch energy on average
compared with a conventional and a trace cache-
based fetch unit, respectively. At the same time,
performance is improved by 5.7% and 0.6%,
respectively.
1. Introduction
Modern high-end processors rely on sophisticated
branch prediction and instruction fetch
mechanisms to achieve high performance and
energy efficiency. Without a constant, smooth
supply of instructions, the rest of the pipeline will
not only perform poorly, but also use energy
inefficiently. However, such sophisticated
mechanisms are not without cost and can account
for a significant fraction of energy consumption
(e.g., 22% in Pentium Pro).
A conventional fetch mechanism consists of
an instruction cache and a branch predictor
(including a direction predictor and a branch
target buffer). The most basic instruction fetch
mechanism can only supply a consecutive chunk
of instructions from a single cache line. If a
branch is predicted to be taken, the fetching of
target instructions is delayed to the next cycle.
This is referred to as SEQ1 [1]. A slightly more
aggressive variation of this conventional fetch
mechanism is to add the capability to fetch across
multiple branches. In such an implementation, a
multi-branch predictor is needed to provide n
predictions per cycle. For example, a SEQ3
scheme [1] can fetch across up to 3 branches,
provided all the targets remain in the same cache
line. We note that the additional complexity of
SEQ3 over SEQ1 is rather low: besides requiring
a multi-branch predictor, the hardware only needs
to “collapse” the fetched cache line to remove
instructions between the taken branches and their
respective targets.
Rotenberg et al. introduced the trace cache as
a promising solution to obtain a high bandwidth
instruction fetching with a very low latency [1].
The idea is to capture dynamic instruction
sequences in an additional cache that stores
traces. A trace is a sequence of at most n
instructions and at most m basic blocks, identified
by its starting address and m-1 branch outcomes.
Note that a multi-branch predictor is needed to
provide m-1 predictions per cycle. In a
conventional trace cache design (referred to as
CTC [2, 3]), the trace cache, the multi-branch
predictor, and the I-cache are accessed
simultaneously to reduce miss penalty when the
trace cache misses. In a Sequential Trace Cache
(STC) design [2, 3], instruction fetch is carried out
in two phases. The trace cache and branch
predictor are accessed first, and the I-cache is
accessed later, only upon a trace cache miss. At
the cost of longer latency when the trace cache
misses, this approach can reduce the energy
consumption due to unnecessary access of the I-
cache when the trace cache hits.
Given all these different fetch options, the best
strategy depends on the behavior of the program.
Intuitively, the best option is the one that balances
the front-end of the machine, which fetches the
instructions, and the execution engine, which
processes them. If the front-end can not keep up,
the execution will take longer than necessary and
this longer execution increases energy
* This work is supported by the Spanish Government grant TIC
2002-750 and by the HiPEAC European Network of Excellence
consumption due to clock distribution and other
overhead. Conversely, an overly aggressive front-
end can not further improve performance, and
thus its high energy expenditure becomes
unnecessary. Unfortunately, program behavior
varies not only across applications but also within
a single application. Hence, there is no fixed
configuration that always works efficiently. An
efficient system will be adaptive, selecting the
fetch policy that works best for the code currently
executing. Additionally, the size of various
structures, such as the trace cache and the branch
target buffer (BTB), also adjusts according to
program demand.,
In this work, our focus is to design such a
flexible fetch mechanism that can reduce energy
consumption and improve performance without
significantly increasing the design complexity.
We adopt the general principle of on-demand
resource allocation and propose a design that we
call Phase-Based Adaptive Fetch Mechanism
(PBAFM). In this scheme, the instruction fetch
unit is adjusted periodically, at the boundary of
phases to adapt to the changing program behavior.
A phase is a period of execution with predictable
behavior. In this paper, we use a simple strategy to
identify program phases. We follow prior work [6,
7] and statically divide an application into
modules. The dynamic execution of a static code
module is a natural candidate of a phase: prior
execution of a code module can be used to
accurately predict behavior of future instances.
Given the command to adapt, the hardware re-
orchestrates the fetch mechanism using a different
combination of the component structures.
Furthermore, using existing circuit techniques [4,
5], the size of these structures is also adjusted
according to the software command.
To simplify the design and reduce runtime
overhead, we use a feedback-based approach
relying on software components to identify
resource demand and make a decision on the
choice of configuration. The hardware, on the
other hand, only provides the primitives to carry
out the reconfiguration. We show that our
proposal is straightforward to implement and is
highly effective: it not only saves fetch energy by
26.8% and 34.1% compared to a conventional
fetch unit (SEQ1) and a trace cache-based fetch
unit respectively, it also improves the performance
of execution.
The rest of this paper is organized as follows.
We first discuss the rationale of our work in
Section 2. In Section 3 we explain our adaptive
fetch design. Section 4 describes the experimental
framework. Evaluation results are shown in
Section 5. Section 6 discusses related work.
Finally, Section 7 presents some conclusions.
2. Rationale
Intuitively, what fetch mechanism works well
depends on the application’s characteristics. When
the application exhibits high trace cache hit ratios,
an STC will avoid the unnecessary waste
accessing the I-cache in parallel and is thus more
efficient than the CTC. On the other hand, when
the application exhibits high trace cache miss
ratios, the CTC may be a better mechanism since
the STC incurs extra latency every time that the
trace cache misses.
Given the wide variety of general-purpose
applications, it is not surprising that there is no
single optimal fetch mechanism or configuration.
Figure 1 illustrates this point quantitatively. We
simulate the execution of several SPEC CPU 2000
applications (the details of the experimental
methodology will be described later in Section 4)
and show the energy-delay product of the
execution under different fetch policies and
configurations. Figure 1-(a) shows the energy-
delay product of a system using SEQ3 and CTC
fetch policy with different trace cache sizes. We
present normalized results using the energy-delay
product of a baseline system with a SEQ1 policy.
In Figure 1-(b) we vary the BTB size from 256
entries to 4096 entries and normalize the result to
that of a processor with a smaller BTB (128
entries).
From these results, we can make several
observations. First, different fetch mechanisms
work differently depending on the application. For
example, while SEQ3 works well for parser and
twolf, CTC is a better choice for gap and vortex.
Moreover, the optimal policy may depend on the
specific configuration. For example, with a trace
cache smaller than 64KB, CTC is the most
efficient mechanism for application gcc, however,
a bigger trace cache makes it less efficient than
SEQ3. Finally, configuration details such as BTB
size can also drastically affect the efficiency of
program execution.
20 Arquitectura del Procesador y Multiprocesadores
Figure 1. Energy-delay product of program execution under different fetch mechanisms and structure configurations.
Figure 1-(a) (left) shows the energy-delay product of SEQ3 and CTC with different trace cache sizes. The
results are normalized to SEQ1. Figure 1-(b) (right) shows the energy-delay product using different BTB
sizes. The results are normalized to a BTB with 128 entries.
From these observations, it is obvious that
fetch requirements vary significantly from
application to application. So, we propose an
adaptive fetch mechanism choosing among
different fetch schemes: SEQ1, SEQ3, CTC, and a
modified STC (the modification is explained in
Section 3.4).
The first two configurations avoid trace cache
access while the others make use of it. In some
cases when the branch misprediction rate is high,
using a trace cache is counterproductive, since it
executes many wrong path instructions, which
increases pollution in some structures like the
cache and increase energy consumption. In these
cases it may make sense to use a SEQ1 or a SEQ3
fetch policy. For the trace cache based schemes,
our adaptive mechanism has two possibilities. In
the first, CTC, the fetch unit accesses at the same
time to the trace cache, the I-cache, the multi-
branch predictor, and the BTB (in a similar way to
CTC [2, 3]). This configuration is useful when the
trace cache behaves well, but the I-cache still
provides a considerable amount of instructions.
The second configuration is a modified STC. In
those cases when trace cache provides almost all
instructions to the back-end, the fetch unit
virtually divides into two phases, like in [2] and
[3]. It accesses first the trace cache and the multi-
branch predictor, and then the I-cache and the
BTB – only when a trace cache miss occurs.
The adaptive fetch mechanism can also adjust
the size of some structures. Figure 1 suggests that
the optimal size for trace cache or BTB varies.
Consequently, our adaptive fetch mechanism
resizes these structures to the most appropriate
configuration.
3. Adaptive Fetch Mechanism
We intend to adapt the fetch policy and trace
cache and BTB sizes at the boundary of program
phases, where the behavior is about to change.
While the concept of program phases is simple at
an intuitive level – that the program goes through
different periods of execution with different
behavior, accurate and efficient phase detection
and behavior prediction for future phases are
challenging and are currently being investigated
by many research groups. In this paper, we use a
code-based approach [8] that is straightforward
and very effective in our design. We associate the
behavior of a period of execution with the static
code section that is being executed and use the
behavior of past instances of that section to
predict the behavior of future instances. While this
learning and prediction process can be performed
online, the need for any extra hardware for
prediction will not only complicate the hardware
but also consume energy, which will reduce the
benefit of adaptation. In this paper, we adopt an
offline approach for its simplicity and
effectiveness.
We first need to establish the phase
boundaries (Section 3.1). Once each phase is
identified, we use profile information to decide
what policy and structure sizes to use in each
phase. This information is then encoded into the
binary, so that at runtime, it instructs the hardware
to adapt. Sections 3.2 and 3.3 describe these steps.
0,7
0,8
0,9
1,0
1,1
1,2
gap bzip parser vortex twolf gzip gcc art
Energy*Delay
SEQ3
CTC_2KB
CTC_8KB
CTC_32KB
CTC_64KB
0,7
0,8
0,9
1,0
1,1
1,2
gap bzip parser vortex twolf gzip gcc art
Energy*Delay
BTB_256
BTB_512
BTB_1024
BTB_4096
XVI Jornadas de Paralelismo, JP '2005 21
Figure 2. Results for the different modules of gzip. Figure 2-(a) (left) illustrates IPC improvement of different schemes
over a SEQ1. Figure 2-(b) (right) shows energy savings over a SEQ1. A negative value implies performance
or energy loss in the given scheme compared to SEQ1.
3.1. Phase Detection
As mentioned above, we use a simple code-based
approach. We partition the code into modules
purely based on granularity. We want the modules
to be big enough to reduce overhead associated
with runtime adaptation and yet small enough to
have more consistent behavior. The technique
employed is the same to the one detailed in [6, 7].
3.2. Configuration Space Exploration
Our approach draws on profiling with reduced
inputs to determine each module’s demand. The
energy and performance metrics are collected by
means of software instrumentation, simulation or
by using hardware performance counters. A naive
implementation would exhaustively search the
space, covering all possible combinations of the
different module’s configurations. However this is
impractical because it would require nm
profiling
runs, where n is the number of possible processor
configurations and m is the number of modules.
We decrease the number of experiments
assuming that choosing a different configuration
for one module does not affect other modules.
Under this assumption, the number of experiments
in the profiling stage decreases to n*m,
significantly fewer than the naive solution. The
assumption ignores the effect of destructive or
constructive interference among different
modules. This interference tends to be secondary
unless the size of the trace cache becomes very
small. Given that we never go down to such small
sizes this effect is irrelevant in our study.
As an example, Figure 2 illustrates results for
a given application (gzip). Figure 2-(a) illustrates
the IPC improvement achieved in each module
using a SEQ3 and different CTC and STC
schemes over a SEQ1 baseline. Figure 2-(b)
shows the processor-wide energy savings
achieved for the same set of configurations,
compared again to the baseline SEQ1. We can see
that the energy savings can be quite dramatic in
certain modules, reaching more than 15%
processor-wide energy savings just by adapting
the fetch mechanism.
3.3. Decision Making for Adaptation
After per-module exploration, we have to obtain
the best configuration for each module, depending
on the energy and performance target. This is the
same as solving a knapsack problem [9]: the
tolerable performance degradation is the
knapsack's capacity while the total energy savings
is the value we want to maximize. As in [6], we
employ a greedy strategy to find an approximation
solution.
The knapsack algorithm adopts a global
approach in deciding the configurations to choose
for each module. We observe that a simpler
approach may also work. For some modules,
configurations are very easy to select just based
on local information of that module and would not
require the more global consideration. For
example, from Figure 2, for module 3 it is obvious
that an STC is the best approach to use, since it
obtains a very similar IPC as the others, but
achieves higher energy savings. On the other
-5
0
5
10
15
20
25
30
35
1 2 3 4 5 6 7
Modules
IPC
Improvement
(%)
SEQ3
CTC4KB,BTB4K
CTC32KB,BTB4K
CTC4KB,BTB1K
CTC32KB,BTB1K
STC4KB,BTB4K
STC32KB,BTB4K
-3
2
7
12
1 2 3 4 5 6 7
Modules
Energy
Savings
(%)
SEQ3
CTC4KB,BTB4K
CTC32KB,BTB4K
CTC4KB,BTB1K
CTC32KB,BTB1K
STC4KB,BTB4K
STC32KB,BTB4K
22 Arquitectura del Procesador y Multiprocesadores
Figure 3. Hardware Support.
hand, module 7 should adapt to a SEQ3
configuration, since any of the trace cache based
configurations behaves significantly poorer, due
to a high number of wrong path speculated
instructions.
3.4. Hardware Support
As mentioned above, we intend to adapt the fetch
unit to match the requirement of each application
phase. Our fetch unit can adopt any of the 4
different configurations that we consider (SEQ1,
SEQ3, CTC, and a modified STC). We modify the
STC originally proposed by Hu et al. [2, 3]. In our
design, the BTB is not accessed when the trace
cache hits. This can be done since our trace cache
directly provides the target address.
In addition to adapting to the best policy, trace
cache and BTB sizes can also be adapted. There
are several existing schemes for resizing caches
and circuitry to perform the resizing. In particular,
the associativity [4], the number of sets [5], or the
combination of the two can be adjusted
dynamically. The effectiveness of these schemes
depends on the particular cache structure
organization. In our case, dynamically varying the
number of sets of the baseline cache is more
effective than changing cache ways.
Figure 3 illustrates the design that we are
using. When the SEQ1 signal is set, trace cache
access is disabled, and just the first prediction bit
from the multi-branch predictor is used. When the
SEQ3 signal is set, trace cache access is disabled,
but the 3 prediction bits are used. When STC1 is
set (first phase of a modified STC configuration),
access to I-Cache and BTB is gated, while if STC2
is set (second phase of a modified STC
configuration), access to trace cache and multi-
branch predictor is gated.
4. Experimental Framework
We have evaluated our proposed adaptive fetch on
a simulated generic out-of-order processor, whose
main parameters are summarized in Table 1. As
the evaluation tool, we employ a modified version
of SimpleScalar [10], incorporating the Wattch
framework [11] to evaluate energy consumption.
16-issue out-of-order processor
120 integer and floating-point physical
registers
I-Queue and FP-Queue: 64 entries
Branch predictor: 2-level, 16K entries /
BTB: 4K entries
RAS: 32 entries / LSQ: 128 entries
L1 data cache: 64KB, 4-way, LRU,
latency: 1 cycle
L2 cache: 512KB, 4-way, LRU, latency: 6
cycle
L1 instruction cache: 64KB, 2-way, LRU,
latency: 1 cycle
Trace cache: 32KB, 2-way, LRU, latency:
1 cycle, partial matching
Memory access: 100 cycles
Table 1. Simulated Parameters
Resizable
T-Cache
I-Cache
Fetch_address
Resizable
BTB
Multi-BP
Hit Logic
1 or 3 prediction bits
TC-line
TC-line
Hit in TC?
IC-line
TC-next-Addr
BTB Logic
Next Address
Instructions
SEQ1
STC2
STC1
SEQ3
PC++
XVI Jornadas de Paralelismo, JP '2005 23
To evaluate our designs for different
applications, we select several benchmarks from
the SPEC CPU2000 suite. In selecting those
applications, we tried to cover the wider variety of
behaviour. We simulated each application to
completion, using the train input as our default
production input.
The trace cache we are simulating is accessed
by the least significant bits of the fetch address.
Each trace contains: a tag (most significant bits of
the address), 3 prediction bits, the number of
branches and of instructions that the trace
contains, a maximum of 16 instructions, and the
next instruction PC for a final taken branch. For
filling in the trace cache, there is a buffer that
stores every committed instruction, so that when a
trace is completed, it is stored into the trace cache
(at a maximum rate of one trace per cycle). The
trace cache we employ allows partial matching
[1]. We should highlight that this implementation
guarantees one cycle access to the trace cache, but
only allows one trace per fetch address.
Our baseline fetch unit uses a 32KB trace
cache, a 64KB I-cache, a 4K-entry BTB, and a 2-
level multi-branch predictor with 16K entries.
Both BTB and trace cache can be downsized to
smaller structures (BTB: 4K, 2K, 1K, 512, 256, or
128 entries; trace cache: 32KB, 16KB, 8KB, 4KB,
or 2KB).
The multi-branch predictor that we are using
is a two level gshare predictor with a golden BHR
[12] updated in the fetch stage.The main BHR and
PHT are updated in the decode stage.
5. Experimental Results
5.1. Energy Savings
Table 2 summarizes the energy savings in the
processor’s fetch unit of PBAFM over 4 different
non-adaptive designs (SEQ1, SEQ3, CTC-4KB,
and CTC-32KB), all of which employ a 4K-entry
BTB and a 64KB I-cache.
As can be noticed, the energy savings
achieved by PBAFM are significant both in
integer and floating-point applications. All the
adaptation mechanisms incorporated in PBAFM
contribute to this enhancement. Trace cache and
BTB resizing are useful in most cases, especially
in floating-point applications. In those modules
where trace cache performs poorly, it is disabled,
which results in significant energy savings. On the
other hand, in those modules where the trace
cache performs exceptionally well, the savings
come from the use of a modified STC, in which
BTB and I-cache are accessed only when the trace
cache misses.
As Table 3 illustrates, improvements in the
fetch unit translate into notable energy savings in
the whole processor. These savings are not only
due to the savings in the fetch unit. In those
modules where a less aggressive fetch policy is
used (especially SEQ1) an extra saving comes
from the mis-speculation reduction (mis-
speculation pollutes the branch predictor and
incurs extra energy executing wrong instructions).
In addition, for integer applications, improving
performance saves energy, mostly by cutting
down extra clock distribution energy.
Gap Bzip Parser Twolf Crafty
SEQ1 31% 49% 19% 22% 16%
SEQ3 26% 33% 19% 20% 15%
CTC-4KB 24% 36% 26% 26% 20%
CTC-32KB 26% 38% 35% 39% 31%
Vortex Gcc Gzip Vpr INT-Avg
SEQ1 32% 25% 23% 17% 26.0%
SEQ3 27% 21% 21% 15% 21.9%
CTC-4KB 26% 20% 21% 22% 24.6%
CTC-32KB 28% 20% 19% 34% 30.0%
Applu Art Mgrid Swim FP-Avg
SEQ1 33% 27% 22% 32% 28.5%
SEQ3 36% 29% 24% 34% 30.8%
CTC-4KB 40% 33% 30% 40% 35.8%
CTC-32KB 46% 41% 40% 46% 43.3%
Table 2. Fetch unit energy savings achieved by
PBAFM over 4 different non-adaptive
designs (SEQ1, SEQ3, CTC-4K, and CTC-
32K).
Gap Bzip Parser Twolf Crafty
SEQ1 5.8% 10.0% 3.1% 3.4% 5.8%
SEQ3 4.5% 5.4% 1.7% 2.0% 2.1%
CTC-4KB 3.1% 5.1% 3.8% 4.1% 4.3%
CTC-32KB 2.5% 6.1% 4.4% 4.8% 4.7%
Vortex Gcc Gzip Vpr INT-Avg
SEQ1 10.8% 6.9% 7.4% 3.9% 6.4%
SEQ3 4.6% 4.0% 4.9% 1.6% 3.4%
CTC-4KB 3.9% 2.9% 3.3% 2.2% 3.6%
CTC-32KB 3.9% 3.2% 3.5% 2.4% 3.9%
Applu Art Mgrid Swim FP-Avg
SEQ1 3.3% 3.9% 3.2% 3.8% 3.6%
SEQ3 2.9% 3.7% 3.0% 4.1% 3.4%
CTC-4KB 2.7% 2.7% 3.0% 4.3% 3.2%
CTC-32KB 2.6% 2.8% 2.8% 4.6% 3.2%
Table 3. Processor energy savings achieved by
PBAFM over 4 different non-adaptive
designs (SEQ1, SEQ3, CTC-4K, and CTC-
32K).
24 Arquitectura del Procesador y Multiprocesadores
5.2. Performance
Table 4 shows performance improvement
achieved when using a PBAFM compared to the 4
non-adaptive designs. A negative value means that
performance gets worse in our adaptive approach.
Using PBAFM, we obtain performance
improvements in most integer applications. Each
module employs an optimal fetch configuration,
which provides sufficient supply of instructions
and yet without using an overly aggressive policy
that can introduce many wrong-path instructions
and negatively impacting performance. Moreover,
in modules where a small trace cache or BTB is
sufficient, keeping the structure size small also
helps to reduce conflict in the disabled portion of
the structures, which indirectly benefits the
execution of other modules. For some modules of
the floating point applications, the trace cache is
simply not effective, so PBAFM ends up disabling
it in these cases. As can be seen from Table 4, the
performance implication is thus negligible.
Gap Bzip Parser Twolf Crafty
SEQ1 7.6% 16.1% 3.8% 2.3% 6.5%
SEQ3 3.5% 2.2% 0.3% 0.0% 0.7%
CTC-4KB 1.7% 0.7% 0.6% 1.1% 2.9%
CTC-32KB 1.1% 0.7% 0.6% 1.0% 2.9%
Vortex Gcc Gzip Vpr INT-Avg
SEQ1 17.3% 7.0% 8.8% 3.9% 8.1%
SEQ3 5.1% 4.3% 3.7% 0.2% 2.2%
CTC-4KB 1.5% 0.5% 0.9% 0.3% 1.1%
CTC-32KB 0.4% 0.5% 0.7% 0.3% 0.9%
Applu Art Mgrid Swim FP-Avg
SEQ1 0.3% 0.6% -0.1% -0.3% 0.1%
SEQ3 0.3% 0.3% -0.1% -0.3% 0.1%
CTC-4KB 0.0% 0.1% 0.0% -0.2% 0.0%
CTC-32KB 0.0% 0.1% 0.0% -0.3% 0.0%
Table 4. Performance improvement achieved by
PBAFM over 4 different non-adaptive
designs (SEQ1, SEQ3, CTC-4K, and CTC-
32K).
6. Related Work
Researchers have proposed other solutions to
improve the fetch unit management. Most of these
proposals include a trace cache structure in the
fetch stage, and our proposal can work on top of
these designs to further improve the fetch
mechanism.
In [2] and [3], Hu et al. propose two new
models for a fetch stage. The first model, which
they call Selective Trace Cache, uses compiler
and hardware support to control trace cache
lookup (avoided in the cases where trace cache
behaves poorly). This approach can achieve some
energy reduction in the fetch stage, but at the cost
of some performance loss, compared to a CTC. A
second approach proposed in this prior work is a
Direction Predictor based Trace Cache (DPTC).
In this case, the selection for the fetch unit
configuration is dynamic, eliminating the need for
recompilation and ISA modification. However,
this comes at the cost of some overhead. The
model can reduce energy consumption in the fetch
mechanism, but again with some performance loss
compared to CTC.
In [13], Buyuktosunoglu et al. introduce a
scheme based on a combination of fetch gating
and issue queue adaptation to jointly adapt the
fetch and issue stages so as to match the current
parallelism characteristics of the application.
In [14], Santana et al. propose software
techniques to reorganize the code so that the fetch
engine complexity can be reduced. In a similar
way, Ramirez et al. [15] also propose compiler
optimizations to improve the layout of
instructions.
In [16], Co and Skadron perform a set of fetch
engine area and associativity experiments as well
as a next trace predictor design space exploration.
In the broader domain of low-power design, some
researchers have proposed structure resizing for
achieving energy savings. In particular, the
associativity [4] or the number of sets [5] of a
cache can be adjusted dynamically to the most
convenient configuration. We have applied some
of these techniques to resize trace cache and BTB
when needed.
Finally, in our prior work, we demonstrated
the effectiveness of an adaptive design of the
branch prediction, including the direction
predictor and the BTB [6].
7. Conclusions
In this paper we have proposed PBAFM, a new
adaptive fetch mechanism that adjusts the
underlying hardware to meet the application’s
demands. Our design switches to less expensive
configurations when appropriate, resulting in
significant energy savings in the fetch unit. In
doing so, the performance is not compromised. In
XVI Jornadas de Paralelismo, JP '2005 25
fact, for integer applications, we even obtain
modest performance gain relative to a very
aggressive fetch unit. Comparing PBAFM with
the most aggressive fetch unit design studied (a
32KB CTC), energy consumption in the fetch unit
is reduced by 34.1% on average and the
performance is improved by 0.6%. The combined
effect is a 3.7% processor-wide energy reduction.
Compared to a baseline fetch unit (SEQ1),
PBAFM improves performance by 5.7%, while
saving 26.8% and 5.5% energy in the fetch unit
and the whole processor, respectively.
References
[1] E. Rotenberg, S. Bennett, and J. E. Smith.
Trace Cache: A low latency approach to high
bandwidth instruction fetching. International
Symposium on Microarchitecture.
November, 1996.
[2] J. S. Hu, N. Vijaykrishnan, M. J. Irwin, M.
Kandemir. Optimizing Power Efficiency in
Trace Cache Fetch Unit. Technical Report,
Department of Computer Science and
Engineering, Pennsylvania State University,
2003.
[3] J. S. Hu, N. Vijaykrishnan, M. J. Irwin, M.
Kandemir. Using Dynamic Branch Behavior
for Power-Efficient Instruction Fetch.
International Symposium on VLSI, February,
2003.
[4] D. H. Albonesi. Selective Cache Ways: On-
Demand Cache Resource Allocation. Journal
of Instruction-Level Parallelism, Vol. 2.
May, 2000.
[5] S. Yang, M. D. Powell, Babak Falsafi, K.
Roy, and T. N. Vijaykumar. An Integrated
Circuit/Architecture Approach to Reducing
Leakage in Deep-Submicron High-
Performance I-Caches. International
Symposium on High-Performance Computer
Architecture, January, 2001.
[6] M. C. Huang, D. Chaver, L. Pinuel, M.
Prieto, and F. Tirado. Customizing the
Branch Predictor to Reduce Complexity and
Energy Consumption. IEEE Micro 23(5):12-
25, September 2003.
[7] Wei Liu, and M. C. Huang. EXPERT:
Expedited Simulation Exploiting Program
Behavior Repetition. International
Conference on Supercomputing, June 2004.
[8] M. C. Huang, J. Renau, J. Torrellas.
Positional Adaptation of Processors:
Application to Energy Reduction.
International Symposium on Computer
Architecture, June 2003.
[9] T. Cormen, C. Leiserson, and R. Rivest.
Introduction to Algorithms. McGraw-Hill,
1989, pp. 333-336.
[10] T. Austin, E. Larson, and D. Ernst.
SimpleScalar: An Infrastructure for
Computer System Modeling. Computer,
35(2), February 2002.
[11] D. Brooks, V. Tiwari, and M. Martonosi.
Wattch: A Framework for Architectural-
Level Power Analysis and Optimizations.,
International Symposium on Computer
Architecture, July, 2001.
[12] T. Y. Yeh and Y. N. Patt. Alternative
Implementations of Two-Level Adaptive
Branch Prediction. International Symposium
on Computer Architecture, May, 1992.
[13] A. Buyuktosunoglu, T. Karkhanis, D. H.
Albonesi, and P. Bose. Energy Efficient Co-
Adaptive Instruction Fetch and Issue.
Computer Architecture News, Vol. 31. May,
2003.
[14] O. J. Santana, A. Ramirez, M. Valero.
Reducing Fetch Architecture Complexity
Using Procedure Inlining. INTERACT-8,
Madrid, Spain. February 2004.
[15] A. Ramirez, O. J. Santana, J. L. Larriba-Pey,
M. Valero. Fetching instruction streams.
International Symposium on
Microarchitecture, November, 2002.
[16] Michele Co and Kevin Skadron. Evaluating
the Energy Efficiency of Trace Caches.
Technical Report CS-2003-19, University of
Virginia, 2003.
26 Arquitectura del Procesador y Multiprocesadores
Gestión eficiente de la LSQ basada en mecanismos de filtrado
F. Castro1
, D. Chaver1
, L. Pinuel1
, M. Prieto1
, F. Tirado1*1
1
ArTeCS Group, Universidad Complutense de Madrid
fcastror@fis.ucm.es
{dani02, mpmatias, ptirado, lpinuel}@dacya.ucm.es
1
* Este trabajo ha sido financiado en parte por el
proyecto TIC 2002-0750 y en parte por el HiPEAC
European Network of Excellence
Resumen
Los procesadores superescalares emplean
grandes colas de loads y stores (LQ-SQ) para
tolerar la creciente brecha entre la velocidad de
procesamiento y el acceso a memoria. En este
artículo hemos tratado el diseño de este
componente crítico, cuya implementación se ha
convertido en un importante desafío.
Basándonos en investigaciones previas sobre el
LQ-SQ state filtering hemos propuesto una LQ-
SQ alternativa. Los experimentos realizados
señalan que un adecuado particionamiento de la
LQ, guiado por un predictor de dependencias
basado en profiling, consigue reducir el
consumo de energía sin incurrir en
penalizaciones de rendimiento significativas.
1. Introducción
Los microprocesadores modernos tratan de
mitigar el problema de la latencia de memoria
incorporando sofisticadas técnicas para permitir
la ejecución adelantada de loads sin afectar a la
correcta ejecución del programa.
Los diseños convencionales incluyen
técnicas tales como el load bypassing y el load
forwarding. Las implementaciones más
agresivas van un paso más allá y permiten la
ejecución especulativa de loads cuando la
dirección efectiva de algún store precedente no
está resuelta todavía. Dicha ejecución
especulativa puede ser prematura si un store
anterior al load en el orden del programa se
solapa con éste y se ejecuta después. Cuando se
ejecuta el store el procesador necesita detectar y
reejecutar esta clase de loads. Todas las
instrucciones posteriores al load, o al menos las
dependientes de ésta, precisan ser reejecutadas
también. Esto es lo que se conoce como load-
store replay [8]. Para suavizar el impacto sobre
el rendimiento de tales reejecuciones, algunos
diseños incorporan mecanismos de predicción
para controlar dicha especulación [5]. Un
ejemplo comercial de esta técnica se puede
encontrar en el Alpha 21264 [8] (y en su
siguiente generación, Alpha 21364). El
procesador usa una simple tabla de 1 bit
indexada por PC para predecir si un load será
dependiente con algún store previo o no. Los
loads predichos como independientes se
ejecutarán tan pronto como sus direcciones
efectivas se encuentren disponibles, mientras
que los otros loads esperan hasta que se
resuelvan todos sus stores precedentes.
Los modernos procesadores con soporte para
sistemas multiprocesador, como el Itanium de
Intel o el POWER 4 de IBM, también incluyen
soporte para la consistencia de memoria en
sistemas multiprocesador de memoria
compartida [14], lo cual convierte en más
complejo todavía el sistema de memoria.
Estos complejos mecanismos tienen como
contrapartida un elevado consumo de energía.
Además, se espera que este consumo se
incremente más en futuros diseños, ya que las
estructuras de almacenamiento de loads y stores
“in flight” (LQ-SQ) necesitan ser escaladas para
acomodar más instrucciones en ellas y tolerar
eficazmente mayores latencias de memoria.
Llevados por esta tendencia, nuestro objetivo en
este artículo es diseñar una estructura de LQ-SQ
eficiente y escalable, que pueda ahorrar energía
sin sacrificar el rendimiento.
El resto del artículo se organiza como sigue:
las secciones 2 y 3 presentan el diseño
convencional y nuestro mecanismo alternativo
de LQ-SQ respectivamente. La sección 4 resume
el entorno experimental y la sección 5 analiza
los resultados obtenidos. La sección 6 trata el
trabajo relacionado. Finalmente, la sección 7
presenta nuestras conclusiones así como algunas
ideas para trabajo futuro.
2. Diseño convencional de la LSQ
Las implementaciones convencionales de LSQ
están basadas generalmente en dos colas
separadas, la cola de loads (LQ) y la cola de
stores (SQ) (ver Figura 1). Cada entrada de estas
colas proporciona un campo para la dirección
efectiva (E.A) y otro para el dato. Por ejemplo,
el microprocesador Alpha 21264 [8] incorpora
32+32 entradas para las colas de loads y stores.
Las técnicas del load forwarding y el load
bypassing incrementan la complejidad de estas
estructuras dado que requieren búsquedas
asociativas (B.A) en la SQ para detectar aliasing
entre los loads y los stores precedentes. La
especulación aumenta más aún el grado de
complejidad ya que las búsquedas asociativas
son necesarias también en la LQ para detectar
loads prematuros: cuando se resuelve la E.A. de
un store se lleva a cabo una B.A. en la LQ; si se
encuentra un match con un load posterior que
haya sido ya lanzado entonces se inicia una
reejecución desde el load que crea el conflicto.
LQ
Ef_Add
Data
Squash or
Forwarding?
SQ
Ef_Add
Data
Forwarding
or Bypass?
Figura 1. Diseño de una LQ-SQ convencional. Cada
instrucción de load realiza una búsqueda asociativa en
la SQ para determinar si es necesario in load
forwarding o un load bypassing. Cada store también
lleva a cabo una búsqueda asociativa en la LQ para
pasar el dato a un load posterior con la misma
dirección, lo cual puede ocurrir si el load se encuentra
esperando a que algún puerto de memoria quede libre,
o para iniciar una reejecución si el load está ya en
ejecución.
3. Gestión eficiente de la LQ-SQ
3.1 Fundamento
A pesar de que las técnicas ya mencionadas
(load forwarding y load bypassing) mejoran el
rendimiento, también requieren gran cantidad de
hardware que incrementa el consumo de energía.
En este artículo exploramos un diseño
alternativo de LQ-SQ y proponemos una gestión
eficiente de la misma que permite una
significativa reducción en la energía consumida.
Esta nueva propuesta se basa en las siguientes
observaciones:
1.- Las dependencias de memoria son
bastante infrecuentes. Nuestros experimentos
indican que sólo alrededor del 11% de los loads
necesitan un forwarding. Esto sugiere que el
complejo hardware de desambiguación
disponible en los microprocesadores modernos
está siendo muy a menudo infrautilizado.
2.- En promedio, alrededor del 73% de las
instrucciones de memoria que aparecen en un
programa son loads. Por tanto, su contribución a
la energía dinámica consumida por el hardware
de desambiguación es mucho mayor que la de
los stores. Esto sugiere que debemos prestar
mayor atención en el tratamiento de los loads.
3.- El comportamiento de loads y stores está
en general fuertemente sesgado, lo cual tenemos
en consideración para su clasificación mediante
profiling. Esta clasificación puede ser usada para
una gestión más eficiente de la LQ-SQ.
3.2 Estructura global
La estructura global del diseño de LQ-SQ
explorado se muestra en la Figura 2. La LQ
convencional es dividida en dos estructuras
diferentes: una LQ asociativa (ALQ) y una LQ
no asociativa dividida en bancos (BNLQ). La
ALQ es similar a una LQ convencional, pero
más pequeña que ésta. Consta de campos para la
E.A. y el dato del load, así como de lógica de
control para llevar a cabo búsquedas asociativas.
La BNLQ consiste en un simple buffer que
almacena la E.A. y el dato del load. Añadimos
también un mecanismo, que denotaremos como
28 Arquitectura del Procesador y Multiprocesadores
EBF (Exclusive Bloom Filter) para garantizar la
corrección semántica del programa.
ALQ
SQ
EA
Data
EA
Data
BNLQ
EA
Data
EBF
Hash
Hash
Squash or
Forwarding?
Bypass or
Forwarding?
Squash ?
+1
Figura 2. Gestión efectiva de la LQ-SQ. La LQ se
divide en dos colas, una asociativa (ALQ) para
aquellos loads predichos como dependientes y una
cola no asociativa y dividida en bancos (BNLQ) para
los loads predichos como independientes. La ALQ y la
SQ funcionan de la misma forma que una LQ-SQ
convencional. Para asegurar que se detectan los loads
“prematuros” aunque éstos hayan sido alojados en la
BNLQ usamos un Exclusive Bloom Filter (EBF).
3.3 Distribución de los loads y predicción de
dependencias
La distribución de los loads entre la ALQ y la
BNLQ es un aspecto clave a considerar. Nuestra
distribución está basada en una noción extendida
de dependencia, que llamaremos dependencia
EBF. Clasificaremos como EBF dependientes a
aquellos loads que mientras se encuentren en
vuelo coexistan con algún store que acceda a su
misma E.A... Esta definición incluye aquellos
loads cuya E.A. coincide con la de un store
posterior según el orden del programa. Nótese
que los loads realmente dependientes sólo son
aquellos que reciben su dato directamente de un
store anterior. El uso de este concepto de
dependencia extendido se debe a la imprecisión
del (aunque más eficiente en términos de
energía) mecanismo de desambiguación
utilizado para tratar a los loads independientes,
tal y como explicaremos a continuación.
Después de decodificar una instrucción de
load, ésta se alojará en una determinada cola en
función de un predictor, que puede ser dinámico
o bien basado en información de profiling. De
acuerdo con esta información y teniendo en
cuenta la ocupación de las colas, el load es
asignado a la ALQ o a la BNLQ. En nuestro
diseño, si un load se predice como independiente
y la BNLQ se encuentra llena, éste es asignado a
la ALQ, ya que un load independiente siempre
puede ser alojado en la cola asociativa sin
comprometer la corrección del programa.
Una vez que los loads son asignados a sus
colas correspondientes es necesario realizar
diversos chequeos para detectar violaciones de
la consistencia de memoria.
Como se describió con anterioridad, en una
LQ-SQ convencional estas posibles violaciones
se detectan por medio de búsquedas asociativas.
El mecanismo que nosotros proponemos sigue
esta misma estrategia para los loads alojados en
la ALQ. Sin embargo, para aquellos asignados a
la BNLQ se necesita incorporar un mecanismo
adicional para detectar estas potenciales
violaciones. Al igual que en [11], nuestra
implementación añade una tabla de contadores
de dos bits, denotada como EBF (Figura 2).
Cuando se lanza un load asignado a la BNLQ,
éste indexa el EBF a partir de su E.A. e
incrementa el contador correspondiente. Cuando
el load termina el contador es decrementado.
Cuando se lanzan los stores, los loads mal
especulados alojados en la ALQ son detectados
realizando una B.A., al igual que en un diseño
convencional. Los loads mal especulados
acomodados en la BNLQ se detectan indexando
el EBF con la E.A. del store. Si el
correspondiente contador es mayor que cero, al
menos un potencial load EBF dependiente se
encuentra en vuelo. En este caso nuestro
mecanismo, de forma conservadora, inicia una
reejecución desde el load en cuestión por ser
éste un posible load realmente dependiente.
Hemos de resaltar que cuando ocurre un
desbordamiento, es decir, cuando más de cuatro
loads indexan una misma entrada del EBF, el
lanzamiento del quinto load se detiene hasta que
alguna de las otras cuatro termina y abandona el
sistema (este es un caso muy infrecuente).
3.3.1 Predictor basado en profiling
En un sistema basado en profiling, cada load
estático es marcado como independiente o
dependiente en función de la información del
propio profiling. De esta forma, la predicción
XVI Jornadas de Paralelismo, JP '2005 29
está ligada a los loads estáticos. La Tabla 1
muestra lo razonable de este enfoque, ya que la
mayoría de los loads son siempre dependientes o
siempre independientes, lo cual puede ser
capturado fácilmente a través de un profiling.
Tabla 1. Comportamiento relativo a dependencias de
loads estáticos. Se muestran porcentajes dinámicos y
estáticos
INT Avg FP Avg Tot Avg
Indep Loads (%) 75.1 88.2 82.8
Dep Loads (%) 4.3 3.9 4.0
Unbiased Loads (%) 20.6 7.9 13.2
INT Avg FP Avg Tot Avg
Indep Loads (%) 65.1 86.1 77.3
Dep Loads (%) 2.4 4.1 3.4
Unbiased Loads (%) 32.5 9.8 19.3
DYNAMIC
STATIC
En promedio, sólo el 13% de los loads
estáticos cambian su comportamiento relativo a
dependencias durante la ejecución del programa.
A pesar de que este porcentaje se traduce en uno
mayor al referirlo al total de instrucciones
dinámicas, el comportamiento sigue siendo muy
uniforme (en torno al 20%).
Nuestra clasificación basada en profiling
marca como dependientes aquellos loads
estáticos que durante el profiling superan un
cierto umbral. En concreto, si t denota el número
total de instancias de un cierto load estático, y d
el número en las cuales es EBF-dependiente, el
load será predicho como dependiente si el
cociente d/t es mayor que el umbral. Un umbral
de cero nos sirve para referenciar el caso
especial en el que la aparición de al menos una
instancia EBF-dependiente implica la
clasificación de ese load como dependiente.
Hemos considerado diferentes umbrales, todos
ellos comprendidos en el rango 0-0.5.
3.3.2 Predictor de dependencias dinámico
Una alternativa al sistema basado en profiling es
generar la predicción de dependencia durante la
ejecución. Hemos explorado un predictor
dinámico en [6], en donde la información de
predicción es almacenada en una tabla dedicada
indexada por PC de la misma forma que en el
Alpha 21264 [8]. Todos los loads estáticos son
considerados inicialmente como independientes,
y esta predicción se cambia para el load al que
se le detecta una potencial dependencia. Una vez
que la predicción ha sido modificada, ésta se
mantiene durante el resto de la ejecución. Esta
decisión, que se basa en lo mostrado en la Tabla
1, supone un pequeño impacto en la precisión de
la predicción y simplifica la implementación.
Esta alternativa no necesita ningún cambio en la
arquitectura del conjunto de instrucciones ni
ningún profiling. Sin embargo, sí requiere un
almacenamiento extra y una fase inicial de
entrenamiento del predictor.
4. Entorno experimental
Evaluamos el diseño de LQ-SQ propuesto en un
simulador de procesador genérico con
lanzamiento fuera de orden. Los principales
parámetros utilizados en las simulaciones se
resumen en la Tabla 2. Como herramienta de
simulación empleamos una versión modificada
del SimpleScalar [1] que incorpora nuestro
modelo de LQ-SQ y un entorno Wattch refinado
[3] que modela el consumo de energía en el
mecanismo del mecanismo LQ-SQ propuesto.
Tabla 2. Configuración del procesador
Processor Caches and Memory
8-issue out of order processor
Register File:
256 integer physical registers
256 FP physical registers
Units:
4 integer ALUs, 2 integer Mult-Dividers, 3
FP ALUs, 1 FP Mult-Dividers
Branch Predictor:
Combined, bimodal: 8K entries 2level, 8K
entries, 13 bits history size, meta-table: 8K
entries
BTB: 4K entries
RAS: 32 entries
Queues:
I-Queue: 128 entries
FP-Queue: 128 entries
L1 data cache:
32-KB, 4-way, LRU, latency: 3 cycles
L2 data cache:
2-MB, 8-way, LRU, latency: 12 cycles
L1 instruction cache:
64-KB, 2-way, LRU, latency: 2 cycles
Memory access:
100 cycles
Baseline LQ-SQ Original State Filtering Proposed LQ-SQ
LQ: 80 entries SQ: 48 entries BNLQ-ALQ : 32-48/40-40/
SQ: 48 entries EBF: 4K entries (2-bit per entry) 48-32/56-24 SQ: 48 entries
EBF: 4K entries (2-bit per entry)
Integer applications: bzip2, crafty, eon, gap, gzip, parser, twolf, vpr
FP applications: applu, apsi, art, facerec, fma3d, galgel, mesa, mgrid, sixtrack,
wupwise
La evaluación de nuestra propuesta ha sido
realizada eligiendo varios benchmarks del
conjunto SPEC CPU2000. Con esta selección
hemos tratado de cubrir una amplia variedad de
comportamientos. En el profiling se han usando
entradas train, mientras que para los
experimentos simulamos regiones single sim-
point [13] de 100 millones de instrucciones.
30 Arquitectura del Procesador y Multiprocesadores
Hemos comparado tres mecanismos LQ-SQ
diferentes: una LQ-SQ convencional que
usamos como configuración base, el esquema
original de state filtering propuesto en [11], en
donde la LQ asociativa es completamente
eliminada (todos los loads indexan una entrada
en el EBF) y nuestra alternativa propuesta.
5. Resultados experimentales
5.1 Predictor de dependencias
Para comparar el comportamiento del predictor
dinámico y el basado en profiling, así como las
diferentes configuraciones de este último
(distintos valores del umbral), hemos empleado
las métricas derivadas del trabajo de Grunwald
et al. sobre estimación de confianza [7]:
x Predictive Value of a Positive test (PVP).
Identifica la probabilidad de que un load
dependiente sea predicho correctamente. Se
calcula como el cociente entre el número de
loads correctamente predichos como
dependientes, y el número total de loads
predichos como dependientes.
x Predictive Value of a Negative test (PVN).
Identifica la probabilidad de que un load
independiente sea incorrectamente predicho.
Se calcula como el cociente entre el número
de loads incorrectamente predichos como
independientes y el número total de loads
predichos como independientes.
En nuestro caso, identificar de manera precisa
los loads dependientes (esto es, un predictor con
un alto valor de PVP), reduce la presión sobre la
ALQ. Esta reducción se traduce en mayores
ahorros del consumo de energía. Por otro lado,
cuando un load EBF-dependiente es clasificado
de manera incorrecta, (es decir, es alojado en la
BNLQ), se produce una reejecución, que implica
una degradación del rendimiento muy
significativa. Por esto, en nuestro contexto sólo
son aceptables valores muy reducidos de PVN.
La Figura 3 muestra las medidas de PVN y
PVP para los diferentes predictores estudiados,
usando una BNLQ de 48 entradas y una ALQ de
32. Para realizar un estudio más completo hemos
considerado tanto dependencias EBF (que son
las que verdaderamente nos interesan) como
dependencias reales.
Como era de esperar, si se utilizan umbrales
no agresivos (menores que 0.1), los valores para
el PVN son muy pequeños y la penalización en
rendimiento es prácticamente insignificante. Por
otro lado cabe resaltar que los valores de PVP
obtenidos son menores que lo deseable pues
nuestro esquema es altamente conservador. No
obstante, no es aconsejable usar umbrales más
agresivos ya que ello deteriora el PVN sin
producir mejoras significativas en el PVP.
Respecto al predictor dinámico, éste es
claramente superado por la estrategia basada en
profiling. Esta observación nos ha sugerido
ignorarlo en el resto de este artículo y hacer
mayor énfasis en el mecanismo basado en
profiling.
0
1
2
3
10 15 20 25 30 35 40
PVP (%)
PVN
(%)
profile-based
dynamic 0.5
0
1
2
3
4
5
6 8 10 12 14
PVP (%)
PVN
(%)
profile-based
dynamic
0
0.5
Figura 3. PVN frente a PVP considerando tanto
dependencias EBF (gráfica superior) como
dependencias verdaderas (gráfica inferior) para BNLQ
= 48 entradas y ALQ = 32. En el predictor basado en
profiling hemos empleado el siguiente rango de
umbrales : 0, [0.01:0.1], 0.2, 0.3, 0.4 y 0.5.
La Figura 4 muestra de nuevo PVN frente a
PVP (considerando dependencias verdaderas y
usando un umbral de 0.01) pero variando el
tamaño de EBF. Como cabría esperar, el PVP se
incrementa con el tamaño del EBF, debido a la
XVI Jornadas de Paralelismo, JP '2005 31
reducción del número de falsos positivos. Sin
embargo, un EBF de 4K entradas se presenta
como la opción más conveniente, pues aumentar
más el número de entradas no se traduce en
mejoras significativas del PVP.
0
1
2
3
4
5
8 9 10 11 12 13 14
PVP (%)
PVN
(%)
512 4K
64K
Figura 4. PVN frente a PVP para diferentes tamaños
de EBF, desde 512 entradas hasta 64K entradas
(BNLQ=48, ALQ=32, y un umbral de 0.01).
5.2 Exploración del umbral
Teniendo en cuenta las consideraciones previas
es razonable elegir un valor del umbral en el
rango entre 0 y 0.5. No obstante, como la Figura
5 ilustra, el umbral óptimo para una
configuración dada depende fuertemente de la
aplicación. Por ello necesitamos un algoritmo
que pueda encontrar el valor óptimo o
subóptimo del umbral.
1,5
2,5
3,5
4,5
0 1 2 3 4
Slowdown (%)
Energy
Savings
(%)
gzip
gap
apsi
sixtrack
0.01
0.06
0.02
0.07
Figura 5. Ahorro de energía frente a pérdida de IPC
respecto a la configuración base usando una BNLQ y
una ALQ ambas de 40 entradas. El umbral óptimo
para cada aplicación está resaltado con una cruz.
Observando estas gráficas se deduce que la
exploración de todo el rango de valores es
innecesaria, y que un algoritmo “greedy” puede
encontrar el valor óptimo del umbral evaluando
un número relativamente pequeño de candidatos.
La exploración comienza desde el umbral más
pequeño (Figura 6), y estudia valores superiores
mientras que el tiempo de ejecución y el
consumo de energía sigan mejorando respecto al
anterior umbral.
0
1
2
3
-6 -5 -4 -3 -2 -1 0
Slowdown (%)
Energy
Savings
(%)
0.01
0.06
0.5
0
Figura 6. Ahorro de energía frente a pérdida de IPC
respecto a un umbral de cero para gzip usando una
configuración en la que ALQ y BNLQ proporcionan
ambas 40 entradas. El umbral óptimo encontrado por
nuestro algoritmo se destaca con una cruz.
5.3 Análisis de rendimiento y energía
La Tabla 3 resume las ganancias en energía y el
impacto sobre el rendimiento alcanzados por
diferentes configuraciones de LQ con nuestro
esquema basado en profiling sobre la
configuración base utilizada. Todas las
configuraciones pueden albergar el mismo
número de loads (80), pero difieren en el reparto
entre la ALQ y la BNLQ.
Nuestro mecanismo logra reducir el
consumo de energía en la LQ-SQ en algo más de
un 40% en promedio con una pérdida de
rendimiento muy pequeña (menos del 1% en
promedio). Esto se traduce en una moderada
reducción de energía en el conjunto del
procesador. Usar una ALQ de 40 entradas
parece ser la opción más adecuada.
Como era de esperar, el consumo de energía
en la LQ-SQ disminuye a medida que lo hace el
tamaño de la ALQ: cuanto menos costosa es la
búsqueda asociativa menor es la energía
consumida en cada acceso. Sin embargo, al
decrecer el tamaño de la ALQ crece el número
32 Arquitectura del Procesador y Multiprocesadores
de conflictos de capacidad incurriendo por tanto
en penalizaciones de tiempo, que a su vez hacen
aumentar el consumo de energía en otras partes
del procesador (debido fundamentalmente a
mayor consumo de la distribución del reloj). De
hecho, en la configuración más agresiva la
reducción de energía en la LQ-SQ está
parcialmente encubierta por esta energía extra
consumida en el resto del procesador.
Tabla 3. Comportamiento medio para el mecanismo
propuesto de gestión de LQ-SQ, usando un predictor
basado en profiling. La tabla muestra las pérdidas de
rendimiento y los ahorros de energía tanto en la LQ-
SQ como en el conjunto del procesador respecto a la
configuración base.
INT Avg FP Avg Tot Avg
Slowdown (%) 0.4 0.3 0.4
¨ LQ-SQ Energy (%) 34.0 37.9 36.1
¨Energy (%) 2.9 3.0 3.0
INT Avg FP Avg Tot Avg
Slowdown (%) 0.5 0.8 0.6
¨ LQ-SQ Energy (%) 38.5 42.3 40.5
¨Energy (%) 3.2 3.2 3.2
INT Avg FP Avg Tot Avg
Slowdown (%) 0.9 1.1 1.0
¨ LQ-SQ Energy (%) 41.5 46.7 44.2
¨Energy (%) 3.4 3.4 3.4
INT Avg FP Avg Tot Avg
Slowdown (%) 1.7 2.2 2.0
¨ LQ-SQ Energy (%) 45.6 51.1 48.5
¨Energy (%) 3.5 3.3 3.4
BNLQ=48 ALQ=32
BNLQ=56 ALQ=24
BNLQ=32 ALQ=48
BNLQ=40 ALQ=40
La Tabla 4 explora los efectos de escalar
nuestro diseño de LQ-SQ. Aunque existe una
cierta ganancia en energía debido a la mejora en
el IPC, el aumento del tamaño de la BNLQ
apenas incrementa el consumo de energía debido
a su estructura de bancos. Además, ya que se
filtran la mayoría de las búsquedas asociativas,
un ligero incremento en la ALQ no incurre en un
significativo aumento de la energía consumida.
Finalmente, la Tabla 5 compara el esquema
original del state filtering respecto a la misma
configuración base. El ahorro de energía en la
LQ-SQ ronda el 69% debido a que la LQ
asociativa ha sido eliminada en su totalidad; sin
embargo el IPC empeora de forma inaceptable,
lo cual se traduce en un aumento de la energía
consumida por el conjunto del procesador.
Tabla 4. Comportamiento medio para el mecanismo
propuesto de gestión de LQ-SQ escalando la ALQ y la
BNLQ. La tabla muestra las pérdidas de rendimiento y
las ganancias en energía sobre la configuración base.
INT Avg FP Avg Tot Avg
Slowdown (%) -1.3 -7.3 -4.7
¨ LQ-SQ Energy (%) 40.9 49.1 45.5
ǻ Energy (%) 4.2 7.9 6.3
INT Avg FP Avg Tot Avg
Slowdown (%) -1.3 -7.9 -5.1
¨ LQ-SQ Energy (%) 36.5 45.1 41.3
ǻ Energy (%) 3.8 7.9 6.1
BNLQ=80 ALQ=40
BNLQ=70 ALQ=50
Tabla 5. Comportamiento medio del state filtering
original [11]. La tabla muestra las pérdidas de IPC y
las ganancias de energía sobre la configuración base.
INT Avg FP Avg Tot Avg
16,90 20,03 18,64
68,48 69,18 68,87
-6,56 -10,70 -8,86
Slowdown (%)
¨ LQ-SQ Energy (%)
¨ Energy (%)
6. Trabajo relacionado
Recientemente se han propuesto una serie de
esquemas que usan filtros Bloom para mejorar la
escalabilidad de la LSQ [11,12]. Estos esquemas
se encuadran dentro de dos grandes categorías.
La primera, llamada filtrado de búsquedas,
reduce el número de búsquedas asociativas en la
LQ-SQ. En la segunda categoría, llamada state
filtering, la LQ-SQ aloja únicamente aquellas
instrucciones de memoria susceptibles de
presentar dependencias, y una serie de filtros
Bloom (denotados como EBF en [11]) codifican
el resto de instrucciones de memoria. En [11] se
plantea un simple diseño preliminar en el cual el
hardware asociativo de la LQ es totalmente
eliminado y todos los loads acceden al EBF
(hemos llamado a este esquema state filtering
original en la sección 5.3). Los resultados
experimentales empleando tal esquema muestran
una enorme pérdida de rendimiento.
En el campo de la LQ-SQ se han propuesto
soluciones alternativas a las mostradas hasta el
momento para conseguir reducir la gran energía
consumida por la estructura. Park et al. [9]
propusieron usar un predictor de dependencias
para filtrar accesos a la SQ. Cain y Lipasti [4]
propusieron un esquema para el ordenamiento
de memoria que consigue colas de loads
escalables. Roth [10] explota la predictibilidad
XVI Jornadas de Paralelismo, JP '2005 33
del comportamiento de los forwardings
proponiendo un predictor que filtra accesos tanto
para loads como para stores. Baugh et al. [2]
proponen una organización de LQ-SQ que
separa la funcionalidad del forwarding del
chequeo para comprobar que los loads reciben el
valor correcto.
7. Conclusiones y trabajo futuro
En este trabajo hemos presentado un esquema de
gestión de la LSQ, el cual, con una pérdida de
rendimiento casi despreciable, consigue una
significativa reducción de la energía consumida:
alrededor de un 40% en la LQ-SQ y cerca de un
3.5% en el conjunto del procesador. Los puntos
clave de nuestra propuesta son los siguientes:
x Se ha propuesto un predictor de
dependencias basado en profiling, el cual
está especialmente indicado para usar con
filtros Bloom. Los predictores tradicionales
no son apropiados para este esquema debido
al concepto extendido de dependencia
manejado por nuestro EBF.
x Con el propósito de realizar un estudio más
completo hemos explorado distintos valores
umbral durante el profiling. Nuestras
medidas han revelado una moderada
variabilidad entre aplicaciones, la cual puede
ser fácilmente resuelta empleando un
sencillo algoritmo greedy.
x Dividir la LQ en estructuras asociativa y no
asociativa permite ahorros de energía
significativos gracias a la reducción del
número y del coste de los accesos
asociativos. Además, una tabla no asociativa
se puede dividir en bancos de forma
sencilla, lo que permite reducciones de
energía adicionales y facilita su escalado.
Nuestros futuros planes de investigación
incluyen aplicar bank gating. También debemos
mejorar la función hash utilizada para indexar el
EBF así como el predictor, ya que la actual
implementación es muy conservadora.
Referencias
[1] T. Austin, E. Larson, and D. Ernst.
“SimpleScalar: An Infrastructure for Computer
System Modeling”. Computer, vol. 35, no. 2,
Feb 2002.
[2] L. Baugh and C. Zilles. “Decomposing the
Load-Store Queue by Function for Power
Reduction and Scalability”. Proceedings of PAC
Conference, October-2004.
[3] D. Brooks, V. Tiwari, and M. Martonosi.
“Wattch: A Framework for Architectural-Level
Power Analysis and Optimizations”. 28-ISCA,
Göteborg, Sweden. July, 2001.
[4] H. W. Cain and M. H. Lipasti. “Memory
Ordering: A Value-Based Approach”.
Proceedings of ISCA-31, June-2004.
[5] B. Calder and G. Reinman. “A Comparative
Survey of Load Speculation Architectures”.
Journal of Instruction-Level Parallelism, May-
2000.
[6] F. Castro, D. Chaver, L. Pinuel, M. Prieto,
M. C. Huang, F. Tirado. “A Power-Efficient and
Scalable Load-Store Queue Design”. ArTeCS
Technical Report 05-01.
[7] D. Grunwald, A. Klauser, S. Manne, A.
Pleszkun. "Confidence estimation for
speculation control". Proc. Int. Symp. on
Computer Architecture, pp. 122 - 131, Jun 1998.
[8] R. E. Kessler. “The Alpha 21264
Microprocessor”. Technical Report, Compaq
Computer Corporation, 1999.
[9] I. Park, C. Liang Ooi, T. N. Vijaykumar.
“Reducing design complexity of the load-store
queue”. Proceedings of MICRO-36, Dec 2003.
[10] A. Roth. “A high-bandwidth load-store unit
for single- and multi- threaded processors”.
Technical Report, Univ. of Pennsylvania, 2004.
[11] S. Sethumadhavan, R. Desikan, D. Burger,
Charles R. Moore, Stephen W. Keckler.
“Scalable Hardware Memory Disambiguation
for High ILP Processors”. Proceedings of
MICRO-36, December-2003.
[12] S. Sethumadhavan, R. Desikan, D. Burger,
Charles R. Moore, Stephen W. Keckler.
“Scalable Hardware Memory Disambiguation
for High ILP Processors”. IEEE-Micro, Vol. 24,
Issue 6:118-127, November/December, 2004.
[13] T. Sherwood, E. Perelman, G. Hamerly, B.
Calder. “Automatically charecterizing large
scale program behavior ”. Proceedings of
ASPLOS-2002, October-2002.
[14] J. M. Tendler, J. S. Dodson, J. S. Fields Jr.,
H. Le and B. Sinharoy. “Power-4 System
Microarchitecture”. IBM Journal of Research
and Development, 46(1):5-26, 2002.
34 Arquitectura del Procesador y Multiprocesadores
Performing fair comparison studies
of leakage reduction policies
Salvador Petit, Julio Sahuquillo
Departamento de Informática de Sistemas y Computadores
Universidad Politécnica de Valencia
46022 Valencia
{spetit, jsahuqui}@disca.upv.es
Abstract
Technology projections indicate that static power
will become a major concern in future generations
of high-performance microprocessors. Caches
represent a significant percentage of the overall
microprocessor die area. Therefore, recent
research has concentrated on the reduction of
leakage current dissipated by caches. The variety
of techniques to control current leakage can be
classified as non-state preserving or state
preserving. Non-state preserving techniques
power off selected cache lines while state
preserving place selected lines into a low-power
state. Drowsy caches are a recently proposed
state-preserving technique. In order to introduce
low performance overhead, drowsy caches must
be very selective on which cache lines are moved
to a drowsy state.
Past research on cache organization has
focused on how best to exploit the temporal
locality present in the data stream. In a previous
paper we proposed a drowsy cache policy called
Reuse Most Recently used On (RMRO), which
makes use of reuse information to trade off
performance versus energy consumption.
Energy saving policies must trade off energy
with performance. Nevertheless, this trade off
depends on the switch-off interval considered by
the policy. We observed that considering the same
interval length for all the compared policies, we
could carry out wrong conclusions. In this paper
we extend the comparison performed in [12] to
determine the interval length that should be used
by each policy in order to carry out a fair
comparison study. Results show that the RMRO
policy is the best for those interval lengths
achieving energy saving higher than 60%.
1. Introduction
Power has become a major design concern in
current microprocessors. The power dissipated has
two main components: 1) dynamic power, and 2)
static or leakage power. Dynamic power is
dissipated due to transistor switching activity,
while leakage power continuously dissipates, even
when transistors are idle. In current CMOS
technologies, dynamic power is dominant and
leakage power is less of a concern. However,
technology projections for the foreseeable future
(e.g., 70nm technologies) suggest that static power
will dominate overall chip power [10].
Leakage power is dependent on the number of
transistors and transistor features implemented.
The majority of leakage will come from the
largest processor components. Recent research
work has focused on reducing power dissipation
in different elements of the microprocessor (e.g.,
in caches [5][4][2][9][1], and arithmetic units [3]).
Cache memories occupy a large percentage of
the overall microprocessor die area (e.g., 30% in
the Alpha 21264 [6]). This percentage of die area
has increased in more recent high performance
microprocessors that include large L2 caches.
Furthermore, some microprocessors include up to
three cache levels on chip (e.g., the Itanium2 [8],
which includes a 3 MB L3 cache).
Since caches consume so much chip real
estate, we need to find techniques where we can
disable selected lines. Proposed techniques can be
broken down into state preserving [4][7], and state
non-preserving [9], depending on if the cache line
loses or maintains the information stored. To
avoid losing the information, a state preserving
solution can place a line in a low-power state-
preserving mode, referred to as drowsy mode.
Lines in this mode maintain their information, but
incur additional cycles to access the information.
As schemes preserving the state do not lose
data, accesses can hit either in an enabled or low-
powered line. Since a hit in a low-powered line
can increase the average data access time, the goal
that many schemes tries to insure that a significant
fraction of the hits are in enabled lines. The goal is
to reduce power while maintaining performance.
Set-associative caches reduce the number of
misses, though they have a longer access time and
increase power dissipation compared to direct-
mapped caches. This increase in power is mainly
due to the fact that current microprocessors
include as many tag comparators as the number of
ways in the cache. There is also extra logic
introduced to select the data on a hit. Even given
these issues, current microprocessors still
implement multi-way set associative caches (e.g.,
the Itanium2 [8], which provides a 4-way set-
associative L1 data cache). Furthermore, the L1
data cache of the Itanium2 has a one cycle hit
time.
To arrive at the strategy presented in this
paper, we first studied the temporal locality
present in a number of applications. To evaluate
our strategy, we measured the leakage savings and
performance impact of two different versions of
our scheme. In our approach, we choose to keep a
fixed number of ways of each set in a low-power
state-preserving state. Experimental results show
that when the L1 data cache maintains one
enabled line per set (e.g., the LRU entry in each
set), power is reduced dramatically, while only
impacting performance slightly. The underlying
principle of these simple policies is that they
exploit temporal locality to reduce leakage power.
Cache accesses can be bursty during program
phases, such that only a few sets are accessed for a
long period of time [5]. To benefit from this
situation, in a previous paper [12] we proposed a
new state-preserving cache policy (RMRO) to
reduce the leakage current in the data cache. The
key idea behind this policy is to exploit reuse
information [11], which is used to adaptively
disable ways and whole sets, while keeping in
mind the intrinsic temporal locality of the
workloads.
Using this policy, we will enable zero, one, or
two lines per set, while the rest of the lines are
disabled. In this way, the fraction of low-powered
lines exponentially increases with the cache
associativity, as do the potential benefits of the
scheme. Although our proposal can be applied to
any level of the cache hierarchy, in this paper we
focus on the performance of a 4-way set-
associative first-level data cache. We compare the
RMRO policy to a recently proposed policy
(SOW) [4]. To this end, we analyze how leakage
and performance trade off depending on the
switch-off interval length for each policy. In this
way, we determine the correct interval length for
each policy, in order to do a fair comparison on a
energy basis or on a performance basis; i.e., we
determine the policy that achieves more energy
savings for a given performance and vice versa.
The remainder of this paper is organized as
follows. Section 2 describes recent research on
power reduction. Section 3 presents the range of
temporal localities present in the SPEC workloads
studied. Section 4 evaluates two simple drowsy
policies, as well as our adaptive drowsy policy.
Finally, section 5 presents some concluding
remarks.
2. Related work
A common technique applied to reduce leakage in
caches is to reduce the power supplied. Two main
methods have been proposed in recent literature
are gated-VDD and drowsy caches.
The gated-VDD [9] technique proposed by
Powell et al. uses a transistor to gate the supply of
the cache SRAM cells. This technique
dramatically reduces the current leakage since
selected lines are powered off. Of course, when
lines are powered off, the stored information is
lost. The main drawback of this technique is that
L1 cache misses involve additional accesses to the
L2 cache, which incur additional energy
dissipation.
Drowsy caches [4] are an alternative
technique proposed by Flautner et al. This
technique saves energy by reducing the power
supply for the selected cache lines, though the
supply is not gated. Proceeding in this way, the
technique avoids losing information. These lines
are placed in drowsy mode, and need to be
awaken prior to accessing the data. The advantage
of this technique is that it achieves the same L1 hit
ratio as conventional caches; therefore, no
additional accesses to the L2 cache are needed.
Nevertheless, as the supply voltage is reduced,
36 Arquitectura del Procesador y Multiprocesadores
current leakage is still greater than the leakage
introduced using the gated-VDD technique.
The cache policies discussed in this paper deal
with drowsy caches, though they can be used for
any state-preserving leakage-saving technology.
Moreover, they also can be applied with
technologies that do not preserve the state,
although the modifications to do so are out of the
scope of this work.
3. Temporal locality variations
In this section we investigate the temporal locality
of lines on a per set basis. The main objective here
is to identify those lines possessing low temporal
locality. To this end, we measure the percentage
of cache line accesses that hit in the most recently
used (MRU) line, in the previous most recently
used line, and so on.
Experiments were run considering multi-way
sets. In particular, we selected a L1 data cache
similar to the design used for the Itanium2 (i.e.,
16KB, 64B line, 4 way set-associative (64 sets)).
Table 1 shows the results. As observed, only one
line per set (the most recently used) captures
almost 92.15% of all cache hits. If two lines per
set are taken into account (half of the cache lines),
this percentage increases to 98.45%. Therefore,
the remaining half of the cache lines is responsible
for 1.55% of all hits. Basing on these results, we
explored two straightforward, simple and cost-
effective policies for drowsy caches: called the
MRO and the TMRO policies.
The MRO (Most Recently used On) policy,
maintains one line as active in each cache set. The
obvious choice would be to maintain the most
recently used entry, while the remaining lines are
placed into drowsy mode. On a hit into a drowsy
line, the line becomes the MRU and is woken up
to access the data. The previous MRU line is put
in drowsy mode, guaranteeing that only one line is
awake. Note that switching the MRU line involves
dynamic power dissipation; nevertheless, 92.15%
of the cache hits do not involve dynamic
switching since they hit in the MRU line.
The TMRO (Two Most Recently used On)
policy, keeps two lines awake per set (the most
recently and the previous most recently used
lines). This policy is more conservative than the
previous technique, since it doubles the number of
lines that are kept awake. Nevertheless, we study
this policy because a significant percentage of the
cache hits are due to accesses to the second most
recently used line. As a consequence, results
obtained from TMRO will show less energy
savings than MRO, but will incur fewer accesses
to drowsy lines.
Table 1 – Percentage of hits along the lines of each set.
Benchmark MRU line 2nd
MRU line Rest
168.wupwise 96.52 3.05 0.43
171.swim 95.80 4.10 0.10
172.mgrid 88.99 8.85 2.16
173.applu 94.05 5.34 0.61
177.mesa 95.25 4.63 0.12
178.galgel 84.10 12.75 3.15
179.art 95.96 3.93 0.11
183.equake 91.86 6.69 1.45
187.facerec 92.93 6.47 0.60
189.lucas 88.53 8.08 3.39
200.sixtrack 86.46 8.87 4.67
301.apsi 95.39 3.34 1.27
Average 92.15 6.34 1.51
4. Drowsy policies evaluation
Since a drowsy cache must offer a good tradeoff
between performance and power dissipation, we
evaluate drowsy cache policies and obtain both
the performance impact and the leakage savings.
The details of the experiment configuration can be
found in Table 2.
We compare both MRO and TMRO to the
simple policy proposed by Flautner et al in [4],
which we refer to as the Switch-Off Window
(SOW) policy. Although this work proposes two
policies, we only implement one of them because
the authors in [3] conclude that the policies
achieve similar performance by choosing the
appropriate window length.
The tradeoff of saving energy by putting
cache lines into a drowsy mode is that we will
increase the number of cache accesses that hit in
drowsy lines. In this section we quantify the
current leakage savings for the MRO, TMRO, and
SOW policies over a conventional cache, as well
as, the percentage of L1 data cache hits in drowsy
lines.
XVI Jornadas de Paralelismo, JP '2005 37
Table 2 – Experiment configuration.
Microprocessor core
Issue policy Out of order
Instruction fetch queue size 8 instructions
Branch predictor type 4K bimod. predictor table
12KB history size
Branch predictor penalty 2 cycles
Decode, issue, commit bandwidth 4 instructions/cycle
Register Update Unit (RUU) size 80
Load/Store Queue (LSQ) size 40
# of Int. ALU's, multiplier/dividers 4/1
# of FP ALU's, multiplier/dividers 2/1
Memory ports 2
Memory hierarchy
L1 data cache 16KB, 4 way, 64 byte-line
L1 data cache hit latency 2 cycles
L2 data cache 1 MB, 2 way, 64 byte-line
L2 data cache hit latency 11 cycles
Memory access latency 97,2,2,2
Energy configuration
Technology 70 nm
Leakage control technique Drowsy
Extra latency in low leak mode 1 cycle
Memory ports available (to CPU) 2
As mentioned above, drowsy cache policies
offer the same overall L1 cache hit ratio, since
they do not introduce additional misses.
Nevertheless, they will differ in the percentage of
accesses that hit in a drowsy line. Notice that this
percentage is directly related to speedup, since the
lower this percentage is, the lower the execution
time of an application.
Current leakage savings
Figure 1 plots the leakage current consumption
(the opposite of leakage savings). Results show
that MRO can outperform the baseline by about
72%, while TMRO surpasses the baseline by
about 48%. In both policies leakage savings
remain nearly constant across the applications due
to the fixed number of active lines (one and two,
respectively). They seem to also remain consistent
in execution time.
Drowsy hit ratio
The drowsy hit ratio is the percentage of all
accesses that hit in drowsy lines. The drowsy hit
ratio adversely impacts on performance because
each hit in a drowsy line invokes a wakeup cycle
before the hit can be serviced. Figure 2 plots the
drowsy hit ratio of the three policies.
Results show that the most conservative
policy (TMRO) achieves the lowest drowsy hit
ratio, while MRO presents the highest drowsy hit
ratio.
0%
10%
20%
30%
40%
50%
60%
1
6
8
.
w
u
p
w
i
s
e
1
7
1
.
s
w
i
m
1
7
2
.
m
g
r
i
d
1
7
3
.
a
p
p
l
u
1
7
7
.
m
e
s
a
1
7
8
.
g
a
l
g
e
l
1
7
9
.
a
r
t
1
8
3
.
e
q
u
a
k
e
1
8
7
.
f
a
c
e
r
e
c
1
8
9
.
l
u
c
a
s
2
0
0
.
s
i
x
t
r
a
c
k
3
0
1
.
a
p
s
i
A
v
e
r
a
g
e
M R O TM R O
Figure 1 - Leakage energy consumption relative to a conventional cache.
0%
5%
10%
15%
20%
1
6
8
.
w
u
p
w
i
s
e
1
7
1
.
s
w
i
m
1
7
2
.
m
g
r
i
d
1
7
3
.
a
p
p
l
u
1
7
7
.
m
e
s
a
1
7
8
.
g
a
l
g
e
l
1
7
9
.
a
r
t
1
8
3
.
e
q
u
a
k
e
1
8
7
.
f
a
c
e
r
e
c
1
8
9
.
l
u
c
a
s
2
0
0
.
s
i
x
t
r
a
c
k
3
0
1
.
a
p
s
i
A
v
e
r
a
g
e
M R O TM R O
Figure 2 – Drowsy hit ratio relative to a conventional cache.
38 Arquitectura del Procesador y Multiprocesadores
Further inspecting the results, we can see that
the main advantage of the MRO policy is its
ability to lower power consumption. Neverteless,
to improve performance; i.e., its drowsy hit ratio,
the policy should to wake up more lines per set;
e.g., two lines per set, as done in the TMRO
policy, where the drowsy hit ratio decreases by an
additional 6% (see Table 1). However, the TMRO
policy has a important shortcoming, since in this
policy leakage consumption is nearly two times as
large than in the MRO.
Figure 3 plots leakage consumption versus
drowsy hit ratio, varying the switch-off interval of
the SOW policy. A single point represents MRO
and TMRO because they do not implement
interval counters; therefore, they provide only one
option to tradeoff energy and performance.
Looking the plot we can find an interval length for
SOW that saves approximately the same energy
than MRO but offers better drowsy hit ratio; i.e.,
2K cycles. As opposite, it is also possible to find
an interval that offers similar drowsy hit ratio than
the TMRO policy but saves more energy.
0%
10%
20%
30%
40%
50%
60%
0% 1% 2% 3% 4% 5% 6% 7% 8% 9%
Drowsy Hit Ratio
Leakage
Consumption
SOW-512
SOW-8K TMRO
MRO
Figure 3 – Leakage consumption of SOW varying the
window size. Plotted points corresponding to the SOW
policy refer to interval lengths of 8K, 4K, 2K, 1K, and
512 cycles.
One can conclude that, although given their
lack of flexibility, both MRO and TMRO policies
are simple and cost-effective policies. The first
one offers good energy savings (as good as the
SOW-2K) while the second one offers good
drowsy hit ratio (between SOW-4K and SOW-
8K). Nevertheless, they restrict the performance
versus energy savings tradeoff since the number
of ways in a set remains constant across the
execution time. In the next section, we investigate
variants of these policies that provide mechanisms
in order to wake up lines on demand and place
them in drowsy mode when they are under-
utilized.
4.1. A new version of the RMRO Policy
The concept of the reuse information has been
already discussed in the literature [11] to improve
cache hit performance. In those applications, reuse
history was used to characterize reuse behavior
associated with a cache line. The main idea behind
this concept is that different L1 tours (i.e., the
time from when a block is placed into the L1 data
cache until it leaves the cache) of the same block
will behave homogeneous (i.e., a block’s behavior
will repeat in time). In this work, we make use of
cache line reuse information to improve both
performance and energy, across different
execution windows.
In [12] we proposed the RMRO (Reused Most
Recently used On) policy, which saves
information about cache line behavior while the
line is in a given execution window. This policy
wakes up lines on demand. When the execution
window expires, the line behavior information is
used to choose the line state (i.e., drowsy or
awake) for the next execution window. Taking
this into account, when the execution window
expires, the policy selects one of the following
actions for the next window:
x If no line was accessed during the window,
maintain the whole set in drowsy mode.
x If only one line was accessed during the
previous window, keep awake only the most
recently used line.
x If more than one line was accessed during the
previous window, keep awake the two most
recently used lines in the set. We bound this
number to two based on the results already
discussed for the TMRO policy.
In this paper we use a new version of the
RMRO proposed in [12] which offers better
energy-performance ratio. The main difference
consists in that policy used here limits the number
of awaked lines to two lines in a set; i.e., if a line
is referenced when two lines are already awake,
one of them should be placed in drowsy mode. As
the cache is four-way set associative, no more
than half of the lines can be awake.
XVI Jornadas de Paralelismo, JP '2005 39
Reuse information
To check how reuse information behaves across
windows, we quantify the probability of accessing
n lines in the next windowi+1, n  [1,4] after
accessing m lines in the current windowi. Table 3
shows the results for a 1024 cycle window length.
As observed, the main diagonal shows the largest
percentage for each row, with the only exception
of n=4. For instance, the probability of accessing
no lines during the next window after accessing
no lines during the current window is about 67%.
Therefore, this shows that a line’s behavior can
remain homogeneous across different time
windows.
Table 3 - Probability to access m lines along the next
window after accessing n lines in the current windowi.
Accessed lines in window i+1
i 0 1 2 3 4
0 67.2 24.5 6.8 1.3 0.2
1 18.2 56.6 19.8 4.7 0.8
2 6.2 26.5 48.1 15.3 3.9
3 2.4 13.6 32.9 39.0 12.1
4 1.1 7.4 25.0 35.5 31.1
Table 4 shows the weight of each given
probability over the total amount, for instance, the
probability of referencing no lines in a given
window is 24.6%. Notice that the probability of
accessing the full set (4 ways) in two consecutive
windows, which was the exception mentioned in
the previous table, represents a negligible 1.2%
increase over the total amount.
Table 4 - Overall probability to access m lines along the
next window after accessing n lines in the current
windowi.
Accessed lines in window i+1
i 0 1 2 3 4
0 16.5 6.0 1.7 0.3 0.1
1 6.2 19.2 6.7 1.6 0.3
2 1.6 6.8 12.3 3.9 1.0
3 0.3 1.6 3.9 4.6 1.4
4 0.0 0.3 1.0 1.4 1.2
Hardware implementation
A simple hardware control mechanism is designed
to handle the reuse information. A total of six bits
per set are used: one per line to indicate that a
given line has been accessed during the window
(i.e., the li), another one to indicate that only one
line of the set has been accessed (i.e., the ol), and
the last one to indicate that more than one line has
been accessed (i.e., the ml).
The mechanism works as follows: when a
window begins, all control bits are reset. Then,
when the accessed line is awakened, the
corresponding li bit and ol bits are set. For another
access, if the li bit is already set, the ml bit must be
also set to one. When the window expires, the ml
bit is inspected, and if set, then the two most
recently used lines must be maintained awake for
the next window. Otherwise, the value of the ol bit
is used to decide if either the recently used line or
no lines should be kept awake for the next
window.
Current leakage savings and drowsy hit ratio
In this section we compare the RMRO policy
versus the SOW policy. The drowsy hit ratio and
the energy savings offered by the RMRO policy
vary with the window length. Figure 4 relates
leakage consumption to drowsy hit ratio in both
compared policies, while varying the window
length. Notice that the window sizes needed by
each policy to reach a given performance or
energy point are different. For instance, the
window lengths that consume around a 30% of the
baseline leakage are 4K cycles for SOW and 1K
cycle for RMRO.
0%
10%
20%
30%
40%
50%
60%
0% 2% 4% 6% 8% 10%
Drowsy Hit Ratio
Leakage
Consumption
RMRO SOW
SOW-8K
SOW-512
RMRO-64K
RMRO-128
Figure 4 – Leakage consumption and drowsy hit ratio of
RMRO and SOW varying the window size. Plotted
points corresponding to the SOW policy refer to interval
lengths of 8K, 4K, 2K, 1K, and 512 cycles. Plotted
points corresponding to the RMRO policy refer to
interval lengths of 64K, 32K, 16K, 8K, 4K, 2K, 1K, 512,
256 and 128 cycles.
40 Arquitectura del Procesador y Multiprocesadores
The leakage consumption value of the
intersection point of both curves is around 45%.
Before this point, the SOW policy is below the
RMRO curve, and after this point the RMRO
curve is below the SOW curve. This means that in
the second range (after the intersection point)
RMRO is better than SOW both in performance
features and energy savings. In less energy-
efficient ranges (before the intersection point),
SOW offers a better drowsy hit ratio;
nevertheless, RMRO bounds this value to 1.8%.
On the other hand, notice that as no more than two
lines can be awake in the RMRO policy, leakage
consumption is bound to 50% with respect to the
baseline.
To perform a fair comparison between the
RMRO and SOW policies, we should fix the
comparison basis; i.e., performance or energy
consumption, and then we should determine the
corresponding interval length for each policy. For
instance, if we bound the drowsy hit ratio, we
should select the interval size consuming less
leakage for each policy, and if we bound the
leakage consumption, we should select the
interval sizes offering the smallest drowsy hit
ratio.
As example, for comparison purposes, we
choose the following restrictions: a leakage
consumption restriction of about a 30% (as the
MRO policy, see Figure 3) and a drowsy hit ratio
of about a 2% (close to the TMRO policy). Notice
that only the RMRO-1K policy accomplishes both
restrictions at the same time while no interval can
be found for the SOW policy performing the
same. In the SOW case, we select a 4K cycles
interval as the one that provides a hit ratio closest
to 2%, and a 2K cycles interval as the one that
provides energy savings closer to 30% (see Figure
4). Figure 5 shows the results for the drowsy hit
ratio. As one can observe, when the drowsy hit
ratio is bounded, the SOW leakage consumption
(39.40%) is, on average, about 30% higher than
the consumption of the RMRO policy (30.62%).
Figure 6 show the results for energy savings.
Notice that when leakage consumption is bounded
to 30%, the drowsy hit ratio of RMRO is 1%
below the drowsy hit ratio of SOW.
Finally, execution time of drowsy caches has
been also simulated, and our results are consistent
with those presented in [4], since the performance
impact is never more than 1%.
0%
20%
40%
60%
80%
100%
1
6
8
.
w
u
p
w
i
s
e
1
7
1
.
s
w
i
m
1
7
2
.
m
g
r
i
d
1
7
3
.
a
p
p
l
u
1
7
7
.
m
e
s
a
1
7
8
.
g
a
l
g
e
l
1
7
9
.
a
r
t
1
8
3
.
e
q
u
a
k
e
1
8
7
.
f
a
c
e
r
e
c
1
8
9
.
l
u
c
a
s
2
0
0
.
s
i
x
t
r
a
c
k
3
0
1
.
a
p
s
i
A
v
e
r
a
g
e
R M R O -
1K SO W -
4K
Figure 5 – Relative leakage consumption of RMRO versus SOW, with drowsy hit ratio around 2%.
0%
1%
2%
3%
4%
5%
6%
7%
1
6
8
.
w
u
p
w
i
s
e
1
7
1
.
s
w
i
m
1
7
2
.
m
g
r
i
d
1
7
3
.
a
p
p
l
u
1
7
7
.
m
e
s
a
1
7
8
.
g
a
l
g
e
l
1
7
9
.
a
r
t
1
8
3
.
e
q
u
a
k
e
1
8
7
.
f
a
c
e
r
e
c
1
8
9
.
l
u
c
a
s
2
0
0
.
s
i
x
t
r
a
c
k
3
0
1
.
a
p
s
i
A
v
e
r
a
g
e
R M R O -
1K SO W -
2K
Figure 6 – Drowsy hit ratio of RMRO versus SOW, with relative leakage consumption around 30%.
XVI Jornadas de Paralelismo, JP '2005 41
5. Conclusions
Drowsy caches place selected lines into a low-
power drowsy mode according to a given policy.
A successful policy should reduce the leakage
current while sustaining cache performance. In
this sense, drowsy caches should infrequently
access drowsy lines.
In a previous work we evaluated two simple
policies; i.e., MRO and TMRO, which maintain a
fixed number of active lines per set, i.e., one and
two, respectively. While the first one offers good
energy savings the second one provides excellent
hit ratio on awake lines. Due to its lack of
flexibility, i.e., the number of awake lines remains
constant through execution. We proposed the
RMRO policy, which awakes lines on-demand. In
addition, this policy makes use of reuse
information to improve the performance versus
energy tradeoff.
In this paper we propose a variant of the
RMRO policy, and evaluate it versus the SOW
policy recently proposed by Flautner et al in [4].
Performance and energy savings on these policies
depend on the switch-off interval. In this work we
perform a fair comparison study by firstly plotting
the energy savings to drowsy hit ratio curves
while varying the switch-off interval. In this way
we can properly chose the interval length for each
policy. Results show that the proposed policy
surpasses the performance of the SOW policy for
a fixed energy savings and vice versa.
The comparison process discussed here,
permits to predict which policies (if any) will
meet the performance and energy criteria provided
by the architect designer.
Acknowledgments
This work has been supported by the Generalitat
Valenciana under grant GV04B/487.
References
[1] Albonesi, D. H. Selective Cache Ways: On-
Demand Cache Resource Allocation. Journal
of Instruction-Level Parallelism, Vol. 2, 2000.
[2] Chen, C., Yang, S-H., Falsafi, B., and
Moshovos, A. Accurate and Complexity-
Effective Spatial Pattern Prediction. Proc. of
the 10th
Intl. Symp. on High Performance
Computer Architecture, Feb. 2004.
[3] Dropsho, S., Kursun, V., Albonesi, D. H.,
Dwarkadas, S., and Friedman, E. G. Managing
Static Leakage Energy in Microprocessor
Functional Units. Proc. of the 35th
Intl. Symp.
on Microarchitecture, Nov. 2002.
[4] Flautner, K., Kim, N. S., Martin, S., Blaauw,
D., and Mudge, T. Drowsy Caches: Simple
Techniques for Reducing Leakage Power.
Proc. of the 29th
Intl. Symp. on Computer
Architecture, May 2002.
[5] Kaxiras, S., HU, Z., and Martonosi, M. Cache
Decay: Exploiting Generational Behavior to
Reduce Cache Leakage Power. Proc. of the
28th
Intl. Symp. on Computer Architecture,
Jun. 2001.
[6] Kessler, R. E. The Alpha 21264
Microprocessor. IEEE Micro, Vol. 19, No. 2,
Mar. 1999.
[7] Li, L., Kadayif, I., Tsai, Y-F., Vijaykrishnan,
N., Kandemir, M., Irwin, M. J., and
Sivasubramania, A. Leakage Energy
Management in Cache Hierarchies. Proc. of
the 11th
Intl. Conf. on Parallel Architectures
and Compilation Techniques, Sep. 2002.
[8] McNairy, C. and Soltis, D. Itanium 2
Processor Microarchitecture. IEEE Micro,
Vol. 23, No. 2, Mar.-Apr. 2003.
[9] Powell, M., Yang, S.-H., Falsafi, B., Roy, K.,
and Vijaykumar, T. N. Gated-Vdd: A circuit
technique to reduce leakage in deep-
submicron cache memories. Proc. of the 2000
Intl. Symp. on Low Power Electronics and
Design, Jul. 2000.
[10] SIA, International Technology Roadmap for
Semiconductors, 2001.
[11] Tam, E. S., Rivers, J. A., Srinivasan, V.,
Tyson, G. S., and Davidson, E. S. Active
Management of Data Caches by Exploiting
Reuse Information. IEEE Transactions on
Computers, Vol. 48, No. 11, Nov. 1999.
[12] Petit, S., Sahuquillo, J., Such, J:M:, and
Kaeli, D., Exploiting Temporal Locality in
Drowsy Cache Policies, Proc. of the
Computing Frontiers, May 2005.
42 Arquitectura del Procesador y Multiprocesadores
Toward the Loop Processor Architecture (LPA)
Alejandro García and Pedro Medina and Adrián Cristal and
Oliverio J. Santana Enrique Fernández Mateo Valero
Dep. Arquitectura de Comp. Dep. Informática y Sistemas Barcelona Supercomputing Center &
Univ. Pol. de Catalunya Univ. Las Palmas de G.C. Dep. Arquitectura de Comp. (UPC)
{juanaleg,osantana}@ac.upc.edu {pmedina,efernandez}@dis.ulpgc.es {adrian,mateo}@ac.upc.edu
Abstract
Current processors frequently run applications
containing loops with just one execution path
(simple dynamic loops or SDLs). The execu-
tion of a SDL implies the repetitive execution
of the same group of instructions (loop instruc-
tions) during each iteration. Loop instructions
are fetched, decoded, and renamed for each it-
eration, wasting power and time.
In this paper, we show that a big part of this
work can be saved. We present the motiva-
tion for a novel architecture, the loop proces-
sor architecture (LPA). This architecture puts
loop instructions nearer to the ALUs, where
the computation actually happens, holding the
loop semantic inside the processor. In this
way, the processor does not need to fetch, de-
code, and rename loop instructions from the
cache for each loop iteration, since these in-
structions are already inside the processor,
ready to be dispatched to the queues. This
fact makes it possible to achieve an improve-
ment in both performance and power dissipa-
tion using LPA.
We have performed a preliminary evaluation
of the LPA through a detailed simulation of a
dynamically scheduled processor. The results
show an average reduction of accesses to in-
struction cache, instruction fetch, instruction
decode and to the mapping table of 15% in
SPEC-INT and 45% in SPEC-FP. In addition,
improving dispatch bandwidth through loop
window could gives an IPC increase up to 5%
in SPEC-INT and 18% in SPEC-FP.
1 Introduction
Previous works have shown that most applica-
tions execute a small set of their static instruc-
tions (only 10%) for the 90% of their runtime
[1] [2]. This is due to the fact that loops are
frequent entities in program execution. Part
of these loops contain just one execution path
(simple dynamic loops or SDLs). On aver-
age, SDLs are 28% and 60% of the execu-
tion time for SPECint2000 and SPECfp2000
benchmarks, respectively (Figure 1). The ex-
ecution of a SDL implies the repetitive execu-
tion of the same group of instructions (loop in-
structions) during each loop iteration. There-
fore, these instructions are fetched, decoded,
renamed and executed for each iteration, wast-
ing power and time.
A standard superscalar processor has no in-
formation about whether or not the individual
instruction belongs to a high-level computa-
tional entity like a loop. The trend in cur-
rent processors has been to get a large num-
ber of independent instructions, looking for its
parallel execution with the objective of make
the most of available instruction level paral-
lelism. These instructions are renamed, re-
moving all register dependences but the true
ones (RAW). Consequently, when an instruc-
tion reaches the processor execution engine, it
retains little or none algorithmic semantic in-
formation. Each instruction only remembers
its program order (kept in the reorder buer
or ROB) and the basic block it belongs (to
support speculation).
The problem is that recent years have wit-
Figure 1: Simple dynamic loops execution time
nessed an enormous growth of the distance be-
tween the memory and the ALUs (i.e., the
distance between where the instructions are
stored and where computation actually hap-
pens). This distance is measured in terms of
both the number of pipeline stages and the
complexity of the logic required to complete
instruction execution. For example, to get one
instruction renamed in one cycle it is needed
one access to read and update the mapping ta-
ble. However, to get two instructions renamed
in one cycle it is needed not only two accesses
to the mapping table, but also to access the
logic that determines and resolves the depen-
dence between both instructions. This makes
evidence that, as the processor width grows,
the logic required is more and more complex.
In this work, we present the motivation for
a method that captures and stores the re-
named instructions belonging to a SDL in a
buer called loop window. The aim is, rst, to
put the loop instructions nearer to the ALUs
where computation is done, and second, to re-
tain the execution semantic into the microar-
chitecture. In this way, the front-end require-
ments are reduced, since instruction issue is
done from the loop window, where the instruc-
tions are already renamed and ready to be
sent to the queues. Furthermore, this tech-
nique makes it possible to feed wider proces-
sor back-ends, that is, to increase the width of
the processor back-end without increasing the
width and complexity of the processor front-
end, and yet provide enough instructions to
the functional units to maintain them fully
used all the time. Therefore, our LPA archi-
tecture is able to reduce the processor power
dissipation without sacricing performance, or
even improving it.
The rest of this paper is organized as follows.
Section 2 addresses the motivation beneath
our approach. Section 3 describes our exper-
imental methodology. Section 4 presents one
of possible implementations of the LPA idea in
current architecture. Section 5 presents simu-
lation results and performance analysis. Sec-
tion 6 summarizes previous studies related to
this paper. Finally, section 7 draws the main
conclusions.
2 Motivation
The motivation for the loop window scheme
comes from the observation that many appli-
cations contain simple dynamic loops, so that
the same instructions are fetched, decoded and
renamed in each loop iteration. Figure 1 shows
the percentage of execution time of SDLs in
the SPECint2000 and SPECfp2000 programs.
The front-end structures involved in
processing the loop instructions (the L1
instruction cache, the branch predictor, and
the rename mapping table) are responsible for
much power dissipation within the processor.
Previous studies show that the amount of
power dissipated in these structures is quite
signicant: around 40%. The L1 instruction
cache is responsible for 10%20% of the over-
44 Arquitectura del Procesador y Multiprocesadores
all chip dissipation [3], the branch predictor
is responsible for 10% or more [4], and the
rename mapping table is responsible for 15%
[5].
As we will see in next sections, our novel
architecture is able to reduce the number of
accesses to these structures, and hence, the
power dissipation. For example, let us assume
the following sample loop:
...
loop: load r2,0(r4) (1)
load r3,0(r4) (2)
add r2,r3,r2 (3)
add r5,r5,r2 (4)
sub r4,r4,r1 (5)
bneqz r4,loop (6)
...
In a 6-instruction wide processor, these in-
structions can be fetched from the instruction
cache during the same cycle. At that time,
the loop branch instruction is predicted. This
prediction will always be taken because loop
branch instructions are strongly biased. Next,
the processor removes the name dependences
between the loop instructions by means of the
rename mapping table.
It should be taken into account that the loop
instructions do not access in parallel the map-
ping table for maintaining the order of instruc-
tions. For example, the instruction (3) write
in r2 immediately afterwards instruction (1).
Hence, the mapping register of every instruc-
tion could depend on the rest of instructions
mapped at the same cycle. For this reason,
the scalability of the mapping table is a criti-
cal issue for future processors.
In a conventional processor, a loop execut-
ing N iterations involves that the same instruc-
tions are fetched from the instruction cache,
the same loop branch is predicted, and the
same instructions are renamed once and again
during N cycles. However, if the loop is de-
tected and stored in the loop window, remov-
ing the name dependencies, the loop instruc-
tions can be dispatched from the loop window.
The instruction cache, the branch predictor,
and the mapping table are only used while
the loop window is being lled and initialized,
reducing the pressure on these critical struc-
tures.
3 Experimental methodology
Our simulation tool is a trace-driven version
of SMTSIM [6]. Our simulator permits execu-
tion along wrong speculative paths by means
of a separate basic block dictionary in which
the information of all static instruction is con-
tained. The baseline conguration is shown in
table 1.
We use SPEC2000 benchmarks as the test
suite for our simulations. Benchmarks were
compiled on a DEC Alpha AXP 21264 with
the standard DEC C V5.9-011 and Compaq
Fortran V5.3-915 compilers with -O2 opti-
mization level. The SPECfp2000 did not use
loop unrolling optimization in order to reduce
the loop body. Besides the loop window does
a particular dynamic loop unrolling. Due to
the large simulation time of SPEC2000 bench-
marks, traces of the most representative 300
slices have been collected, following the idea
presented in [7].
Processor Conguration
Pipeline depth 8 stages
Fetch/Dec./Rename Width = 4
Queues Entries 64 int, 64 fp, 64 ld/st
Execution Units 6 int, 6 fp, 6 ld/st
Physical Registers 128Int, 128FP
NRR 96Int, 96FP
ROB size 256 entries
Branch Prediction Conguration
Branch Predictor 16K entries gshare
Branch Target Buer 256-entry, 4-way associative
RAS 256 entries
Memory Conguration
Icache 64 Kbytes, 2-way, 8-bank,
128-byte lines, 1 cycle access
Dcache 32 Kbytes, 4-way, 8-bank,
128-byte lines, 1 cycle access
L2 cache 2 Mbytes, 10-way, 8-bank,
128-byte lines, 10 cycle ac-
cess
Main memory latency 100 cycles
TLB 48 entry I and 128 entry D
TLB miss penalty 160 cycles
Table 1: Baseline conguration
XVI Jornadas de Paralelismo, JP '2005 45
Figure 2: Pipeline stages
4 Processor model
The SMTSIM simulator implements an out-
of-order superscalar processor pipelined in 8
stages (we only use a single thread context).
Figure 2 shows a scheme of the processor
pipeline stages and gure 3 shows a scheme
of the processor architecture. The rst three
stages (fetch, decode, and rename) constitute
the processor front-end, where the instructions
ow from the memory hierarchy to the instruc-
tion window.
Figure 3: Loop processor architecture
The rst stage fetches instructions from
memory. The branch predictor avoids fetch
stalls due to control ow instructions, provid-
ing the information required to drive the in-
struction cache. The second stage is devoted
to decoding the opcode and operands of the
fetched instructions.
In the third stage, the name dependences
are eliminated through dynamic register re-
naming. This mechanism is able to provide
multiples storage locations (physical registers)
for the same logical register and keeps this
association in the rename mapping table. A
standard mapping table has an entry for each
logical register, which contains the associated
physical register. Hence, the physical registers
are localized in the dispatch stage, but unused
until the write stage. In order to improve this,
we use virtual registers [8][9] to delay register
allocation by decoupling dependency checks
from physical register assignments. Virtual
registers are tags used to track dependences
among instructions whereas physical registers
are used to store live value of instructions.
Therefore, our processor model removes
name dependences through mapping logical
register to virtual registers using the Virtual
Mapping Table (VMT). Renamed instructions
are stored in the reorder buer (ROB) for pre-
serving the execution order and support pre-
cise interrupts. Renamed instructions are also
stored in the instruction queues until these
instructions are selected to be issued by the
wake-up select logic.
The loop window used by LPA substitutes
the three pipeline stages of the processor front-
end, since the instructions stored in the loop
window are already renamed (see gure 2). In
this way, loop instructions can be dispatched
to the queues and the ROB without being
fetched, decoded, and renamed (see gure 3).
Due to space limitations, we do not provide
deep details about the implementation of LPA,
which can be found in [10].
The remaining ve stages (issue, read, exe-
cute, write and commit) constitute processor
46 Arquitectura del Procesador y Multiprocesadores
Figure 4: Redution of work in the front-end
back-end or execution engine. Instructions are
executed in these stages: their source operands
are read and their destination operands are
written. Instructions are executed out-of-
order, that is, when all their source operands
are available and there is a free functional unit.
The fourth stage wake-ups and selects in-
structions stored in the instruction queues
(load/store queue, oating point queue and in-
teger queue) in order to be executed by the
functional units. Physical registers are allo-
cated when instructions are issued, and thus
an instruction can only be issued if there is a
free physical register. When a physical register
is allocated, the mapping virtual to physical
registers is updated in the Physical Map Ta-
ble (PMT). This mapping table is less complex
than the VMT because the name dependences
have just resolved and the number of entries
is equal to number of physical registers, which
is much lower than the number of virtual reg-
isters.
The following three stages (execute, write
and commit) are devoted to execute and com-
plete the execution of the instructions. The
commit stage is the last one, where instruc-
tions are committed in order as in a standard
superscalar processor.
5 LPA evaluation
Since the loop window keeps already renamed
instructions, our LPA is able to reduce the
amount of work done by the processor front-
end, and thus its power dissipation. In order
to evaluate this reduction, we have explored
several loop window setups, from 32 to 256 en-
tries and there are not signicant dierences
between 128 or 256 entries. Hence, we have
chosen as optimal size 128 instruction entries.
Figure 4 shows the reduction of accesses to
the main front-end structures using LPA. It
becomes clear that our technique is especially
ecient for the SPECfp2000 programs. For
instance, swim and mgrid achieve 95% reduc-
tion in the work done by the front-end due to
the great amount of SDLs these benchmarks
have. On average, the front-end work is re-
duced 45% for oating point programs, while
just 15% for integer programs due to the lower
amount of SDLs.
Nevertheless, reducing the work done by the
front-end is not the only benet achievable by
LPA. Although our baseline processor setup is
4-instruction wide, we have evaluated the per-
formance improvement achievable by enabling
the loop window to dispatch six instructions
per cycle. Allowing this increase is straight-
forward, since it is not necessary to modify
all the front-end structures, which are on the
critical path, but only the loop window.
Figure 5 shows the performance improve-
ment achievable by the 4-wide baseline proces-
sor when using a loop window able to provide
6 instructions per cycle. For comparison pur-
poses, we also show the improvement achiev-
able by increasing the processor width to 6 in-
structions. It should be highlighted that some
benchmarks, such as 187.facerec, 301.apsi and
176.gcc, achieve a similar improvement using
XVI Jornadas de Paralelismo, JP '2005 47
Figure 5: LPA IPC speedup
the loop window than using the wider front-
end, while requiring less complexity and en-
ergy.
However, other benchmarks, such as
171.swim, 172.mgrid, and 178.galgel, do not
achieve signicant performance improvement
despite of their great amount of SDLs. This
happens because the processor back-end is sat-
urated 60% of the time [10]. In order to
show the potential improvement achievable,
gure 6 shows data using a perfect back-end.
Now, the benchmarks 171.swim, 172.mgrid,
and 178.galgel achieve an IPC speedup even
greater than the 6-wide processor. The main
reason is that the loop instructions frequently
do not perfectly t to cache blocks, while the
loop window store scheme eliminates this ef-
fect. These data shows that LPA is able to
provide good performance results at a lower
power dissipation, and thus it is an interesting
eld for future research.
6 Related work
The reuse of fetched instructions using loops
is not a new technique. In the 1960's, loop
buers were developed for the CDC 6600/6700
series [11] with the objective of minimizing
the time wasted due to conditional branches,
which could severely limit the total CPU per-
formance in short loop programs. Also in
the sixties, the IBM/360 model 91 introduced
the loop mode execution as a way of reduc-
ing the eective fetch bandwidth requirements
[12][13]. When a loop was detected in the eight
words prefetch buer, the "loop mode" came
to active status; the branch prediction was
toggle from "predict-not-taken" to "predict-
taken" and the instructions fetch from mem-
ory was stopped. They claim that the "loop
mode" was active 30% of execution time on
average.
Nowadays, hardware-based loop caching has
been mainly used in embedded systems to re-
duce the instruction fetch power dissipation.
These mechanisms use a SDL buer that iden-
ties, captures, and process SDL structures
during the processor execution [14]. More re-
cent designs [15] capture and process com-
plex loop structures using a nite state ma-
chine that provides more sophisticated utiliza-
tion of the loop buer memory (DLB con-
troller). Other designs such as CONDEL [16]
and LEVO [17] use static instruction order
to reduce the ill eects of branches. Hence,
the fetched instructions are reused capturing
loop structures. However, unlike our proposal,
these techniques do not deal with renaming
loop instructions.
A dierent approach, dynamic vectoriza-
tion [18][19], increases the available instruc-
tion level parallelism by extending the logical
instruction window. The key idea is to detect
repetitive control ow at runtime and capture
in the instruction window the corresponding
dynamic loop body in vector form. Multi-
ple loop iterations are issued from the single
copy of the loop body in the instruction win-
dow. Using a local register le for each loop
trace, where the physical registers are queues
48 Arquitectura del Procesador y Multiprocesadores
Figure 6: LPA unbounded back-end IPC speedup
to write the results of the loop instructions
in each iteration. Therefore, the register map-
ping is more complex because it is necessary to
decide whether the logical register is mapped
to the global register le or to a local regis-
ter le. In order to reduce the complexity of
the register mapping, a cache of renamed in-
structions is introduced in the design. On the
contrary, our mechanism maintains inalterable
the logic of critical structures such as the re-
name mapping logic and the register le.
7 Conclusions
In this paper, we show that a mechanism to
dynamically capture SDLs (loops with only
one path) will be a worthwhile contribution
for superscalar processor designs. This mech-
anism is based on the combination of three key
ideas. First, to store the body of a SDL after
the rename stage, where loop instructions are
already decoded and their name dependences
have been resolved. Second, to decouple the
rename process from the physical register as-
signment. And third, to do a generic renaming
that will be valid for all loop iterations.
The originality of the proposed idea lies in
the ability of capturing the loop body in a
buer (loop window), renaming instructions
by mapping logical to virtual registers. In
this way, we reduce the power dissipation of
the processor front-end due to a lower num-
ber of accesses to the branch predictor, the
instruction cache, and the rename mapping
table. Moreover, the dispatch bandwidth of
SDLs can be augmented without increasing
the front-end width, since instructions can be
dispatched from the loop window at a higher
rate. As a consequence, our proposal is not
only able to reduce the power dissipation of the
processor front-end for a given performance
level, but it is also able to improve the overall
processor performance.
Acknowledgements
This work has been supported by the Ministry
of Education of Spain under contract TIN
200407739C0201, the HiPEAC European
Network of Excellence, the CEPBA, and the
Barcelona Supercomputing Center. The au-
thors would like to thank to Daniel Ortega
and Francisco J. Cazorla for their comments
and support.
References
[1] P.J. Denning. The working Set Model for
Program Behavior. ACM Symposium on
Operating System. 1967.
[2] Marcos R. de Alba and David R. Kaeli.
Runtime Predictability of Loops. In the
IEEE 4th Annual Workshop on Workload
Characterization, held with the 34th An-
nual International Symposium on Microar-
chitecture, December 2001.
[3] A. Badulescu and A. Veidenbaum. Energy
Ecient Instruction Cache for Wide-issue
XVI Jornadas de Paralelismo, JP '2005 49
Processors. International Workshop on In-
novative Architecture, 2001.
[4] D. Parikh, K. Skadron, Y. Zhang, M. Bar-
cella and M. Stan. Power Issues Related to
Branch Prediction. 8th International Sym-
posium on High-Performance Computer
Architecture, 2002.
[5] Daniele Folegnani and Antonio González.
Energy-eective issue logic. 28th Interna-
tional Symposium on Computer Architec-
ture, 2001.
[6] D. Tullsen, S. J. Eggers and H. M. Levy.
Simultaneous multithreading: Maximiz-
ing on chip parallelism. 22nd Interna-
tional Symposium on Computer Architec-
ture, 1995.
[7] T. Sherwood, E. Perelman and Brad
Calder. Basic block distribution analysis
to nd periodic behaviour and simulations
points applications. International Confer-
ence on Parallel Architectures and Compi-
lation Techniques, 2001.
[8] A. González, J. González and M. Valero.
Virtual-Physical Registers. International
Symposium on High Performance Com-
puter architecture, 1998.
[9] T. Monreal, A. González, M. Valero, J.
González, V. Viñals. Delaying physical
register allocation through virtual-physical
registers. Proceedings of the 32nd annual
ACM/IEEE international symposium on
Microarchitecture,1999.
[10] A. García, O.J. Santana, E. Fernández,
P. Medina, A. Cristal, and M. Valero.
Loop Processor Architecture: A Novel Ap-
proach. Technical Report UPC-DAC-RR-
2005-28, Departament d'Arquitectura de
Computadors, Universitat Politècnica de
Catalunya, 2005.
[11] J.E. Thornton. Parallel operation in the
control data 6600. In AFIPS Proc. FJCC,
vol 26:2, pp. 33-40, 1964.
[12] R.M. Tomasulo. An Ecient Algorithm
for Exploiting Multiple Arithmetic Units.
IBM Journal of Research and Develop-
ment, pp. 25-33, January 1967.
[13] D.W. Anderson, F.J. Sparacio, and R.M.
Tomasulo. The IBM System/360 Model
91: Machine Philosophy and Instruction-
Handling. IBM J. Research and Develop-
ment, vol 11:1, January 1967.
[14] L.H. Lee, W. Moyer and J. Arends.
Instruction Fetch Energy Reduction Us-
ing Loop Caches for Embedded Applica-
tions with Small Tight Loops. Interna-
tional Symposium on Low Power Electron-
ics and Design (ISLPED), 1999.
[15] J.A. Rivers, S. Asaad, J.D. Wellman and
J.H. Moreno. Reducing Instruction Fetch
Energy with Backward Branch Control
Information and Buering. International
Symposium on Low Power Electronics and
Design (ISLPED), 2003.
[16] A.K. Uht. Concurrency Extraction via
Hardware Methods Executing the Static
Instruction Stream. IEEE Transaction on
Computers, vol.41, 1992.
[17] A. K. Uht, D. Morano, A. Khala, M.
de Alba, T. Wenisch, M. Ashouei and
D. Kaeli. Levo: IPC in the 10's via Re-
source Flow Computing.PACT 2001 Work-
In-Progress (WIP) Session, 2001.
[18] S. Vajapeyam and T. Mitra. Improving
Superscalar Instruction Dispatch and Issue
by Exploiting Dynamic Code Sequences.
24th International Symposium on Com-
puter Architecture, 1997.
[19] S. Vajapeyam, P.J. Joseph and T. Mitra.
Dynamic Vectorization: A Mechanism for
Exploiting Far-Flung ILP in Ordinary Pro-
grams. 26th International Symposium on
Computer Architecture, 1999.
50 Arquitectura del Procesador y Multiprocesadores

       
 
               
              
            !   "  # $ " % & '  (   % !
1 # )    * + %  %   ,  - % !
  - .  / %  0  " %  
1 1 2 3 4 5 6 7 3 8 9 8 8 5 : 9 7 ; 9 < = 9 7 8 5 > 6 9 2 ? 9 2 9 6 3 9
1 2 3 4 5 6 7 3 @ 9 @ ; A < 3 @ B C 2 3 C 9 8 5 ? 9 @ 9 < D 2 E 9 F G 8 3 H C 3 A 8 5 I 2 J A 6 = K @ 3 C 9 E L 9 @ 5 = K @ 3 C 9 7
M
A 6 8 3 > 3 6 A 2 9 N O P F Q R Q P S T 9 6 C 5 < A 2 9 F U V 9 3 2 F ? 9 = V D 7 1 2 3 4 5 6 7 3 @ 9 6 3 A 8 5 W 9 H 6 9 F
X
J C 9 Y A 6 < 9 Z 9 6 9 = 3 6 5 Y Z = 9 @ 5 A [ \ 9 C F D V C F 5 8 D P ] Q N ^ F : 9 7 ; 9 < = 9 7 8 5 > ? F U V 9 3 2 F
1 T 9 6 C 5 < A 2 9 U D V 5 6 C A = V D @ 3 2 _ ? 5 2 @ 5 6 Z T 9 6 C 5 < A 2 9 F U V 9 3 2 F 5 J 5 6 2 9 2 8 5 Y \ 8 3 7 F D < V _ C F 5 7
` a b c d e f c
g h i j k l m n o o l k o p q m k n r o n j n k s l k t r q m n u v n w x
n m y z p q { p q o z k y m z p l q o s k l t o n | n k r } z ~ k n r  o o p x
t y } z r q n l y o } v € i ~ n o n z ~ k n r  o y o n z ~ n k n x
o l y k m n o l s z ~ n j k l m n o o l k u n z z n k u v o ~ r k p q {
z ~ n t u y z  r z z ~ n o r t n z p t n  m l t j n z n s l k
z ~ n t € i ~ n ‚ r v m k p z p m r } k n o l y k m n o r k n  p o x
z k p u y z n  r t l q { z ~ k n r  o  n z n k t p q n o z ~ n ƒ q r }
j n k s l k t r q m n € „ y k k n q z } v  j k l m n o o l k k n o l y k m n o
r k n  p o z k p u y z n  r t l q { z ~ k n r  o r o  n z n k t p q n 
u v z ~ n s n z m ~ j l } p m v z ~ r z  n m p  n o ‚ ~ p m ~ z ~ k n r  o
n q z n k z ~ n j k l m n o o l k z l m l t j n z n s l k k n o l y k m n o €
…
l ‚ n | n k  s n z m ~ j l } p m p n o l q } v y o n p q  p k n m z p q  p x
m r z l k o l s k n o l y k m n y o r { n p q z ~ n p k  n m p o p l q € i ~ p o
m r q } n r  z l k n o l y k m n t l q l j l } p † r z p l q u v r o p q { } n
z ~ k n r  l k z l k n o l y k m n y q  n k x y z p } p † r z p l q  m r y o x
p q { j n k s l k t r q m n  n { k r  r z p l q €
‡
q z ~ p o j r j n k  ‚ n p q z k l  y m n z ~ n m l q m n j z l s
 v q r t p m k n o l y k m n m l q z k l } p q g h i j k l m n o o l k o €
ˆ
o p q { z ~ p o m l q m n j z  ‚ n j k l j l o n r q l | n } k n x
o l y k m n r } } l m r z p l q j l } p m v s l k g h i j k l m n o o l k o €
i ~ p o j l } p m v  p k n m z } v t l q p z l k o z ~ n y o r { n l s k n x
o l y k m n o u v n r m ~ z ~ k n r  r q  { y r k r q z n n o z ~ r z r } }
z ~ k n r  o { n z z ~ n p k s r p k o ~ r k n l s m k p z p m r } o ~ r k n 
k n o l y k m n o  r | l p  p q { t l q l j l } p † r z p l q € ‰ n r } o l
 n ƒ q n r t n m ~ r q p o t z l r } } l ‚ r z ~ k n r  z l u l k x
k l ‚ k n o l y k m n o s k l t r q l z ~ n k z ~ k n r  p s z ~ r z
z ~ k n r   l n o q l z k n Š y p k n z ~ n t  z ~ n k n u v k n  y m x
p q { k n o l y k m n y q  n k x y o n € ‹ y k k n o y } z o o ~ l ‚ z ~ r z
l y k  v q r t p m k n o l y k m n r } } l m r z p l q j l } p m v l y z j n k x
s l k t o z ~ n u n o z k n o l y k m n x m l q o m p l y o s n z m ~ j l } p x
m p n o } p Œ n  Ž
ˆ
g
…  
u v  ‘  l q r | n k r { n  ‚ ~ p } n
 l n o q l z k n Š y p k n ’ y o ~ p q { p q o z k y m z p l q o s k l t z ~ n
j p j n } p q n €
“ ” •
c d – — ˜ f c ™ –
•
g y j n k o m r } r k
j k l m n o o l k o p q m k n r o n j n k s l k t r q m n
u v n w j } l p z p q { p q o z k y m z p l q } n | n } j r k r } } n } p o t
š
‡
Ž › œ ‚ p z ~ p q r o p q { } n r j j } p m r z p l q €
…
l ‚ n | n k 
 r z r r q  m l q z k l }  n j n q  n q m n o k n  y m n z ~ n
‡
Ž ›
l s r j j } p m r z p l q o €  o r k n o y } z  ‚ ~ n q z ~ n r | r p } x
r u } n
‡
Ž › p o q l z ~ p { ~ n q l y { ~  t r q v j k l m n o o l k
k n o l y k m n o k n t r p q p  } n r q   l q l z m l q z k p u y z n
z l j n k s l k t r q m n € g p t y } z r q n l y o t y } z p z ~ k n r  n 
š
g h i œ j k l m n o o l k o n w n m y z n p q o z k y m z p l q o s k l t
t y } z p j } n z ~ k n r  o r z z ~ n o r t n z p t n  o l z ~ r z
z ~ n m l t u p q n 
‡
Ž › l s t y } z p j } n z ~ k n r  o r } } l ‚ o
r ~ p { ~ n k y o r { n l s k n o l y k m n o  p q m k n r o p q { j n k s l k x
t r q m n ž Ÿ   ž ¡   ž ¢ £   €
…
l ‚ n | n k  z ~ k n r  o q l z l q } v
o ~ r k n k n o l y k m n o  z ~ n v r } o l m l t j n z n s l k z ~ n t €
‡
q m y k k n q z g h i o  k n o l y k m n  p o z k p u y z p l q
r t l q { z ~ k n r  o p o n p z ~ n k o z r z p m l k s y } } v  v x
q r t p m €  o z r z p m k n o l y k m n  p o z k p u y z p l q
š
y o n  
s l k n w r t j } n  p q z ~ n › n q z p y t  œ n | n q } v o j } p z o
z ~ n k n o l y k m n o r t l q { z ~ n k y q q p q { z ~ k n r  o € i ~ p o
n q o y k n o z ~ r z q l o p q { } n z ~ k n r  t l q l j l } p † n o z ~ n
k n o l y k m n o r q  z ~ r z r } } z ~ k n r  o r k n z k n r z n 
n Š y r } } v € i ~ p o o m ~ n t n o y ¤ n k o z ~ n o r t n j k l u } n t
r o r o y j n k o m r } r k j k l m n o o l k ¥ p s r q v z ~ k n r   l n o
q l z s y } } v y o n z ~ n r } } l m r z n  k n o l y k m n o  z ~ n o n r k n
‚ r o z n  r q   l q l z m l q z k p u y z n z l j n k s l k t r q m n €
¦
v q r t p m o ~ r k p q { l s k n o l y k m n o p o r m m l t j } p o ~ n 
u v k y q q p q { r } } z ~ k n r  o p q r m l t t l q k n o l y k m n
j l l } r q  r } } l ‚ p q { z ~ k n r  o z l s k n n } v m l t j n z n s l k
z ~ n t €
‡
q r  v q r t p m r } } v o ~ r k n  n q | p k l q t n q z  p z
p o z ~ n s n z m ~
š
‡
x s n z m ~ œ j l } p m v z ~ r z r m z y r } } v m l q x
z k l } o ~ l ‚ k n o l y k m n o r k n o ~ r k n  € i ~ n
‡
x s n z m ~
j l } p m v  n z n k t p q n o ‚ ~ p m ~ z ~ k n r  o m r q n q z n k z ~ n
j k l m n o o l k z l { n z z ~ n l j j l k z y q p z v l s y o p q { r | r p } x
r u } n k n o l y k m n o €
…
l ‚ n | n k  m y k k n q z s n z m ~ j l } p x
m p n o  l q l z n w n k m p o n  p k n m z m l q z k l } l | n k ~ l ‚ k n x
o l y k m n o r k n  p o z k p u y z n  r t l q { z ~ k n r  o  y o p q {

 
p q  p k n m z p q  p m r z l k o l s j l z n q z p r } k n o l y k m n
r u y o n u v r { p | n q z ~ k n r   } p Œ n Ž  m r m ~ n t p o o n o €

n m r y o n q l  p k n m z m l q z k l } l | n k k n o l y k m n o p o n w x
n k m p o n   p z p o o z p } } j l o o p u } n z ~ r z r z ~ k n r  ‚ p } }
l u z r p q t l o z l s z ~ n j k l m n o o l k k n o l y k m n o  m r y o x
p q { l z ~ n k z ~ k n r  o z l o z r } } €  } o l  z l t r Œ n z ~ p q { o
‚ l k o n  p z p o r m l t t l q o p z y r z p l q z ~ r z z ~ n z ~ k n r 
‚ ~ p m ~ ~ r o u n n q r } } l m r z n  t l o z l s z ~ n k n o l y k m n o
‚ p } } q l z k n } n r o n z ~ n t s l k r } l q { j n k p l  l s z p t n €
i ~ n k n ~ r | n u n n q s n z m ~ j l } p m p n o j k l j l o n  ž    ž   
z ~ r z z k v z l  n z n m z z ~ p o o p z y r z p l q  p q l k  n k z l
j k n | n q z p z u v o z r } } p q { z ~ n z ~ k n r  u n s l k n p z p o
z l l } r z n  l k n | n q z l m l k k n m z z ~ n o p z y r z p l q u v
o Š y r o ~ p q { z ~ n l ¤ n q  p q { z ~ k n r  z l t r Œ n p z o
k n o l y k m n o r | r p } r u } n z l l z ~ n k z ~ k n r  o ž     ‚ p z ~
| r k v p q {  n { k n n o l s o y m m n o o € i ~ n t r p q j k l u x
} n t l s z ~ n o n j l } p m p n o p o z ~ r z p q z ~ n p k r z z n t j z z l
j k n | n q z k n o l y k m n t l q l j l } p † r z p l q  z ~ n v t r v p q x
z k l  y m n k n o l y k m n y q  n k x y o n  u n m r y o n z ~ n v m r q
j k n | n q z r z ~ k n r  s k l t y o p q { k n o l y k m n o z ~ r z q l
l z ~ n k z ~ k n r  k n Š y p k n o €
‡
q z ~ p o j r j n k  ‚ n o ~ l ‚ z ~ r z z ~ n j n k s l k t r q m n
l s r q g h i j k l m n o o l k m r q o p { q p ƒ m r q z } v u n p t x
j k l | n  p s r  p k n m z m l q z k l } l s k n o l y k m n r } } l m r x
z p l q p o n w n k m p o n  € ‹ q z ~ n l q n ~ r q   r z r q v
{ p | n q z p t n   k n o l y k m n ~ y q { k v  z ~ k n r  o t y o z u n
s l k m n  z l y o n r } p t p z n  r t l y q z l s k n o l y k m n o €
‹ z ~ n k ‚ p o n  z ~ n v m l y }  t l q l j l } p † n o ~ r k n  k n x
o l y k m n o € ‹ q z ~ n l z ~ n k ~ r q   p q l k  n k z l r } } l ‚
k n o l y k m n ~ y q { k v z ~ k n r  o z l n w j } l p z
‡
Ž › t y m ~
u n z z n k  ‚ n o ~ l y }  r } } l ‚ z ~ n t z l y o n r o t r q v
k n o l y k m n o r o j l o o p u } n ‚ ~ p } n z ~ n o n k n o l y k m n o r k n
q l z k n Š y p k n  u v z ~ n l z ~ n k z ~ k n r  o € i ~ p o p o z ~ n
z k r  n x l ¤ r   k n o o n  p q z ~ p o j r j n k €
‡
q l k  n k z l m l q z k l } z ~ n r t l y q z l s k n o l y k m n o
{ p | n q z l n r m ~ z ~ k n r   ‚ n p q z k l  y m n z ~ n m l q x
m n j z l s r




 
  

 


€  k n o l y k m n
r } } l m r z p l q j l } p m v m l q z k l } o z ~ n s n z m ~ o } l z o  r o
p q o z k y m z p l q s n z m ~ j l } p m p n o  l  u y z p q r   p z p l q
p z n w n k m p o n o r  p k n m z m l q z k l } l | n k 
 
o ~ r k n 
k n o l y k m n o € i ~ p o  p k n m z m l q z k l } r } } l ‚ o r u n z x
z n k y o n l s k n o l y k m n o  k n  y m p q { k n o l y k m n y q  n k x
y z p } p † r z p l q € ‰ n j k l j l o n o y m ~ r k n o l y k m n r } } l m r x
z p l q j l } p m v m r } } n 
¦
v q r t p m r } } v „ l q z k l } } n   n x
o l y k m n  } } l m r z p l q
š
¦
„   œ €
¦
„   ƒ k o z m } r o x
o p ƒ n o z ~ k n r  o r m m l k  p q { z l z ~ n r t l y q z l s k n x
o l y k m n o z ~ n v k n Š y p k n € i ~ p o m } r o o p ƒ m r z p l q j k l x
| p  n o
¦
„   ‚ p z ~ r | p n ‚ l s z ~ n  n t
r q  z ~ r z
z ~ k n r  o ~ r | n l s n r m ~ k n o l y k m n €  n w z  u r o n 
l q z ~ n j k n | p l y o m } r o o p ƒ m r z p l q 
¦
„    n z n k x
t p q n o ~ l ‚ n r m ~ k n o l y k m n o ~ l y }  u n  p o z k p u y z n 
r t l q { z ~ k n r  o €  p q r } } v  n r m ~ m v m } n
¦
„  
 p k n m z } v t l q p z l k o k n o l y k m n y o r { n  ‚ p z ~ l y z k n x
} v p q { n q z p k n } v l q p q  p k n m z p q  p m r z l k o €
…
n q m n 
p z p t t n  p r z n } v  n z n m z o z ~ r z r z ~ k n r  p o n w x
m n n  p q { p z o r o o p { q n  r } } l m r z p l q r q  o z r } } o z ~ r z
z ~ k n r  y q z p } p z q l } l q { n k n w m n n  o p z o r } } l m r x
z p l q € ‹ y k k n o y } z o o ~ l ‚ z ~ r z l y k
¦
„   j l } x
p m v l y z j n k s l k t o z ~ n u n o z  v q r t p m k n o l y k m n x
m l q o m p l y o s n z m ~ j l } p m p n o } p Œ n  Ž
ˆ
g
…  
ž ¢   p q
u l z ~ z ~ k l y { ~ j y z r q  s r p k q n o o ž    € i ~ k l y { ~ j y z
k n o y } z o o ~ l ‚ z ~ r z
¦
„   p t j k l | n o  Ž
ˆ
g
…  
u v ¢ ‘  l q r | n k r { n €  r p k q n o o k n o y } z o  y o x
p q { z ~ n ~ r k t l q p m t n r q r o r t n z k p m  p q  p x
m r z n z ~ r z
¦
„   l y z j n k s l k t o  Ž
ˆ
g
…  
u v
 ‘  l q r | n k r { n €

l z ~ k n o y } z o m l q ƒ k t z ~ r z
¦
„   r m ~ p n | n o u n z z n k z ~ k l y { ~ j y z z ~ r q z ~ n
l z ~ n k j l } p m p n o r q  p q r   p z p l q j k n o n q z o r u n z z n k
z ~ k l y { ~ j y z x s r p k q n o o u r } r q m n z ~ r q z ~ n t €
i ~ n k n t r p q  n k l s z ~ p o j r j n k p o o z k y m z y k n 
r o s l } } l ‚ o ¥ o n m z p l q  j k n o n q z o l y k q n ‚ j l } p m v €
‡
q o n m z p l q   ‚ n n w j } r p q z ~ n n w j n k p t n q z r } n q x
| p k l q t n q z € g n m z p l q o  j k n o n q z o z ~ n o p t y } r z p l q
k n o y } z o € „ l q m } y o p l q o r k n { p | n q p q g n m z p l q  €
      
`  –  ™ f 
i l j n k s l k t r q n m p n q z k n o l y k m n r } } l m r z p l q  p z
p o q n m n o o r k v z l z r Œ n p q z l r m m l y q z z ~ n  p ¤ n k n q z
n w n m y z p l q j ~ r o n o l s r z ~ k n r  € h l o z z ~ k n r  o
~ r | n  p ¤ n k n q z u n ~ r | p l k j r z z n k q o  y k p q { z ~ n p k
n w n m y z p l q ¥ z ~ n v r } z n k q r z n ~ p { ~
‡
Ž › j ~ r o n o r q 
t n t l k v x u l y q  n  j ~ r o n o ‚ p z ~ s n ‚ j r k r } } n } p o t 
r q  z ~ y o z ~ n p k k n o l y k m n q n n  o m ~ r q { n  v q r t p x
m r } } v € ‰ n t y o z z r Œ n p q z l r m m l y q z z ~ p o | r k v p q {
u n ~ r | p l k p q l k  n k z l r } } l m r z n k n o l y k m n o ‚ ~ n k n
z ~ n v ‚ p } } u n u n o z y o n   r q  r } o l z l r } } l m r z n
k n o l y k m n o ‚ ~ n k n z ~ n v r k n q n n  n  t l o z €
¦
„    v q r t p m r } } v m } r o o p ƒ n o z ~ k n r  o u r o n 
l q z ~ n n w n m y z p l q j ~ r o n z ~ n v r k n p q  ~ p { ~
‡
Ž ›
l k t n t l k v x u l y q  n 
š
g n m z p l q  € ¢ € ¢ œ €  n w z 
‚ n  n z n k t p q n ‚ ~ p m ~ k n o l y k m n o r k n u n p q { y o n 
u v n r m ~ z ~ k n r  p q z ~ n j ~ r o n p z p o p q
š
g n m x
z p l q  € ¢ €  œ €  s z n k z ~ r z 
¦
„   y o n o r o ~ r k p q {
t l  n } z l r } } l m r z n k n o l y k m n o z l z ~ k n r  o u r o n 
52 Arquitectura del Procesador y Multiprocesadores
l q z ~ n m } r o o p ƒ m r z p l q j k n | p l y o } v t r  n
š
g n m z p l q
 €  œ €  p q r } } v  z ~ n o ~ r k p q { t l  n } r } o l n q o y k n o
z ~ r z z ~ k n r  o  l q l z n w m n n  z ~ n p k r } } l m r z n  k n x
o l y k m n o €
0.6
0.65
0.7
0.75
0.8
0.85
0.9
0.95
1
12.5 25 37.5 50 62.5 75 87.5 100
% of resources given to threads
%
of
full
speed
Integer IQ
Load/Store IQ
FP IQ
Integer Registers
FP Registers
3 _ D 6 5 N
 4 5 6 9 _ 5 I ; ? A J U ; G ?  5 2 C  = 9 6  7 9 7  5
4 9 6 E @  5 9 = A D 2 @ _ 3 4 5 2 @ A @  5 =   5 2 @  5 8 9 @ 9 : N
C 9 C  5 3 7 V 5 6 J 5 C @ F
‹ y k t l  n } u r o n o l q z ~ n s r m z z ~ r z z ~ k n r  o
‚ p z ~ l y z l y z o z r q  p q { Ž  t p o o n o k n Š y p k n s n ‚ n k
k n o l y k m n o z l n w j } l p z
‡
Ž › z ~ r q z ~ k n r  o ‚ p z ~ Ž 
t p o o n o €  p { y k n ¢ o ~ l ‚ o z ~ n r | n k r { n
‡
› „ r o ‚ n
| r k v z ~ n r t l y q z l s k n o l y k m n o { p | n q z l g ›  „
 £ £ £ u n q m ~ t r k Œ o ‚ ~ n q n w n m y z n  p q o p q { } n x
z ~ k n r  t l  n r q  z ~ n  r z r Ž ¢ m r m ~ n p o j n k x
s n m z  €  l k z ~ p o n w j n k p t n q z ‚ n y o n ¢ £ j ~ v o x
p m r } k n { p o z n k o    x n q z k v p o o y n Š y n y n o  r q  z ~ n
k n t r p q  n k j r k r t n z n k o l s l y k u r o n } p q n m l q ƒ { y x
k r z p l q o ~ l ‚ q p q g n m z p l q  €  l k n w r t j } n  z ~ n
j l p q z   ‘ s l k z ~ n p q z n { n k
‡

o ~ l ‚ o z ~ n r | x
n k r { n
‡
› „ ‚ ~ n q u n q m ~ t r k Œ o r k n r } } l ‚ n  z l
y o n   ‘ l s z ~ n p q z n { n k
‡

r q  r } } l z ~ n k k n x
o l y k m n o €
‡
q { n q n k r } ‚ n o n n z ~ r z ‚ p z ~ s n ‚ k n x
o l y k m n o z ~ k n r  o k y q r z r } t l o z z ~ n o r t n o j n n 
z ~ r q ‚ ~ n q z ~ n v y o n r } } z ~ n k n o l y k m n o l s z ~ n
t r m ~ p q n
š
s y } } o j n n  œ € ‰ n o n n z ~ r z l q } v ‚ p z ~
  €  ‘ l s k n o l y k m n o
š
¢ 
‡

n q z k p n o r q  £ j ~ v o x
p m r } k n { p o z n k o œ z ~ k n r  o k y q r z r j j k l w p t r z n } v
¡ £ ‘ l s z ~ n p k s y } } o j n n  €
‹ y k l u  n m z p | n p o z l { p | n r   p z p l q r } k n o l y k m n o
z l t n t l k v x u l y q  z ~ k n r  o r o z ~ n o n k n o l y k m n o
r k n m } n r k } v q l z q n n  n  u v z ~ k n r  o ‚ p z ~ l y z l y z x
o z r q  p q { m r m ~ n t p o o n o €

v { p | p q { t l k n k n x
o l y k m n o z l t p o o p q { z ~ k n r  o ‚ n l u z r p q u n q n ƒ z o
                                      

                 !    "     #  "   $ 
r o ‚ n { p | n z ~ n l y z x l s x l k 
n k t n m ~ r q p o t t l k n
l j j l k z y q p z v z l l | n k } r j t y } z p j } n Ž  t p o o n o  p q x
m k n r o p q { z ~ n t n t l k v j r k r } } n } p o t l s z ~ n r j j } p x
m r z p l q ‚ p z ~ l y z k n r } } v ~ r k t p q { z ~ n j n k s l k t r q m n
l s z ~ n k n t r p q p q { z ~ k n r  o €
% & ' ( ) * + , - . / , 0 0 1 2 . , 3 1 4 5
¦
„   m } r o o p ƒ n o z ~ k n r  o u r o n  l q ~ l ‚ t r q v
k n o l y k m n o z ~ n v q n n  z l n m p n q z } v n w j } l p z
‡
Ž ›
 n j n q  p q { l q z ~ n j ~ r o n p q ‚ ~ p m ~ r z ~ n z ~ k n r 
p o € h l k n l | n k  n r m ~ z ~ k n r  p o m } r o o p ƒ n   n x
j n q  p q { l q ‚ ~ p m ~ m k p z p m r } k n o l y k m n o p z r m z y x
r } } v y o n o r q  ‚ ~ p m ~ k n o l y k m n o p z  l n o q l z q n n  €
i ~ n
¦
„   m } r o o p ƒ m r z p l q p o m l q z p q y l y o } v k n x
n | r } y r z n  z l r  r j z z l z ~ n m ~ r q { p q { u n ~ r | p l k
l s z ~ k n r  o €
…
n q m n  p z  v q r t p m r } } v r  r j z o z ~ n
k n o l y k m n r } } l m r z p l q z l z ~ n o j n m p ƒ m q n n  o l s k y q x
q p q { z ~ k n r  o €
¦
„   u r o n o l q z ~ n p  n r z ~ r z k n o l y k m n o s l k
r z ~ k n r  ‚ p } } u n r } } l m r z n  r m m l k  p q { z l u l z ~
m } r o o p ƒ m r z p l q o  z ~ k n r  j ~ r o n r q  m k p z p m r } k n x
o l y k m n o q n n  n  € ‹ q z ~ n l q n ~ r q   z ~ k n r  o p q
r t n t l k v x u l y q  n  j ~ r o n ‚ p z ~  p m y } z p n o z l
n w j } l p z
‡
Ž › ‚ p } } u l k k l ‚ k n o l y k m n o s k l t s r o z n k
z ~ k n r  o € ‹ q z ~ n l z ~ n k ~ r q   m k p z p m r } k n o l y k m n o
‚ p } } l q } v u n  p o z k p u y z n  r t l q { z ~ l o n z ~ k n r  o
‚ ~ p m ~ r m z y r } } v m r q y o n z ~ n t €
6 7 8 7 8 9 : ; < = > ? : = @ < A B = @ @ C D A = E C F G
‡
z p o p t j l k z r q z z l q l z n z ‚ l j l p q z o r u l y z z ~ n
z ~ k n r  m } r o o p ƒ m r z p l q t r  n u v
¦
„   €  p k o z 
‚ n  l q l z m } r o o p s v r z ~ k n r  s l k p z o n q z p k n } p s n x
z p t n ¥ ‚ n  p o z p q { y p o ~ z ~ n  p ¤ n k n q z j ~ r o n o p q r
z ~ k n r   o n w n m y z p l q  r  r j z p q { z l z ~ n  v q r t p m
m ~ r q { n o p q k n o l y k m n k n Š y p k n t n q z o € g n m l q  
l y k j l } p m v  l n o q l z q n n  z l Œ q l ‚ z ~ n n w r m z
r t l y q z l s n r m ~ k n o l y k m n z ~ r z r z ~ k n r  q n n  o €
‰ n l q } v m } r o o p s v z ~ k n r  o p q z l z ~ l o n k n Š y p k x
p q { s n ‚ k n o l y k m n o z l r m ~ p n | n ~ p { ~ x j n k s l k t r q m n 
r q  z ~ l o n ‚ p z ~ ~ p { ~ n k k n Š y p k n t n q z o  o l z ~ r z
l q n z ~ k n r  { k l y j m r q z n t j l k r k p } v { p | n r   p x
z p l q r } k n o l y k m n o z l z ~ n l z ~ n k { k l y j €
‰ n m } r o o p s v z ~ k n r  o p q z l z ‚ l { k l y j o ¥ z ~ n
Fast
{ k l y j  r q  z ~ n
Slow
{ k l y j € ‰ n y o n
m r m ~ n u n ~ r | p l k z l  n z n k t p q n p q ‚ ~ p m ~ { k l y j
z l j } r m n r z ~ k n r  € ‰ ~ n q r z ~ k n r  n w j n k p x
n q m n o r m r m ~ n t p o o  p z k y q o t y m ~ o } l ‚ n k z ~ r q
p z m l y }  r q  p z ~ l }  o k n o l y k m n o z ~ r z ‚ p } } q l z
XVI Jornadas de Paralelismo, JP '2005 53
u n k n } n r o n  s l k r j l z n q z p r } } v } l q { z p t n ¥ y q z p }
z ~ n t p o o p q { } l r  p o m l t t p z z n   n r m ~ p q o z k y m x
z p l q ~ l }  o r k n l k  n k u y ¤ n k
š
 ‹

œ n q z k v r q  
t r q v l s z ~ n t  r j ~ v o p m r } k n { p o z n k €  } o l  r } } p q x
o z k y m z p l q o  n j n q  p q { l q z ~ n t p o o p q { } l r  ~ l } 
r q p q o z k y m z p l q Š y n y n
š
‡

œ n q z k v ‚ p z ~ l y z t r Œ x
p q { r q v j k l { k n o o r o } l q { r o z ~ n l ¤ n q  p q { } l r 
p o q l z k n o l } | n  € ‹ q z ~ n l z ~ n k ~ r q   z ~ k n r  o
‚ ~ p m ~  l q l z n w j n k p n q m n m r m ~ n t p o o n o r k n r u } n
z l n w j } l p z
‡
Ž › ‚ p z ~ s n ‚ k n o l y k m n o € › } n r o n  q l z n
z ~ r z z ~ n v o z p } } k n Š y p k n
‡

n q z k p n o r q  j ~ v o p x
m r } k n { p o z n k o  u y z z ~ n v k n } n r o n z ~ n o n k n o l y k m n o
o ~ l k z } v r s z n k r } } l m r z p q { z ~ n t  o l z ~ n v r k n r u } n
z l k y q l q r k n  y m n  o n z l s k n o l y k m n o €
 s z n k ~ r | p q { n w j } l k n  o n | n k r } j l o o p u p } p z p n o 
‚ n m } r o o p s v z ~ k n r  o u r o n  l q Ž ¢  r z r m r m ~ n
t p o o n o € i ~ k n r  o ‚ p z ~ j n q  p q { Ž ¢  r z r t p o o n o
r k n m } r o o p ƒ n  p q z ~ n o } l ‚ { k l y j  u n m r y o n z ~ n v
t r v r } } l m r z n k n o l y k m n o s l k r } l q { j n k p l  l s
z p t n  r q  z ~ k n r  o ‚ p z ~ q l j n q  p q { Ž ¢  r z r
m r m ~ n t p o o n o r k n m } r o o p ƒ n  p q z ~ n s r o z { k l y j 
u n m r y o n z ~ n v ‚ p } } u n r u } n z l k y q l q r k r j p  } v
m v m } p q { o n z l s k n o l y k m n o €
6 7 8 7 6 < @ F
; A <
@ =  < A B = @ @ C D A = E C F G
 p | n q z ~ n m } r o o p ƒ m r z p l q  n o m k p u n  r u l | n  ‚ n
m l y }  r } k n r  v  p o z k p u y z n k n o l y k m n o r t l q {
z ~ k n r  o z r Œ p q { p q z l r m m l y q z ‚ ~ p m ~ l q n o k n Š y p k n
r   p z p l q r } k n o l y k m n o r q  ‚ ~ p m ~ l q n o m r q  l
‚ p z ~ } n o o z ~ r q z ~ n p k n Š y r } o ~ r k n €
…
l ‚ n | n k  q l z
r } } z ~ k n r  o y o n n | n k v r | r p } r u } n k n o l y k m n p q z ~ n
j k l m n o o l k  y k p q { z ~ n p k n q z p k n } p s n z p t n r q  r o x
o p { q p q { z ~ n t k n o l y k m n o l s r z v j n z ~ r z p o q l z
k n Š y p k n  ‚ l y }  n ¤ n m z p | n } v u n ‚ r o z p q { z ~ n o n k n x
o l y k m n o €  l k z ~ r z k n r o l q  ‚ n r } o l m } r o o p s v n r m ~
z ~ k n r  r o      l k 
     ‚ p z ~ k n { r k  z l o n | x
n k r } j k l m n o o l k k n o l y k m n o € ‰ n j k l m n n  r o s l } x
} l ‚ o ¥ n | n k v z p t n r z ~ k n r  y o n o r { p | n q k n x
o l y k m n  p z p o m } r o o p ƒ n  r o      s l k z ~ n s l } } l ‚ p q {
Y
m v m } n o €
‡
s z ~ n z ~ k n r   p  q l z y o n z ~ p o k n x
o l y k m n r s z n k z ~ n r o o p { q n 
Y
m v m } n o  z ~ n z ~ k n r 
p o m } r o o p ƒ n  r o 
     y q z p } p z y o n o z ~ r z z v j n
l s k n o l y k m n r { r p q €
‡
s r z ~ k n r  p o m } r o o p ƒ n  r o p q r m z p | n s l k r { p | n q
k n o l y k m n  z ~ n q ‚ n r o o y t n z ~ r z p z  l n o q l z m l t x
j n z n s l k z ~ n k n o l y k m n r q  p z o o ~ r k n m r q u n
n | n q } v o j } p z r t l q { z ~ n k n t r p q p q { m l t j n z p q {
z ~ k n r  o €
‡
q l y k o n z y j z ~ p o t n z ~ l  p o n ¤ n m z p | n
s l k z ~ n ’ l r z p q { j l p q z k n o l y k m n o ‚ ~ n q r z ~ k n r 
p o p q r q p
q z n { n k m l t j y z r z p l q j ~ r o n €
‡
q l z ~ n k
g h i m l q ƒ { y k r z p l q o y o p q { l z ~ n k z v j n o l s k n x
o l y k m n o  n € { €  | n m z l k k n o l y k m n o ž     z ~ p o t n z ~ l 
‚ l y }  r } o l u n n ¤ n m z p | n €  l z n z ~ r z z ~ n r m z p | p z v
m } r o o p ƒ m r z p l q p o r o o l m p r z n  z l r o j n m p ƒ m z v j n l s
k n o l y k m n r q  z ~ r z r z ~ k n r  m r q u n r m z p | n ‚ p z ~
k n o j n m z z l r m n k z r p q k n o l y k m n r q  p q r m z p | n ‚ p z ~
k n o j n m z z l l z ~ n k o €
i ~ n z ~ k n r  j ~ r o n m } r o o p ƒ m r z p l q r q  z ~ n
k n o l y k m n y o r { n m } r o o p ƒ m r z p l q r k n l k z ~ l { l q r } €
…
n q m n  s l k n r m ~ k n o l y k m n ‚ n ~ r | n  j l o o p u } n
m } r o o p ƒ m r z p l q o s l k r z ~ k n r  ¥ s r o z x r m z p | n
š
FA
œ 
s r o z x p q r m z p | n
š
FI
œ  o } l ‚ x r m z p | n
š
SA
œ  r q  o } l ‚ x
p q r m z p | n
š
SI
œ € i ~ n t r p q m ~ r k r m z n k p o z p m o l s z ~ p o
m } r o o p ƒ m r z p l q r k n z ~ r z p q r m z p | n z ~ k n r  o
š
XI
œ  l
q l z y o n z ~ n p k o ~ r k n l s r { p | n q k n o l y k m n r q  z ~ r z
o } l ‚ z ~ k n r  o
š
Sx
œ k n Š y p k n t l k n k n o l y k m n o z l n w x
j } l p z
‡
Ž › z ~ r q s r o z z ~ k n r  o
š
Fx
œ  l €
% & % ( ) + 0 ) , * 1 5   4 - + /
i ~ n o ~ r k p q { t l  n }  n z n k t p q n o ~ l ‚ o ~ r k n  k n x
o l y k m n o r k n  p o z k p u y z n  r t l q { z ~ k n r  o €  Œ n v
j l p q z p q r q v o ~ r k p q { t l  n } p o z l u n r ‚ r k n l s
z ~ n k n Š y p k n t n q z o l s n r m ~ { k l y j l s z ~ k n r  o ¥ z ~ n
t l k n r m m y k r z n z ~ n p q s l k t r z p l q  z ~ n u n z z n k z ~ n
o ~ r k p q { €
‹ y k o ~ r k p q { t l  n } o z r k z o s k l t z ~ n r o o y t j x
z p l q z ~ r z r } } z ~ k n r  o k n m n p | n r q n Š y r } o ~ r k n l s
n r m ~ o ~ r k n  k n o l y k m n € ‹ q r | n k r { n  n r m ~ z ~ k n r 
{ n z o
E
n q z k p n o l s n r m ~ k n o l y k m n  { p | n q p q z ~ n
n Š y r z p l q
š
¢ œ  ‚ ~ n k n
R
p o z ~ n z l z r } q y t u n k l s
n q z k p n o l s z ~ r z k n o l y k m n r q 
T
p o z ~ n q y t u n k
l s k y q q p q { z ~ k n r  o €
E =
R
T
š
¢ œ
 n w z  ‚ n z r Œ n p q z l r m m l y q z z ~ r z o } l ‚ z ~ k n r  o
k n Š y p k n t l k n k n o l y k m n o z ~ r q s r o z z ~ k n r  o €
…
n q m n  s r o z z ~ k n r  o m r q o ~ r k n j r k z l s z ~ n p k
k n o l y k m n o ‚ p z ~ o } l ‚ z ~ k n r  o € i ~ p o ‚ r v  o } l ‚
z ~ k n r  o r k n r o o p { q n  z ~ n p k n Š y r } o ~ r k n r q  r } o l
u l k k l ‚ o l t n r   p z p l q r } k n o l y k m n o s k l t z ~ l o n
z ~ k n r  o z ~ r z m r q  l ‚ p z ~ l y z z ~ n t € i ~ p o p q x
z k l  y m n o r    
       
C
 z ~ r z  n z n k t p q n o
z ~ n r t l y q z l s k n o l y k m n o z ~ r z s r o z z ~ k n r  o { p | n
z l n r m ~ o } l ‚ z ~ k n r  € i ~ n | r } y n l s
C
 n j n q  o
l q z ~ n q y t u n k l s z ~ k n r  o ¥ p s z ~ n k n r k n s n ‚
54 Arquitectura del Procesador y Multiprocesadores
z ~ k n r  o  z ~ n q z ~ n k n p o } p z z } n j k n o o y k n l q k n x
o l y k m n o r q  t r q v k n o l y k m n o r k n r o o p { q n  z l
n r m ~ z ~ k n r  €
…
n q m n  s r o z z ~ k n r  o ~ r | n t l k n
k n o l y k m n o z l } n q  l y z € ‰ n ~ r | n z n o z n  o n | n k r }
| r } y n o s l k z ~ p o o ~ r k p q { s r m z l k r q 
C = 1
T +4
{ p | n o z ~ n u n o z k n o y } z o s l k } l ‚ t n t l k v } r z n q m p n o €
‰ p z ~ z ~ p o o ~ r k p q { t l  n }  o } l ‚ z ~ k n r  o p q m k n r o n
z ~ n p k o ~ r k n ‚ p z ~ z ~ n k n o l y k m n o { p | n q z l z ~ n t u v
s r o z z ~ k n r  o €
…
n q m n  n r m ~ o } l ‚ z ~ k n r  p o n q z p x
z } n  z l y o n r z t l o z
Eslow
n q z k p n o  r o o ~ l ‚ q p q
n Š y r z p l q
š
 œ  ‚ ~ n k n
F
p o z ~ n q y t u n k l s s r o z
z ~ k n r  o €
Eslow =
R
T
(1 + C ∗ F)
š
 œ
 z z ~ p o j l p q z  l y k o ~ r k p q { t l  n } z r Œ n o p q z l
r m m l y q z ‚ ~ p m ~ z ~ k n r  o k n Š y p k n t l k n k n o l y k m n o
r q  ‚ ~ p m ~ z ~ k n r  o m r q { p | n j r k z l s z ~ n p k o ~ r k n
z l z ~ n o n k n o l y k m n x ~ y q { k v z ~ k n r  o €
…
l ‚ n | n k 
‚ n o z p } }  l q l z r m m l y q z s l k z ~ n s r m z z ~ r z q l z
r } } z ~ k n r  o y o n n | n k v z v j n l s k n o l y k m n p q z ~ n
j k l m n o o l k € i l r m m l y q z s l k z ~ p o p q s l k t r z p l q  ‚ n
y o n r o n j r k r z n k n o l y k m n r } } l m r z p l q s l k n r m ~ z v j n
l s k n o l y k m n r q  z r Πn p q z l r m m l y q z z ~ r z z ~ k n r  o
‚ ~ p m ~ r k n p q r m z p | n s l k r m n k z r p q k n o l y k m n
š
z ~ l o n
p q z ~ n
SI
r q 
FI
{ k l y j o œ m r q { p | n z ~ n p k n q z p k n
o ~ r k n l s z ~ r z k n o l y k m n z l z ~ n l z ~ n k z ~ k n r  o €
…
n q m n  n r m ~ r m z p | n z ~ k n r  ~ r o
E = R
FA+SA
k n o n k | n  n q z k p n o l s r k n o l y k m n  o p q m n p q r m z p | n
z ~ k n r  o  l q l z m l t j n z n s l k z ~ n t € h l k n l | n k 
s r o z r m z p | n z ~ k n r  o r } o l o ~ r k n r j r k z l s z ~ n p k
k n o l y k m n o ‚ p z ~ o } l ‚ r m z p | n z ~ k n r  o  r o  n z n k x
t p q n  u v z ~ n o ~ r k p q { s r m z l k
C
 ‚ ~ p m ~ ‚ n k n x
 n ƒ q n r o
C = 1
FA+SA
€
…
n q m n  z ~ n q y t u n k l s
n q z k p n o z ~ r z n r m ~ o } l ‚ r m z p | n z ~ k n r  p o n q z p z } n 
z l y o n p o k n x  n ƒ q n  r o ¥
Eslow =
R
FA + SA
(1 + C ∗ FA)
š
 œ
i ~ p o ƒ q r } t l  n }  p o z k p u y z n o k n o l y k m n o l q } v
r t l q { r m z p | n z ~ k n r  o  z ~ l o n r m z y r } } v m l t j n z x
p q { s l k z ~ n t  r q  { p | n o t l k n k n o l y k m n o z l
z ~ k n r  o p q z ~ n o } l ‚ j ~ r o n o  z r Œ p q { z ~ n t s k l t
z ~ n z ~ k n r  o p q ~ p { ~
‡
Ž › j ~ r o n o €


=  ? B < 7
 o o y t n r o ~ r k n  k n o l y k m n ‚ p z ~
  r | r p } r u } n n q z k p n o p q r j k l m n o o l k z ~ r z k y q o 
z ~ k n r  o € i r u } n ¢ o ~ l ‚ o z ~ n k n o l y k m n r } } l m r z p l q
l s o } l ‚ r m z p | n z ~ k n r  o s l k r } } m r o n o p q z ~ p o n w r t x
j } n o p z y r z p l q €
‡
q m r o n z ~ r z r } } z ~ k n r  o r k n p q r
    
FA SA Eslow
  

 


 

 


 
   

  





  
   
i r u } n ¢ ¥
; 6 5 O C 9 < C D < 9 @ 5 8 6 5 7 A D 6 C 5 9 < < A C 9 @ 3 A 2 4 9 < D 5 7
J A 6 9 P  O 5 2 @ 6 E 6 5 7 A D 6 C 5 A 2 9 S O @  6 5 9 8 V 6 A C 5 7 7 A 6 F
9 C @ 3 4 5 @  6 5 9 8 7 6 5 7 V 5 C @ 3 4 5 < E
o } l ‚ j ~ r o n r q  r m z p | n s l k z ~ r z k n o l y k m n
š
z r u } n
n q z k v ¢ £ œ  z ~ n v ‚ l y }  k n m n p | n Ÿ n q z k p n o n r m ~ €
‡
q m r o n ‚ ~ n k n  z ~ k n r  o r k n p q z ~ n s r o z { k l y j
r q  ¢ p o p q z ~ n o } l ‚ { k l y j  r } } r m z p | n s l k z ~ n k n x
o l y k m n
š
z r u } n n q z k v  œ  z ~ n o } l ‚ z ~ k n r  ‚ l y } 
u n r } } l m r z n  ¢  n q z k p n o  } n r | p q { ¢ Ÿ n q z k p n o s l k
z ~ n s r o z z ~ k n r  o €
‡
q m r o n ‚ ~ n k n ¢ z ~ k n r  p o
FI
z ~ k n r  s l k z ~ n k n o l y k m n  
FA
 r q  ¢ z ~ k n r  p q
z ~ n o } l ‚ { k l y j
š
z r u } n n q z k v  œ  z ~ n o } l ‚ z ~ k n r 
‚ l y }  u n r } } l m r z n  ¢ Ÿ n q z k p n o  r q  z ~ n s r o z r m x
z p | n z ~ k n r  o ‚ l y }  u n } n s z ‚ p z ~ ¢  n q z k p n o € i ~ n
p q r m z p | n s r o z z ~ k n r   l n o q l z r } } l m r z n r q v n q x
z k p n o s l k z ~ p o k n o l y k m n € i ~ n l z ~ n k n q z k p n o r k n
m l t j y z n  p q z ~ n o r t n ‚ r v €
  
c

– — –  –  
i l n | r } y r z n z ~ n j n k s l k t r q m n l s z ~ n  p ¤ n k n q z
j l } p m p n o  ‚ n y o n r z k r m n  k p | n q g h i o p t y } r z l k
 n k p | n  s k l t o t z o p t ž ¡   € i ~ n o p t y } r z l k m l q x
o p o z o l s l y k l ‚ q z k r m n  k p | n q s k l q z x n q  r q  r q
p t j k l | n  | n k o p l q l s o t z o p t  o u r m Œ x n q  € i ~ n
o p t y } r z l k r } } l ‚ o n w n m y z p q { ‚ k l q { j r z ~ p q o z k y m x
z p l q o u v y o p q { r o n j r k r z n u r o p m u } l m Π p m z p l x
q r k v z ~ r z m l q z r p q o r } } o z r z p m p q o z k y m z p l q o € i r x
u } n  o ~ l ‚ o z ~ n t r p q j r k r t n z n k o l s z ~ n o p t y x
} r z n  j k l m n o o l k € i ~ p o j k l m n o o l k m l q ƒ { y k r z p l q
k n j k n o n q z o r o z r q  r k  r q  s r p k m l q ƒ { y k r z p l q
r m m l k  p q { z l o z r z n x l s x z ~ n x r k z j r j n k o p q g h i €
i k r m n o l s z ~ n u n q m ~ t r k Πo r k n m l } } n m z n  l s
z ~ n t l o z k n j k n o n q z r z p | n  £ £ t p } } p l q p q o z k y m z p l q
o n { t n q z  s l } } l ‚ p q { r q p  n r j k n o n q z n  p q ž   €
‰ n y o n r } } j k l { k r t o s k l t z ~ n g ›  „  £ £ £ p q x
z n { n k r q  s j u n q m ~ t r k Œ o y p z n €  r m ~ j k l { k r t
p o n w n m y z n  y o p q { z ~ n k n s n k n q m n p q j y z o n z r q 
m l t j p } n  ‚ p z ~ z ~ n
−O2 − non shared
l j x
z p l q o y o p q {
¦
 „  } j ~ r   › x  ¢   „  „
 
XVI Jornadas de Paralelismo, JP '2005 55


                                   
  
  


  

  

  

 

     




   
    

         
 


 

   

  



    

                        

  
    

             

   

     
 

      

      
            



                 



 


                   
               
            


  
    

      

   

              

                   

 
 

     

    
      
     

    

         

               
 



      
 
 

   

      

                  
     
  

          

     

       

  
    

                

                                               

 
i r u } n  ¥ ‰ l k Œ } l r  m } r o o p ƒ m r z p l q u r o n  l q m r m ~ n u n ~ r | p l k l s z ~ k n r  o €

           
      

        



  
 

 

      


    

     

   

 

  !  

        "    

   

 

  !  


      # 
     



$


    % # & '    



      
'    


            
      
'    


       
  (
      


  
'    


 
  '  )  


 *
     
 
  
# + ,



      

        
      

  

  -   


  (
     

* 
  
  *
   
     

          

  




(
     
* 
  
  *
   
     


          

               
 
     



'          
  
     
i r u } n  ¥

r o n } p q n m l q ƒ { y k r z p l q
m l t j p } n k € › k l { k r t o r k n  p | p  n  p q z l z ‚ l
{ k l y j o u r o n  l q z ~ n p k m r m ~ n u n ~ r | p l k r o  n x
o m k p u n  p q ž ¢   ¥ z ~ l o n ‚ p z ~ r q Ž  m r m ~ n t p o o
k r z n ~ p { ~ n k z ~ r q ¢ ‘ r k n m l q o p  n k n  t n t l k v
u l y q  n 
š
h  h œ €  n t r p q  n k z ~ k n r  o r k n m l q x
o p  n k n 
‡
Ž › €
i ~ n j k l j n k z p n o l s r ‚ l k Œ } l r   n j n q  l q z ~ n
q y t u n k l s z ~ k n r  o p q z ~ r z ‚ l k Œ } l r  r q  z ~ n
t n t l k v u n ~ r | p l k l s z ~ l o n z ~ k n r  o €
‡
q l k  n k z l
t r Œ n r s r p k m l t j r k p o l q l s l y k j l } p m v  ‚ n  p o x
z p q { y p o ~ z ~ k n n z v j n o l s ‚ l k Œ } l r  o ¥
‡
Ž ›  h  h 
r q  h
‡
 €
‡
Ž › ‚ l k Œ } l r  o m l q z r p q l q } v ~ p { ~
‡
Ž › z ~ k n r  o  h  h ‚ l k Œ } l r  o m l q z r p q l q } v
t n t l k v x u l y q  n  z ~ k n r  o
š
z ~ k n r  o ‚ p z ~ r ~ p { ~
Ž  t p o o k r z n œ  r q  h
‡
 ‚ l k Œ } l r  o m l q z r p q r
t p w z y k n l s u l z ~ € ‰ n m l q o p  n k ‚ l k Œ } l r  o ‚ p z ~
    r q   z ~ k n r  o €
 m l t j } n z n o z y  v l s r } } u n q m ~ t r k Œ o p o q l z
s n r o p u } n  y n z l n w m n o o p | n o p t y } r z p l q z p t n ¥ r } }
j l o o p u } n m l t u p q r z p l q o l s    r q   u n q m ~ x
t r k Πo { p
| n t l k n z ~ r q ¢ £  £ £ £ ‚ l k Œ } l r  o € ‰ n
~ r | n y o n  z ~ n ‚ l k Œ } l r  o o ~ l ‚ q p q i r u } n  €
 r m ~ ‚ l k Œ } l r  p o p  n q z p ƒ n  u v  j r k r t n z n k o ¥
z ~ n q y t u n k l s z ~ k n r  o p z m l q z r p q o r q  z ~ n z v j n
l s z ~ n o n z ~ k n r  o
š
‡
Ž ›  h
‡
  l k h  h œ €
…
n q m n 
‚ n ~ r | n ¡ ‚ l k Œ } l r  z v j n o €  o m r q u n o n n q
p q i r u } n   ‚ n ~ r | n u y p } z   p ¤ n k n q z { k l y j o
s l k n r m ~ ‚ l k Œ } l r  z v j n p q l k  n k z l r | l p  z ~ r z
l y k k n o y } z o r k n u p r o n  z l ‚ r k  r o j n m p ƒ m o n z
l s z ~ k n r  o €

n q m ~ t r k Πo p q n r m ~ { k l y j ~ r | n
u n n q o n } n m z n  k r q  l t } v €
‡
q z ~ n k n o y } z o n m x
z p l q  ‚ n o ~ l ‚ z ~ n r | n k r { n k n o y } z o l s z ~ n s l y k
{ k l y j o  n € { €  z ~ n h  h  k n o y } z p o z ~ n t n r q
l s z ~ n . / 0 1 2 3 4 5 0  6 7 2 1 8 9 7  6 7 2 1 2 3 4 5 0  r q 
:
3 ; . 1 . / 0 ‚ l k Œ } l r  o €
< = 
d > – d ? e
•
f
  @
e  ˜ e c ™ –
•
‰ n m l t j r k n l y k
¦
„   j l } p m v ‚ p z ~ o l t n
l s z ~ n u n o z s n z m ~ j l } p m p n o m y k k n q z } v j y u x
} p o ~ n  ¥
‡
„ ‹
ˆ
 i ž Ÿ    g i  Ž Ž ž      Ž
ˆ
g
…
ž    
 Ž
ˆ
g
…  
ž ¢   
¦
 ž    r q  ›
¦
 ž    € ‹ y k k n o y } z o
o ~ l ‚ z ~ r z s l k z ~ n o n z y j o n w r t p q n  p q z ~ p o j r x
j n k   Ž
ˆ
g
…  
l y z j n k s l k t o u l z ~ g i  Ž Ž r q 
 Ž
ˆ
g
…
 r q 
¦
 l y z j n k s l k t o ›
¦
 €
…
n q m n 
s l k u k n | p z v  ‚ n l q } v o ~ l ‚ z ~ n k n o y } z o s l k
‡
„ ‹
ˆ
 i   Ž
ˆ
g
…  
 r q 
¦
 €
‡
q l k  n k z l m l t j r k n z ~ n o j l } p m p n o ‚ n y o n z ‚ l
‚ n } } x Œ q l ‚ q t n z k p m o p q g h i ¥ z ~ n
‡
› „ z ~ k l y { ~ x
j y z r q  z ~ n
Hmean
ž    €
 p { y k n 
š
r œ o ~ l ‚ o z ~ n
‡
› „ z ~ k l y { ~ j y z
r m ~ p n | n  u v
¦
„   r q  z ~ n l z ~ n k s n z m ~ j l } p x
m p n o € ‰ n l u o n k | n z ~ r z
¦
„   r m ~ p n | n o ~ p { ~ n k
z ~ k l y { ~ j y z z ~ r q r q v l s z ~ n l z ~ n k s n z m ~ j l } p x
m p n o s l k r } } ‚ l k Œ } l r  o  n w m n j z s l k  Ž
ˆ
g
…  
56 Arquitectura del Procesador y Multiprocesadores
0
1
2
3
4
5
6
ILP MIX MEM ILP MIX MEM ILP MIX MEM
2 3 4
Throughput
ICOUNT DG FLUSH++ DCRA
9
I ; ? @  6 A D _  V D @
-10
0
10
20
30
40
50
60
70
80
ILP MIX MEM ILP MIX MEM ILP MIX MEM ILP MIX MEM
2 3 4 avg
Hmean
improvement
(%)
ICOUNT
DG
FLUSH++

 = 5 9 2 J 9 3 6 2 5 7 7 3 = V 6 A 4 5 = 5 2 @
3 _ D 6 5 
W  6 A D _  V D @   = 5 9 2 3 = V 6 A 4 5 = 5 2 @ A J

?   A 4 5 6 I ?  1  W Z : 1 U    Z 9 2 8

> F
p q z ~ n h  h ‚ l k Œ } l r  o € i ~ n r  | r q z r { n l s
 Ž
ˆ
g
…  
l | n k
¦
„   p o  y n z l z ~ n s r m z z ~ r z
s l k z ~ n h  h ‚ l k Œ } l r  o  n o j n m p r } } v s l k z ~ n  x
h  h ‚ l k Œ } l r  o  z ~ n k n p o r q l | n k j k n o o y k n l q
k n o l y k m n o ¥ z ~ n k n p o r } t l o z q l z ~ k l y { ~ j y z p q x
m k n r o n ‚ ~ n q { l p q { s k l t z ~ n  x h  h ‚ l k Œ } l r  o
z l z ~ n  x h  h ‚ l k Œ } l r  o €  o r m l q o n Š y n q m n l s
z ~ p o ~ p { ~ j k n o o y k n l q k n o l y k m n o  p z p o j k n s n k r u } n
z l s k n n k n o l y k m n o r s z n k r t p o o p q { } l r  z ~ r q z k v
z l ~ n } j r z ~ k n r  n w j n k p n q m p q { m r m ~ n t p o o n o € ‹ q
r | n k r { n 
¦
„   p t j k l | n o
‡
„ ‹
ˆ
 i u v   ‘ 
¦
 u v  £ ‘  r q   Ž
ˆ
g
…  
u v ¢ ‘ €
 n { r k  p q {
…
t n r q k n o y } z o  o ~ l ‚ q p q  p { y k n

š
u œ 
¦
„   p t j k l | n o r } } l z ~ n k j l } p m p n o € ‹ q
r | n k r { n 
¦
„   p t j k l | n o  Ž
ˆ
g
…  
u v  ‘ 
‡
„ ‹
ˆ
 i u v ¢ Ÿ ‘ r q 
¦
 u v  ¢ ‘ €  { r p q 
z ~ n  Ž
ˆ
g
…  
j l } p m v j n k s l k t o u n z z n k z ~ r q
¦
„   p q z ~ n h  h ‚ l k Œ } l r  o  s l k z ~ n o r t n
k n r o l q o  n o m k p u n  r u l | n €
…
l ‚ n | n k  z ~ n o } p { ~ z j n k s l k t r q m n r  | r q z r { n
l s  Ž
ˆ
g
…  
l | n k
¦
„   p q z ~ n h  h ‚ l k Œ x
} l r  o m l t n o r z r ~ p { ~ m l o z ¥ n | n k v z p t n r z ~ k n r 
p o ’ y o ~ n  z l k n m } r p t p z o k n o l y k m n o s l k z ~ n l z ~ n k
z ~ k n r  o  p q o z k y m z p l q o s k l t z ~ n l ¤
n q  p q { z ~ k n r 
t y o z u n s n z m ~ n    n m l  n   k n q r t n   r q  n | n q
o l t n z p t n o n w n m y z n  r { r p q € ‰ n ~ r | n t n r o y k n 
z ~ p o l | n k ~ n r   r q  s l k  £ £ m v m } n o l s t n t l k v } r x
z n q m v   Ž
ˆ
g
…  
s n z m ~ n o ¢ £ Ÿ ‘ t l k n p q o z k y m x
z p l q o z ~ r q
¦
„   € i ~ r z p o r
2X
p q m k n r o n p q
r m z p | p z v s l k z ~ n j k l m n o o l k  o s k l q z x n q  €
i ~ n r  | r q z r { n l s
¦
„   l | n k z ~ n l z ~ n k
k n o l y k m n x m l q o m p l y o s n z m ~ j l } p m p n o p o z ~ r z p z r } x
} l ‚ o z ~ n t n t l k v x u l y q  z ~ k n r  z l m l q z p q y n
n w n m y z p q { p q o z k y m z p l q o ‚ p z ~ r q p q m k n r o n  x u y z
} p t p z n  x k n o l y k m n o ~ r k n € i ~ p o p q m k n r o n  k n x
o l y k m n r o o p { q t n q z r } } l ‚ o z ~ n z ~ k n r  z l } r y q m ~
t l k n } l r  l j n k r z p l q o u n s l k n o z r } } p q {  y n z l k n x
o l y k m n r u y o n  r q  p q m k n r o n o z ~ n t n t l k v j r k x
r } } n } p o t l s t n t l k v x u l y q  r j j } p m r z p l q o ‚ ~ p } n
~ p { ~
‡
Ž › l q n o  l q l z o y ¤ n k t y m ~
š
r o o ~ l ‚ q
p q  p { y k n ¢ œ € ‰ n ~ r | n t n r o y k n  z ~ n p q m k n r o n
p q z ~ n q y t u n k l s l | n k } r j j p q { Ž  t p o o n o ‚ ~ p } n
y o p q {
¦
„   m l t j r k n  z l y o p q {  Ž
ˆ
g
…  

r q  ‚ n ~ r | n s l y q  r q r | n k r { n p q m k n r o n l s ¢ Ÿ ‘
p q z ~ n t n t l k v j r k r } } n } p o t l s z ~ n ‚ l k Œ } l r  o
š
  ‘ p q m k n r o n p q
‡
Ž › ‚ l k Œ } l r  o    ‘ p q h
‡

‚ l k Œ } l r  o  r q  £ €  ‘ p q h  h ‚ l k Œ } l r  o œ €
 y k z ~ n k r q r } v o p o l s z ~ n h  h ‚ l k Œ } l r  o
o ~ l ‚ o z ~ r z
¦
„   p o r  | n k o n } v r ¤ n m z n  u v  n x
{ n q n k r z n m r o n o } p Œ n   € ‹ y k k n o y } z o o ~ l ‚
r  ¢ ‘ p q m k n r o n p q z ~ n q y t u n k l s l | n k } r j x
j p q { t p o o n o s l k    ~ l ‚ n | n k  z ~ p o p q m k n r o n p o
~ r k  } v | p o p u } n p q z ~ n l | n k r } } j k l m n o o l k j n k s l k x
t r q m n  y n z l z ~ n n w z k n t n } v } l ‚ u r o n } p q n j n k x
s l k t r q m n  r q  m l t n o r z z ~ n n w j n q o n l s o } p { ~ z } v
 n m k n r o n  j n k s l k t r q m n l s l z ~ n k z ~ k n r  o € i ~ r z
n w j } r p q o ‚ ~ v  Ž
ˆ
g
…  
~ r q  } n o   u n z z n k
z ~ r q
¦
„    { p | p q { p z z ~ n r  | r q z r { n p q h  h
‚ l k Œ } l r  o €  y z y k n ‚ l k Œ ‚ p } } z k v z l  n z n m z
z ~ n o n  n { n q n k r z n m r o n o p q ‚ ~ p m ~ r o o p { q p q { t l k n
k n o l y k m n o z l r z ~ k n r   l n o q l z m l q z k p u y z n r z r } }
z l p q m k n r o n  l | n k r } } k n o y } z o l k k n o y } z o p q l | n k r } }
j n k s l k t r q m n  n { k r  r z p l q €


–
•
f  ˜ b ™ –
•
b
„ y k k n q z  v q r t p m r } } v j r k z p z p l q n   n o p { q o  n x
j n q  l q z ~ n s n z m ~ j l } p m v s l k k n o l y k m n r } } l m r x
z p l q €
…
l ‚ n | n k  z ~ n s n z m ~ j l } p m v  l n o q l z  p x
k n m z } v m l q z k l } ~ l ‚ t r q v k n o l y k m n o r k n r } } l x
m r z n  z l r z ~ k n r  r q  m y k k n q z j l } p m p n o m r q
m r y o n u l z ~ k n o l y k m n t l q l j l } p † r z p l q r q  k n x
XVI Jornadas de Paralelismo, JP '2005 57
o l y k m n y q  n k x y o n  l u z r p q p q { } n o o z ~ r q l j z p t r }
j n k s l k t r q m n €
‰ n ~ r | n j k l j l o n  z l y o n r  p k n m z k n o l y k m n
r } } l m r z p l q j l } p m v  p q o z n r  l s s y } } v k n } v p q { l q z ~ n
s n z m ~ j l } p m v z l  n z n k t p q n ~ l ‚ m k p z p m r } k n o l y k m n o
r k n o ~ r k n  u n z ‚ n n q z ~ k n r  o € ‹ y k  v q r t p m k n x
o l y k m n r } } l m r z p l q z n m ~ q p Š y n p o u r o n  l q r  v x
q r t p m m } r o o p ƒ m r z p l q l s z ~ k n r  o € ‰ n p  n q z p s v
‚ ~ p m ~ z ~ k n r  o r k n m l t j n z p q { s l k r { p | n q k n x
o l y k m n r q  ‚ ~ p m ~ z ~ k n r  o o ~ l y }  u n r u } n z l
{ p | n j r k z l s z ~ n p k k n o l y k m n o z l l z ~ n k z ~ k n r  o
‚ p z ~ l y z  r t r { p q { j n k s l k t r q m n € ‹ y k z n m ~ x
q p Š y n m l q z p q y l y o } v  p o z k p u y z n o k n o l y k m n o z r Œ x
p q { z ~ n o n m } r o o p ƒ m r z p l q o p q z l r m m l y q z r q   p x
k n m z } v n q o y k n o z ~ r z q l k n o l y k m n x ~ y q { k v z ~ k n r 
n w m n n  o p z o k p { ~ z s y } r } } l m r z p l q €
‹ y k k n o y } z o o ~ l ‚ z ~ r z
¦
„   l y z j n k s l k t o
j k n | p l y o } v j k l j l o n  s n z m ~ j l } p m p n o s l k r } } n | r } x
y r z n  ‚ l k Œ } l r  o € i ~ k l y { ~ j y z k n o y } z o o ~ l ‚
z ~ r z
¦
„   p t j k l | n o
‡
„ ‹
ˆ
 i u v   ‘ 
¦

u v  £ ‘  r q   Ž
ˆ
g
…  
u v ¢ ‘  l q r | n k r { n €
i ~ n r | n k r { n
…
t n r q p t j k l | n t n q z l s
¦
„  
p o ¢ Ÿ ‘ l | n k
‡
„ ‹
ˆ
 i   ¢ ‘ l | n k
¦
  r q   ‘
l | n k  Ž
ˆ
g
…  
€ i ~ n o n k n o y } z o m l q ƒ k t z ~ r z
¦
„    l n o q l z l u z r p q z ~ n
‡
Ž › u l l o z u v y q x
s r p k } v j k n s n k k p q { ~ p { ~
‡
Ž › z ~ k n r  o l | n k o } l ‚ n k
t n t l k v x u l y q  n  z ~ k n r  o € ‹ q z ~ n m l q z k r k v 
p z j k n o n q z o r u n z z n k z ~ k l y { ~ j y z x s r p k q n o o u r } x
r q m n € g y t t r k p † p q {  ‚ n j k l j l o n r  v q r t p m k n x
o l y k m n r } } l m r z p l q j l } p m v z ~ r z l u z r p q o r u n z z n k
z ~ k l y { ~ j y z x s r p k q n o o u r } r q m n z ~ r q j k n | p l y o } v
j k l j l o n  j l } p m p n o  t r Œ p q { p z r q p  n r }  n o p { q
j l p q z s l k u l z ~ z ~ k l y { ~ j y z r q  s r p k q n o o l k p x
n q z n  g h i  n o p { q o €
` f
•
–


—  ?
 •
c b
i ~ p o ‚ l k Œ ~ r o u n n q o y j j l k z n  u v z ~ n h p q p o z k v
l s g m p n q m n r q  i n m ~ q l } l { v l s g j r p q y q  n k m l q x
z k r m z i
‡
„ x  £ £  x £    ¡ x „ £  x £ ¢  r q  { k r q z  › x
 £ £ ¢ x   
š
 k r q m p o m l  € „ r † l k } r œ  z ~ n
…
p ›   „
 y k l j n r q  n z ‚ l k Œ l s  w m n } } n q m n  r q  r q
‡
q z n }
s n } } l ‚ o ~ p j € i ~ n r y z ~ l k o ‚ l y }  } p Œ n z l z ~ r q Œ
› n z n k  q p  q n q u y k { s l k ~ p o m l t t n q z o r q  ‹ } p | x
n k p l  € g r q z r q r   v l o n  r } m  q  r q   n k q r q  l
Ž r z l k k n s l k z ~ n p k ‚ l k Œ p q z ~ n o p t y } r z p l q z l l } €
 
>

d
 •
f

b

N  F
M
F ? 9 Y A 6 < 9 Z G F 5 6 2 9 2 8 5 Y Z  F  9 = 3 6 5 Y Z 9 2 8
L F  9 < 5 6
A F I = V 6 A 4 3 2 _ = 5 = A 6 E < 9 @ 5 2 C E 9  9 6 5
J 5 @ C  V A < 3 C 3 5 7 J A 6 U L W V 6 A C 5 7 7 A 6 7 F 
   
   

  
 
  



 



      

   


  

 


  
 

  

  
Z  C @ F  Q Q P F

   F G < O L A D 6 7 E 9 2 8

F  <  A 2 5 7 3 F 6 A 2 @ O 5 2 8
V A < 3 C 3 5 7 J A 6 3 = V 6 A 4 5 8 3 7 7 D 5 5 ! C 3 5 2 C E 3 2 U L W
V 6 A C 5 7 7 A 6 7 F

 " Z  Q Q P F

P   F G 7 V 9 7 9 9 2 8 L F  9 < 5 6 A F L D < @ 3 @  6 5 9 8 5 8 4 5 C O
@ A 6 9 6 C  3 @ 5 C @ D 6 5 7 F 
  
   

  
 #





 



  



 

 

   

 


  
 

  

 " 



 


 Z V 9 _ 5 7  P ^ $  S % Z 5 
N % % ^ F

S  ? F : 3 = A D 7 3 2 Z
M
F U 5  A @ Z  F  9 6 @ 9 2 3 9 2 Z 9 2 8
 F

6 9 C  O W 5 = 9 = F I = V 6 A 4 3 2 _ P

_ 5 A = 5 O
@ 6 E @ 6 9 2 7 J A 6 = 9 @ 3 A 2 7 A 2 9 7 3 = D < @ 9 2 5 A D 7 = D < @ 3 O
@  6 5 9 8 5 8 U I L

V 6 A C 5 7 7 A 6 F 
 &

  
 ' 
 



&



 

 

   
 

  

  
Z L 9 E
 Q Q N F

]  ( F : D A Z
M
F > D = = 9 6 9 ) D Z 9 2 8 L F 6 9 2  < 3 2 F
T 9 < 9 2 C 3 2 _ @  6 A D _  V D @ 9 2 8 J 9 3 6 2 5 7 7 3 2 U L W
V 6 A C 5 7 7 A 6 7 F 
  
   

  





 



  
   

   


 


  
  "
      


  



   



  *

 Z  A 4 F  Q Q N F
 +
 W F U  5 6  A A 8 Z G F ; 5 6 5 < = 9 2 Z 9 2 8 T F ? 9 < 8 5 6 F
T 9 7 3 C  < A C  8 3 7 @ 6 3  D @ 3 A 2 9 2 9 < E 7 3 7 @ A H 2 8 V 5 O
6 3 A 8 3 C  5  9 4 3 A 6 9 2 8 7 3 = D < 9 @ 3 A 2 V A 3 2 @ 7 3 2 9 V O
V < 3 C 9 @ 3 A 2 7 F 
  
   

  
 ' ,
  



 




  



 

 





  


" 



 




 

    



 -
 

  . 


Z U 5 V @ F  Q Q N F

^ 

F W D < < 7 5 2 9 2 8
M
F T 6 A  2 F  9 2 8 < 3 2 _ < A 2 _ O
< 9 @ 5 2 C E < A 9 8 7 3 2 9 7 3 = D < @ 9 2 5 A D 7 = D < @ 3 O
@  6 5 9 8 5 8 V 6 A C 5 7 7 A 6 F 
  
   

  
 # /
 
"
    
" 0 1
 2 2 2 



 



      


   


0








 


 Z

5 C F  Q Q N F

R 

F W D < < 7 5 2 Z U F G _ _ 5 6 7 Z
M
F G = 5 6 Z  F : 5 4 E Z
M
F : A Z 9 2 8  F U @ 9 = = F G 3 V < A 3 @ 3 2 _ C  A 3 C 5
I 2 O
7 @ 6 D C @ 3 A 2 J 5 @ C  9 2 8 3 7 7 D 5 A 2 9 2 3 = V < 5 = 5 2 @ 9  < 5
7 3 = D < @ 9 2 5 A D 7 = D < @ 3 @  6 5 9 8 3 2 _ V 6 A C 5 7 7 A 6 F 
 &

  
 4 # "
    



&
   

   



 

 " 



 


 Z V 9 _ 5 7 N % N $  Q  Z  V 6 F N % %
+
F

% 

F W D < < 7 5 2 Z U F G _ _ 5 6 7 Z 9 2 8  F L F : 5 4 E F U 3 = D < O
@ 9 2 5 A D 7 = D < @ 3 @  6 5 9 8 3 2 _
L 9 3 3 = 3 Y 3 2 _ A 2 O C  3 V
V 9 6 9 < < 5 < 3 7 = F 
 &

  
 4 4

"
    



&
   

   

  

 " 



 


 Z N % % ] F

N Q  5 F 6 9 = 9 = A @ A 9 2 8 L F  5 = 3 6 A 4 7  E F I 2 C 6 5 9 7 O
3 2 _ 7 D V 5 6 7 C 9 < 9 6 V 5 6 J A 6 = 9 2 C 5 @  6 A D _  = D < @ 3 O
7 @ 6 5 9 = 3 2 _ F 
 &

  
 '

 



 



    



   

 
 " Z N % % ] F
58 Arquitectura del Procesador y Multiprocesadores
hdSMT: An Heterogeneity-Aware Simultaneous Multithreading
Architecture
Carmelo Acosta † Ayose Falcón ‡ Alex Ramirez † Mateo Valero †

† Departament d’Arquitectura de Computadors ‡ Barcelona Research Office
Barcelona
Universitat Politecnica de Catalunya HP Labs Supercomputing
Barcelona, Spain Barcelona, Spain Center
{cacosta,aramirez,mateo}@ac.upc.edu ayose.falcon@hp.com
Abstract
The hardware support required for each ap-
plication may vary as they exhibit different
behaviors. However, current architectures are
designed for the common case.
In this paper we present an alternative SMT
architecture, the Heterogeneously Distributed
SMT (hdSMT), based in a novel combina-
tion of SMT and clustering techniques in a
heterogeneity-aware fashion. The hardware is
designed to match the heterogeneous applica-
tion behavior with the statically and heteroge-
neously partitioned resources, minimizing the
amount of resources wasted to achieve a given
performance rate.
We evaluate and compare our hdSMT archi-
tecture with both monolithic SMT processor
and homogeneous clustered SMT. Our results
show that hdSMT architectures obtain an av-
erage improvement of 13% and 14% in opti-
mizing performance per area over monolithic
SMT and homogeneously clustered SMT re-
spectively.
1 Introduction
The needs of today’s multi-programmed work-
loads put pressure on microprocessor de-
sign towards high-performance and high-
throughput machines. Simultaneous multi-
threading (SMT) [15, 16] processors evolve the
traditional superscalar architecture by shar-
ing all the processor resources among more
than one running thread. Chip multiproces-
sors (CMP) [8, 5] rely on simpler cores, repli-
cating them on a single chip and allocating
running threads to these cores. They represent
different approaches to optimize the perfor-
mance that a fixed transistor budget can pro-
duce: A big machine where every resource is
shared versus several simpler machines where
the sharing locality is restricted.
As the number of transistors on chip in-
creases, the issue of how to employ them to
achieve the highest performance potential gets
renewed importance. The design complexity
has to remain under reasonable costs while
it achieves the highest performance potential.
But achieving high levels of both performance
and throughput from a given hardware bud-
get at a reasonable complexity cost is not an
easy task. Employing the additional resources
to simply stretch traditional structures, such
as instruction queues, is not conducive towards
building highly pipelined processors with short
clock periods. Besides, power and thermal
considerations also have to be taken into ac-
count since future microprocessors’ designs are
likely to be limited by them. In this sense,
the reduced complexity of the CMP approach
combined with the resource exploitation ca-
pacity of the SMT approach seems an appeal-
ing alternative.
General-purpose designs treat applications
homogeneously, although not all applications
have the same behavior. In fact, we can find a
huge inter-application heterogeneity in current
multi-programmed workloads, which can be
measured in terms of memory misses, branch
mispredictions or instruction level parallelism
(ILP) among others. This heterogeneity re-
sults sometimes in applications executed us-
ing an amount of resources and power that
is not cost-effective with the performance ob-
tained. By making the hardware conscious
of this heterogeneity (heterogeneity-aware) we
could keep design complexity reasonably low
without losing too much performance.
In this paper, we review the open issue of
on chip resource distribution and propose a si-
multaneous multithreading architecture, Het-
erogeneously Distributed Simultaneous Multi-
threading (hdSMT), in which all the pipeline
stages but the fetch stage have been heteroge-
neously clustered —pipelined from now on—
, making up a multipipeline SMT processor.
Both the memory subsystem and the register
file are also shared among all the pipelines.
Consequently, the single-thread performance
is not hampered by a memory or register file
static distribution as could happen in a CMP
processor. In this architecture the heteroge-
neity of the typical software that will be ex-
ecuted on the processor is analyzed and mir-
rored itself in the hardware. Thus, the hetero-
geneous behavior of the running applications
is matched with the heterogeneous hardware,
mapping software needs to heterogeneously
partitioned hardware resources.
2 The hdSMT Architecture
The foundations of the hdSMT architecture
are comprised of a threefold combination of
well known principles and techniques: SMT,
clustering, and heterogeneity-awareness. The
heterogeneity in applications’ behavior makes
vary the hardware requirements among dif-
ferent applications. This heterogeneity may
turn evenly clustered approaches, as in [3], into
not optimal. To better profit from the avail-
able hardware it should be heterogeneously
clustered and the applications appropriately
matched with the clusters according to their
needs. The hdSMT architecture maximizes


       

      
      
      
…


 
 
 
! 
"

#
$ %
& '
" (
)*
$
(
#
+
,
-
,
.
,
/012 4 5
6 7 8
9
5
7
4
5
6
7 8
:;
4
5
6
7 8
  < = >
? @
A
A BC
? @
A
A BC
? @
A
A BC
? @
A
A BC
Figure 1: The hdSMT Architecture.
the available hardware budget by taking into
account the heterogeneity in this way.
The hdSMT architecture overview is de-
picted in Fig. 1. As in a conventional SMT
processor, all threads share the caches, regis-
ter file, and fetch engine. However, the rest of
the pipeline stages and resources are arranged
in heterogeneous clusters (or pipelines). Each
pipeline also has got its own private instruc-
tion queues, renaming map tables and func-
tional units. The size and number of these
resources may vary from pipeline to pipeline.
Additionally, each thread’s instructions are
stored in a private reorder buffer (ROB), one
per thread.
In this clustered multithreaded architecture,
entire threads are assigned to pipelines accord-
ing to heterogeneity. This implies that there
are no dependencies between instructions in
different clusters, since all instructions from a
single thread are mapped to the same pipeline.
The heterogeneity-aware fetch engine strives
to match both the needs of each running ap-
plication and the interaction among each ap-
plication with the heterogeneously distributed
hardware. This software-hardware mapping
is performed each time the job scheduler of
the operating system selects a new bunch of
active threads. The whole subsequent exe-
cution of the workload is done according to
this mapping. In this work we have used a
simple profile-based heuristic policy that uses
the memory behavior of each thread to do the
mapping. By means of profile information,
the active threads are arranged by the num-
ber of data cache misses and assigned to the
pipelines. The full mapping process is as fol-
lows:
60 Arquitectura del Procesador y Multiprocesadores
1. Arrange all active threads by the number
of data cache misses in a list (T). The
first thread in T is the one with the lesser
number of misses.
2. Arrange all pipelines by their width in
a list (P). The first pipeline in P is the
widest one.
3. Map the first thread in T to the first
pipeline in P.
4. If this is the first assignment, and there
are more available hardware contexts
than active threads then remove the top
of the list P.
5. Remove the top of the list T.
6. If all the hardware contexts of the pipeline
in the top of the list P are busy then re-
move the top of the list P.
7. If list T is not empty continue in step 3.
The number of hardware contexts and width
of each pipeline may vary from pipeline to
pipeline. So, an hdSMT microarchitecture
may be comprised of both narrow single-
threaded and wide multithreaded pipelines, as
well intermediate pipelines. Depending on the
resource needs of each application and the in-
teraction between application behavior, more
than one application may be mapped to a sin-
gle pipeline. This distribution of the hardware
contexts along the chip can be profited to turn
off idle pipelines whenever the number of run-
ning applications does not reach the number
of hardware contexts. This is also applied in
the Heterogenous Multi-Core architecture [6],
turning off idle heterogeneous cores. The main
difference of our proposal in this sense is that
we can still use the whole budget of physi-
cal registers and memory space to improve the
performance of the running applications, since
they are shared by all pipelines.
Notice that multipipeline-awareness in
hdSMT uncovers new fetch policies not avail-
able in conventional SMT processors. The
shared fetch engine is limited by the number
and width of the instruction cache ports.
However, the number of instructions that
each pipeline accept per cycle may vary from
pipeline to pipeline. In order to decouple the
fetch engine from the characteristics of each
specific pipeline it feeds, some small buffers
are added before each pipeline (see Fig. 1).
Thus, the fetch engine inserts in-order the
fetched instructions at its own rate while
each pipeline extracts in-order instructions
according to its width. The fetch policy
takes into account these buffers in order to
appropriately balance the instructions fetched
among the pipelines. Depending on the
pipeline set characteristics, this may result
in a wider global decode bandwidth since all
pipelines are fed from their private buffer each
cycle.
3 Area Cost Model
In this work we evaluate different microar-
chitectures, which involve different hardware
budgets. Since comparing the results pro-
duced by microarchitectures with different
amount of resources may be quite unfair, we
need some complexity measurement to guide
this evaluation. Quantifying complexity is a
tricky task and giving a single and compara-
ble measurement is even harder to accomplish.
In this paper we follow a quite generalized ap-
proach and use the area (in mm2
) of the pro-
cessor as a metric of its “complexity”.
To estimate the area of each configuration
we employ the Karlsruhe Simultaneous Mul-
tithreaded Simulator [11, 12, 13]. On top of
this area estimation tool we develop our area
cost model. Since both hdSMT and SMT
approaches share the same register file and
caches, we have removed them from the model
to simplify the results. However, since in
hdSMT these resources are shared among all
pipelines, the additional logic cost is taken into
account. It is added to the execution core of
each pipeline, as additional hardware for data
access. The hdSMT fetch engine also needs
some additional logic for multipipeline sup-
port. We have estimated the area overhead
of the execution core within each pipeline in
a 10%; and a 20% area overhead for the con-
ventional SMT fetch engine ,when applied to
XVI Jornadas de Paralelismo, JP '2005 61
a hdSMT multipipeline environment.
In our evaluation, we use four different mod-
els of pipeline, named M8, M6, M4, and M2.
Each microarchitecture evaluated is comprised
of a some of them, except for the monolithic
SMT baseline represented by M8. Our area
cost model considers the total area as the sum,
for all constituent pipelines, of the instruc-
tion fetch, decode, dispatch, execution core,
and instruction completion stages plus the de-
code, dispatch, and completition queues. We
show in Fig. 2.(a) the amount of resources de-
voted to each pipeline model. Additionally, we
have assumed a per-thread 256-entry ROB in
all configurations. In Fig. 2.(b) we show the
area estimation of each model according to our
area cost model. Finally, in Fig. 2.(c) we show
the area estimation of each microarchitecture
evaluated. All estimations have been made in
0.18 µm.
Finally, as shown in Fig. 2.(a), our SMT
baseline (M8) is not able to execute more
than four threads. Although adding additional
hardware contexts increases the total area of
an SMT processor, as Burns and Gaudiot eval-
uate in [1], we assume no additional area over-
head for this model when adding two addi-
tional hardware contexts; in order to execute
workloads of six threads on it.
4 Simulation Setup
We use a trace driven SMT simulator derived
from SMT-SIM [15]. The simulator consists
of our own trace driven front-end plus an im-
proved version of SMT-SIM’s back-end, that
provides multipipeline support among others.
We show the simulation parameters in Ta-
ble 1. Both the monolithic SMT and the
multipipeline configurations have an 8 stage
pipeline depth. However, in the multipipeline
configurations we have increased the register
file read/write latency from 1 to 2 cycles, due
to the additional logic required in hdSMT to
handle multipipeline register file sharing.
In our experiments, we adopt the
FLUSH [14] fetch policy for the baseline
(M8) case. This fetch policy, built on top of
ICOUNT 2.8 [16], predicts an L2 miss every
M8 M6 M4 M2
Hardware Contexts 4 2 2 1
Max. Instr./cycle 8 6 4 2
Max. Threads/cycle 2 2 2 1
Queues (IQ/FQ/LQ) 64 32 32 16
Integer Func. Units 6 4 3 1
FP Func. Units 3 2 2 1
LD/ST Units 4 2 2 1
a) Resources.
0
20
40
60
80
100
120
140
160
180
M8 M6 M4 M2
mm
2
Completion Queue
Dispatch Queue
Decode Queue
Instruction Completion
Execution Core
Instruction Dispatch
Instruction Decode
Instruction Fetch
b) Pipelines area estimation.
0
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
170
180
190
200
M
8
3
M
4
4
M
4
2
M
4
+
2
M
2
3
M
4
+
2
M
2
1
M
6
+
2
M
4
+
2
M
2
mm²
CQ
DIQ
DEQ
IC
EX
DI
DE
IF
-17% -27%
+10,14%
+2%
-1%
c) Microarchitectures area estimation.
Figure 2: Pipeline models.
time a load spends more cycles in the cache
hierarchy than needed to access the L2 cache.
In case of L2 miss, the instructions after the
L2 missing load are flushed, and the offending
thread is stalled until the load is resolved.
Thus, the resources used by the offending
thread are freed and it does not compete for
new resources until the load is resolved. This
allows the other threads to proceed while the
stalled thread is waiting for the outstanding
cache miss.
In all other cases, we adopt the
L1MCOUNT fetch policy, a variant of
the DCache Warn fetch policy [2]. This fetch
policy keeps track of the number of inflight
loads. Threads are arranged by the number
of inflight loads they have and given fetch
priority accordingly. Threads with fewer
62 Arquitectura del Procesador y Multiprocesadores
Branch Predictor perceptron
4K loc, 256 pers
BTB 256 entries, 4-way
RAS* 256 entries
ROB Size* 256 entries
Rename Registers 256 regs.
L1 I-Cache 64KB, 2-way, 8 banks
L1 D-Cache 64KB, 2-way, 8 banks
L1 lat./miss. 3/22 cyc.
L2 Cache 512KB, 2-way, 8 banks
L2 latency 12 cyc.
Main Memory Latency 250 cyc.
I-TLB/D-TLB 48 ent. / 128 ent.
TLB miss. 300 cyc.
Table 1: Simulation parameters (resources
marked with * are replicated per thread)
number of inflight loads have priority. In case
of equal number of inflight loads, threads
allocated to wider pipelines have priority over
those in narrower pipelines. Finally, in case of
pipeline coincidence, the ICOUNT 2.8 policy
is applied. Regardless of the fetch policy,
all simulations are limited to 8 instructions
fetchable per cycle, from a maximum of 2
threads. In order to decouple the shared fetch
engine from each pipeline characteristics, we
have put a buffer between the fetch engine
and each pipeline (see Fig. 1). The size
of these buffers is 32 entries, for M6 and
M4 pipeline models, and 16 entries, for M2
pipeline model.
We use the SPEC2000 integer benchmark
suite. From them, we have collected traces
of the most representative 300 million instruc-
tion segment of each benchmark, following the
idea presented in [10]. Each program is com-
piled with the –O2 –non_shared options using
DEC Alpha AXP-21264 C/C++ compiler and
executed using the reference input set. Ta-
bles 2 and 3 show the workloads used in our
simulations. We have used workloads includ-
ing 2, 4, and 6 threads. Workloads are clas-
sified according to the characteristics of the
included benchmarks: with high instruction-
level parallelism (ILP), with bad memory be-
havior (MEM), or a mix of both (MIX). Due to
the characteristics of SPECint2000, with few
benchmarks that are really memory bounded,
MEM workloads are only feasible for 2 and 4
threads.
In each experiment, we strictly focus on the
period of time in which all the initial threads
share the processor. The objective in each case
is evaluating the behavior of each microarchi-
tecture with workloads of two, four and six
threads. This means that each simulation fin-
ishes as soon as one thread contained in the
evaluated workload finishes executing 300 mil-
lion instructions.
5 Simulation Results
In this section, we evaluate and com-
pare monolithic SMT, homogeneously dis-
tributed hdSMT, and heterogeneous dis-
tributed hdSMT processors. In order to make
a fairer comparison, for each microarchitec-
ture we evaluate both its raw performance
(IPC) and its performance per area ratio
(IPC/mm2
).
For each workload, three measurements are
given. As their names indicate, BEST and
WORST give the best (by applying an ora-
cle thread mapping policy) and worst possi-
ble thread-to-pipeline mapping. The HEUR
result gives the performance obtained by us-
ing the heuristic thread mapping policy pre-
sented in Section 2. Special cases are the base-
line (M8) and the two-threaded workloads of
homogeneous distributions (3M4 and 4M4).
Since the baseline is not multipipelined, no
thread-to-pipeline mapping policy is needed
and so only one measurement is given. In two-
threaded workloads, when all pipelines are of
the same sort the three measurements (BEST,
HEUR, WORST) coincide.
We show the raw performance (measured
in IPC) and performance per area ratio
(IPC/mm2
) results in Figs. 3 and 4 respec-
tively. In all cases, it is shown the harmonic
mean of all workloads of a same type and size.
From these results we can infer that hdSMT
achieves its goal of achieving better relative
results using fewer resources, obtaining a 13%
and 14% improvement in performance per
area ratio over monolithic SMT and homo-
geneously clustered SMT respectively. How-
ever, these results also point out that hdSMT
raw performance results are exceeded by SMT
ones. Comparing the baseline (M8) and best-
XVI Jornadas de Paralelismo, JP '2005 63
Wld Benchmarks T Wld Benchmarks T
2W1 eon, gcc I 4W1 eon, gcc, gzip, bzip2 I
2W2 crafty, bzip2 I 4W2 crafty, bzip2, eon, gzip I
2W3 gap, vortex I 4W3 gap, vortex, parser, crafty I
2W4 mcf, twolf M 4W4 mcf, twolf, vpr, perlbmk M
2W5 vpr, perlbmk M 4W5 vpr, perlbmk, mcf, twolf M
2W6 vpr, twolf M 4W6 gzip, twolf, bzip2, mcf X
2W7 gzip, twolf X 4W7 crafty, perlbmk, mcf, bzip2 X
2W8 crafty, perlbmk X 4W8 parser, vpr, vortex, twolf X
2W9 parser, vpr X 4W9 vpr, twolf, gap, vortex X
Table 2: Two and four threaded workloads (I=ILP, M=MEM, X=MIX)
Wld Benchmarks T
6W1 gzip, gcc, crafty, eon, gap, bzip2 I
6W2 gcc, crafty, parser, eon, gap, vortex I
6W3 gzip, vpr, mcf, eon, perlbmk, bzip2 X
6W4 vpr, mcf, crafty, perlbmk, vortex, twolf X
Table 3: Six threaded workloads.
0
1
2
3
4
5
6
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS 6 THREADS HMEAN
IPC
BEST
HEUR
WORST
a) ILP Workloads.
0
0,5
1
1,5
2
2,5
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS HMEAN
IPC
BEST
HEUR
WORST
b) MEM Workloads.
0
0,5
1
1,5
2
2,5
3
3,5
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS 6 THREADS HMEAN
IPC
BEST
HEUR
WORST
c) MIX Workloads.
Figure 3: Performance comparison.
performing hdSMT (1M6+2M4+2M2) means,
we got baseline speedups over hdSMT of 5%,
4% and 15% in ILP, MEM, and MIX work-
loads respectively. The ability to flush and
re-execute instructions of the baseline seems
crucial in the MIX scenario, which indicates
that the hdSMT results could be improved in
this sense. A deeper analysis also indicates
that these results could also be improved by
reducing the additional register file access de-
lay in hdSMT.
By comparing BEST and HEUR results,
these results also point out that the thread-
to-pipeline mapping policy is a crucial factor
in hdSMT architecture. As an example, no-
tice that the 2M4+2M2 hdSMT microarchi-
tecture obtains the highest performance per
area ratios in all but the four-threaded MEM
workload case. In that case, although the ora-
cle mapping policy obtains a 9% improvement
over the baseline, the heuristic accuracy drops
to 76%, resulting in a worse result than the
baseline. From Figs. 3 and 4 it is also notice-
able that the effectiveness of the mapping pol-
icy depends on the specific hdSMT microar-
chitecture. Thus, while the heuristic applied
in this work achieves 92% and 96% accuracy
in 2M4+2M2 and 1M6+2M4+2M2 microar-
chitectures respectively, its accuracy drops to
a 88% in 3M4+2M2 microarchitecture.
6 Related Work
Kumar et al. propose in [7] the Heteroge-
neous Multicore processor, a CMP processor
comprised of heterogeneous cores. In this pro-
posal, matching the inter-application hetero-
geneity with the statically partitioned hard-
64 Arquitectura del Procesador y Multiprocesadores
0
0,005
0,01
0,015
0,02
0,025
0,03
0,035
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS 6 THREADS HMEAN
IPC/Area
BEST
HEUR
WORST
a) ILP Workloads.
0
0,002
0,004
0,006
0,008
0,01
0,012
0,014
0,016
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS HMEAN
IPC/Area
BEST
HEUR
WORST
b) MEM Workloads.
0
0,005
0,01
0,015
0,02
0,025
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
M8
3M4
4M4
2M4+2M2
3M4+2M2
1M6+2M4+2M2
2 THREADS 4 THREADS 6 THREADS HMEAN
IPC/Area
BEST
HEUR
WORST
c) MIX Workloads.
Figure 4: Performance per Area comparison.
ware is, as in hdSMT, a prime issue. The
main difference between them comes from
their CMP/SMT inclinations. So, in case
of few applications running on the processor,
split resources accross CMP cores as physical
registers and L1 caches are wasted in a Hetero-
geneous Multicore processor. On the contrary,
an hdSMT can still utilize these resources to
improve the performance of the running appli-
cations.
Putting aside heterogeneity-awareness, we
find in the literature some prior work that
study the combination of clustering and SMT
techniques. Collins and Tullsen explore in [3]
the relation between clustering and SMT.
They show that the synergistic combination
of the two techniques minimizes the IPC im-
pact of the clustered architecture, and even
permits more aggressive clustering of the pro-
cessor than is possible with a single-threaded
processor. In contrast, the hdSMT approach
explores the benefits of a heterogeneous clus-
tering to obtain high performance at a reduced
complexity cost. Raasch and Reinhardt quan-
tify in [9] the performance impact of resource
partitioning policies in SMT machines, focus-
ing on the execution portion of the pipeline.
They found out that for storage resources,
such as the instruction queue, statically allo-
cating an equal portion to each thread pro-
vides good performance, in part by avoiding
starvation. In contrast, they also showed that
static division of issue bandwidth has a neg-
ative impact on throughput. SMTŠs ability
to multiplex bursty execution streams dynam-
ically onto shared functional units contributes
to its overall throughput. As we have shown in
this paper, a heterogeneous partition of issue
bandwidth can be possitive if it is appropri-
atily matched with the heterogeneous needs
of the running applications. The hdSMT ap-
proach also differs from these prior studies in
the granularity applied in the cluster distribu-
tion. Notice that in hdSMT entire threads are
assigned to pipelines, instead of the instruction
level applied in these studies. So, dependent
instructions are always executed in the same
cluster, avoiding additional latencies and com-
plexity.
7 Conclusions
The heteregeneity among application behav-
iors turns current architectures overdesigned
for most cases, obtaining high performance
but wasting a lot of resources to do so.
In this paper we have presented the Het-
erogeneously Distributed Simultaneous Multi-
threading (hdSMT) architecture, an SMT al-
ternative in which the running threads are
mapped to a heterogeneosly clustered hard-
ware according to this heterogeneity. The
results obtained in this work indicate that
hdSMT reduce this waste of resources at re-
duced budget, obtaining a 13% and 14% im-
provement in optimizing performance per area
over monolithic SMT and homogeneously clus-
tered SMT, respectively.
In hdSMT, the thread-to-pipeline mapping
policy is a prime concern. In this work, we
have presented a simple profile-based heuristic
policy that achieves a 92% average accuracy.
XVI Jornadas de Paralelismo, JP '2005 65
Raw performance results also point out that,
in future hdSMT implementations, this map-
ping should probably be made dynamically in
order to better adapt to the dynamic changes
in program behaviour during execution.
Acknowledgements
This work has been supported by the Min-
istry of Education of Spain under contract
TIN2004–07739–C02–01, CEPBA and the
HiPEAC European Network of Excellence.
Carmelo Acosta is also supported by the Min-
istry of Science and Technology of Spain grant
BES–2002–0015.
References
[1] J. Burns and J.L. Gaudiot, Quantifying the
SMT Layout Overhead - Does SMT Pull its
Weight?, in Proc. of HPCA-6, 2000.
[2] F. J. Cazorla, E. Fernandez, A. Ramirez,
and M. Valero, DCache Warn: An I-Fetch
Policy To Increase SMT Efficiency, in
Proc. of IPDPS-18, 2004.
[3] J. D. Collins and D. M. Tullsen, Clus-
tered Multithreaded Architectures Ű– Pur-
suing Both IPC and Cycle Time, in Proc.
of IPDPS-18, 2004.
[4] A. El-Moursy and D. H. Albonesi, Front-
End Policies for Improved Issue Efficiency
in SMT Processors, in Proc. of HPCA-9,
2003.
[5] L. Hammond, B. A. Nayfeh, and K.
Olukotun, Single-Chip Multiprocessor,
IEEE Computer Special Issue on Billion-
Transistor Processors, 1997.
[6] R. Kumar, K. Farkas, N. P. Jouppi, P.
Ranganathan, and D. M. Tullsen, Single-
ISA Heterogeneous Multi-Core Architec-
tures: The Potential for Processor Power
Reduction, in Proc. of MICRO-36, 2003.
[7] R. Kumar, D. M. Tullsen, P. Ranganathan,
N. P. Jouppi, and K. I. Farkas, Single-ISA
Heterogeneous Multi-core Architectures for
Multithreaded Workload Performance, in
Proc. of ISCA-31, 2004.
[8] K. Olukotun, B. A. Nayfeh, L. Hammond,
K. Wilson, and K. Chang, The case for
a single-chip multiprocessor, in Proc. of
ASPLOS-7, 1996.
[9] S. E. Raasch and S. K. Reinhardt, The
Impact of Resource Partitioning on SMT
Processors, in Proc. of PACT-12, 2003.
[10] T. Sherwood, E. Perelman, and B.
Calder, Basic Block Distribution Analysis
to Find Periodic Behavior and Simulation
Points in Applications, in Proc. of PACT-
10, 2001.
[11] U. Sigmund, M. Steinhaus, and T. Un-
gerer, On Performance, Transistor Count
and Chip Space Assessment of Multimedia-
enhanced Simultaneous Multithreaded Pro-
cessors, in Proc. of MTEAC-4, 2000.
[12] M. Steinhaus, R. Kolla, J. L. Larriba-
Pey, T. Ungerer, and M. Valero, Transis-
tor Count and Chip-Space Estimation of
SimpleScalar-based Microprocessor Mod-
els, in Proc. of WCED-2, 2001.
[13] M. Steinhaus, R. Kolla, J. L. Larriba-
Pey, T. Ungerer, and M. Valero, Tran-
sistor Count and Chip-Space Estimation of
Simulated Microprocessors, in Tech. Rep.
UPC-DAC-2001-16, 2001.
[14] D. M. Tullsen and J. A. Brown, Handling
long-latency loads in a simultaneous multi-
threaded processor, in Proc. of MICRO-34,
2001.
[15] D. M. Tullsen, S. Eggers, and H. M. Levy,
Simultaneous Multithreading: Maximizing
On-Chip Parallelism, in Proc. of ISCA-22,
1995.
[16] D. M. Tullsen, S. J. Eggers, J. S. Emer,
H. M. Levy, J. L. Lo and R. L. Stamm,
Exploiting Choice: Instruction Fetch and
Issue on an Implementable Simultaneous
Multithreading Processor, in Proc. of
ISCA-23, 1996.
66 Arquitectura del Procesador y Multiprocesadores

        

               
     
       

                 ! " # $  % !  &  ' ( & ) * +  ,   ) %
1
'
  -    ) ! .  & )  !
1
/ 0 1 2 3 4 1 2 5 6 3 0 7 8 9 : ; 3 < 8 9 = 3 > ? 9 6 @ 6 4 1 2 9 6 A 0 8 9 0 @ B 3 C @ 6 @ 2 ; 8 5 @ D
E F F G H
4 @ 2 @ 9 ? 3 @ ; D I > @ 8 0 3 D J 1 > B 9 K 9 > 1 8 @
F L M
D N
H
N
M O P
@ > 0 3 2 1 8 @ D Q R @ 9 8 D
? 6 3 R 7 @ 8 D
S
9 > T R 1 2 5 6 3 0 7 8 9 : ; 3 D 3 B ; U V 0 @ W 1 > 2 @ X @ > @
S
9 > 3 W X
S
@ 6 3 1 Y T @ 0 D ; R 0 D 3 B ;
1 P
@ > 0 3 2 1 8 @ Q ; R 3 > 0 1
S
R ; 6 9 8 Z C 3 8 6 3 > X
P
@ > 0 3 2 1 8 @ D Q R @ 9 8 D
[ \ ] ^ _ ` a ^
b c d e f g e h i j k l j l m i n o j p p n i p f q o i j k p j e h j f i m j i g
r
n i s k q o j t u k d d n v f q w e h i j k l p e n p h k i j h k i l g
v k i j i j p n c i o j p k e e h j p k s j e f s j x b k q u m i n g
m n p k d p h k y j t j j q l n q j f q e h j z b { d f e j i k e c i j
f q n i l j i e n o n q e i n d h n v i j p n c i o j p k i j p m d f e t j g
e v j j q e h i j k l p x
| y k d c k e f q w e h j f s m k o e n
r
e h j p j m i n m n p k d p i j g
}
c f i j p o h n n p f q w k s j e i f o e h k e
r
k f i d u i j ~ j o e p
e h j i j k d t j q j  e p x { h j n t € j o e f y j n
r
e h f p m k m j i
f p e n c q l j i p e k q l v h f o h s j e i f o p  e t j e e j i l j g
m j q l f q w n q e h j m c i m n p j n
r
e h j z b { m i n o j p p n i
c q l j i o n q p f l j i k e f n q x  j f q e i n l c o j ‚ ƒ „ … ƒ † ‡ ˆ ‰
Š ƒ ‹ Œ  k s j e i f o t k p j l n q s c d e f m d f o k e f y j p u s g
s j e i u  e h k e o k q t j k w n n l o h n f o j
r
n i j y k d c k e f q w
w j q j i k d m c i m n p j s c d e f g e h i j k l j l m i n o j p p n i p x
Ž  
^ _ ‘ ’ “ a ^ ” ‘

b c d e f e h i j k l j l k q l z f s c d e k q j n c p b c d e f g
e h i j k l j l • z b { – m i n o j p p n i p — ˜ ™  ˜ š  ˜ › œ 
f s m i n y j m j i
r
n i s k q o j t u k d d n v f q w p j y j i k d
e h i j k l p e n p h k i j i j p n c i o j p k e e h j p k s j e f s j x
 q e h j z b { d f e j i k e c i j  k d n e n
r
m i n m n p k d p
h k y j t j j q l n q j f q n i l j i e n f s m i n y j e h j
ž
m j i
r
n i s k q o j Ÿ n
r
z b { p x
b n p e n
r
e h j p j m i n m n p k d p
r
n o c p n q e h j f q p e i c o g
e f n q
r
j e o h m n d f o u  p f q o j f e f p k   j u m k i k s j e j i f q
m j i
r
n i s k q o j n
r
z b { m i n o j p p n i p — ˜ ¡ œ x  q — ˜ ¡ œ
p j y j i k d
r
j e o h m n d f o f j p k i j m i n m n p j l 
r
i n s v h f o h
v j j ¢ m d k f q e h j s k f q e v n x
£ f i p e  ‡ „ ¤ Œ ¥ ¦ ‡ „ § ˆ Œ
— ˜ ¡ œ f p e h j s n p e t k p f o
r
n i s n
r r
j e o h k q l p f s m d u
r
j e o h j p f q p e i c o e f n q p
r
i n s k d d e h i j k l p k d e j i q k g
e f y j d u  l f p i j w k i l f q w e h j i j p n c i o j c p j n
r
j k o h
e h i j k l x z j o n q l  ˆ ‰ „ ¤ Œ † — ˜ ¡ œ m i f n i f e f ¨ j p e h i j k l p
v f e h
r
j v f q p e i c o e f n q p f q e h j m i j g f p p c j p e k w j p x
£ i n s e h j m n d f o f j p m i j p j q e j l f q — ˜ ¡ œ f o n c q e m i n g
y f l j p e h j t j p e m j i
r
n i s k q o j i j p c d e p x { h j f o n c q e
m n d f o u m i j p j q e p w n n l i j p c d e p
r
n i e h i j k l p v f e h
h f w h  © ª x « n v j y j i  z b { p h k y j p m j o f k d m i n t g
d j s p  q n e k l l i j p p j l t u j f e h j i i n c q l g i n t f q n i
f o n c q e  e h k e s k u o k c p j k p f w q f  o k q e m j i
r
n i g
s k q o j l i n m x { h j p j m i n t d j s p k i j e v n ¬
•
© n q w g d k e j q o u s j s n i u n m j i k e f n q p ¬  h j q
k e h i j k l j ¢ j o c e j p k d n q w d k e j q o u n m j i k e f n q
f e c p j p i j p n c i o j p
r
n i k d n q w e f s j  l j w i k l g
f q w e h j m j i
r
n i s k q o j n
r
e h j n e h j i e h i j k l p x
z n s j
r
j e o h m n d f o f j p e i u e n p n d y j e h f p
m i n t d j s t u p e k d d f q w n i p
}
c k p h f q w e h n p j
e h i j k l p j ¢ m j i f j q o f q w d n q w g d k e j q o u n m j i k g
e f n q p  d f   j o k o h j s f p p j p x z n s j n
r
e h j p j
m n d f o f j p k i j e h j
r
n d d n v f q w ¬ ­ k e k w k e f q w — ¡ œ 
ª i j l f o e f y j ­ k e k ® k e f q w — ¡ œ  ­  k i q — ¯ œ 
­ ° ± ² — ˜ œ  z { ² © © — ˜ ³ œ  £ © ´ z « — ˜ ³ œ  k q l
­ ° g ª ± | ­ — µ œ x
• ¶
i k q o h s f p p m i j l f o e f n q p ¬ ± j p n c i o j p k q l
m n v j i k i j v k p e j l t u j ¢ j o c e f q w f q p e i c o g
e f n q p k d n q w k s f p m i j l f o e j l m k e h  k q l
f o n c q e k p p f w q p m i f n i f e f j p l f p i j w k i l f q w e h j
r
k o e e h k e k e h i j k l s k u t j n q k v i n q w
DC-PRED STALL PDG DG
AGSTALL FPG
ICOUNT
BRANCH SPECULATION LONG LATENCY OPERATIONS
FLUSH
I 9 Z ; > 3
F
Q 0 7 3
S
@ 1 V 6 7 3 > 3 2 @ 6 3 B R 1 2 9 0 9 3 ?
p m j o c d k e f y j m k e h x z n s j o c i i j q e m n d f o f j p 
d f   j
ƒ † ‰   ‡ ˆ „ ‡ ˆ † ˆ  ˆ Œ  ‹ Œ ¥ ‚ ‹ † ˆ Œ  •
r
m w –
—  œ  k q l  ‚  † ‹ — › œ v n i   n q e n m n
r
f o n c q e
• p j j £ f w c i j ˜ –  k q l k l l t i k q o h p m j o c d k g
e f n q o n q e i n d e n i j l c o j e h f p v k p e j x { h j p j
m n d f o f j p n t e k f q k p f w q f  o k q e i j l c o e f n q f q
v k p e j k q l k p d f w h e f s m i n y j s j q e f q e n e k d
 ª ° • e h i n c w h m c e – x
b k q u n
r
e h j p j m n d f o f j p v j i j j y k d c k e j l c p g
f q w l f
j i j q e s j e i f o p x | y j q  p n s j k c e h n i p c p j l
e v n s j e i f o p d j k l f q w e n l f
j i j q e o n q o d c p f n q p l j g
m j q l f q w n q e h j s j e i f o c p j l x  q e h f p v k u  w d n t k d
o n s m k i f p n q n
r
k d d e h j p j s j e h n l p f p y j i u l f  g
o c d e x  q n i l j i e n
r
k f i d u o n s m k i j k d d m i n m n p k d p
v j q j j l e n h k i s n q f ¨ j s j e i f o p
r
n i e h j j y k d c k g
e f n q n
r
z b { m i n o j p p n i m j i
r
n i s k q o j x
 q e h f p m k m j i  v j p h n v e h j m i n m j i e f j p n
r
k d d
s j e i f o p m i n m n p j l f q e h j z b { d f e j i k e c i j k q l
v j k d p n o n s m k i j e h j s x  c i i j p c d e p p h n v e h k e
p n s j s j e i f o p s k u m i n y f l j q n q g o n h j i j q e i j g
p c d e p  p n e h k e e h j u p h n c d l t j c p j l o k i j
r
c d d u x
£ f q k d d u  v j m i j p j q e e h j ® j n s j e i f o b j k q s j e g
i f o
r
n i e h j j y k d c k e f n q n
r
z b { m i n o j p p n i p x
{ h f p m k m j i f p n i w k q f ¨ j l k p
r
n d d n v p ¬ z j o e f n q
¯ m i j p j q e p e h j s j e i f o p e h k e h k y j t j j q v f l j d u
c p j l f q m i j y f n c p z b { d f e j i k e c i j x z j o e f n q ³ f q g
e i n l c o j p e h j ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ  k s j e i f o e h k e
q n e u j e c p j l  f q e h j z b { d f e j i k e c i j  k q l e h k e
o k q t j k w n n l o n s m i n s f p j
r
n i e h j | y k d c k e f n q
n
r
z b { m j i
r
n i s k q o j x z j o e f n q ¡ j ¢ m d f o f e p e h j
m i n m j i e f j p q j j l j l
r
n i s j e i f o p
r
n i z b { m i n o j p g
p n i x z j o e f n q š  q k d d u o n s m k i j p e h j t j h k y f n i n
r
l f
j i j q e s j e i f o p n q k q k i e f  o f k d j ¢ k s m d j x £ f g
q k d d u  z j o e f n q › f p l j y n e j l e n e h j o n q o d c p f n q p x

_   ” ‘ “ ]   ^ _ ” a ]
 q e h f p p j o e f n q v j p h n v e h j s j e i f o p k d i j k l u
m i n
m n p j l f q e h j z b { d f e j i k e c i j x  q e h j
r
n i g
s c d k p c p j l t j d n v
n
i j m i j p j q e p e h j q c s t j i n
r
e h i j k l p 
t ∈ W
i j m i j p j q e p e h j e h i j k l p f q k
v n i   d n k l
W

IPCtW
e h j  ª ° n
r
k e h i j k l
t
f q
e h j v n i   d n k l   k q l
IPCtalone
e h j  ª ° n
r
k
e h i j k l
t
v h j q f e f p j ¢ j o c e j l f q f p n d k e f n q n q e h j
m i n o j p p n i x { h j s j e i f o p k i j e h j
r
n d d n v f q w ¬
•
{ h i n c w h m c e ¬ { h f p s j e i f o f p e h j p c s n
r
e h j  ª ° p n
r
k d d e h i j k l p f q k w f y j q v n i   d n k l
k p p h n v q f q j
}
c k e f n q ˜
T put =


t∈W
IPCtW
• ˜ –
{ h f p s j e i f o n q d u d n n   p k e e h j e n e k d  ª ° 
i j w k i l d j p p n
r
e h j e u m j n
r
e h i j k l x  e s j k g
p c i j p e h j c e f d f ¨ k e f n q n
r
i j p n c i o j p ¬ e h j
h f w h j i e h j e h i n c w h m c e  e h j h f w h j i e h j i j g
p n c i o j c e f d f ¨ k e f n q x  e w f y j p s c o h f s m n i g
e k q o j e n h f w h g  ª ° e h i j k l p  e h n p j e h i j k l p
e h k e h k y j h f w h  q p e i c o e f n q © j y j d ª k i k d g
d j d f p s •  © ª – k q l
r
j v o k o h j s f p p j p x  e m k u p
d j p p k e e j q e f n q e n d n v g  ª ° e h i j k l p    
m i n w i k s p n i e h i j k l p j ¢ m j i f j q o f q w o k o h j
s f p p j p x  e f p e h j  i p e s j e i f o c p j l e n o h j o  
e h j m j i
r
n i s k q o j n
r
k z b { — ˜ ¡  ˜ š  ˜ › œ  k p
f e k d d n v p k o d n p j o n s m k i f p n q v f e h p f q w d j g
e h i j k l j l m i n o j p p n i p x
•
 j f w h e j l z m j j l c m ¬ f e f p e h j k y j i k w j
s j k q n
r
e h j ‡ ƒ ‹ † ˆ  ƒ    n
r
e h j e h i j k l p
f q k v n i   d n k l  v h j i j e h j i j d k e f y j  ª ° f p
l j  q j l k p
relative IPC =
IP CtW
IP Ct alone
x
68 Arquitectura del Procesador y Multiprocesadores

    
    



T put W S W Sicount

        

               
                    
{ k t d j ˜ ¬  q o n q p f p e j q o u n
r
W S
k q l
W Sicount
W S =
1
n


t∈W
IPCtW
IPCtalone
• ¯ –
{ h f p s j e i f o m k u p s n i j k e e j q e f n q e n d n v
 ª ° e h i j k l p  t u n q d u d n n   f q w k e q n i s k d g
f ¨ j l  ª ° — ˜ ¯ œ x  q — ˜ ˜ œ  z k ¨ j f l j p k q l  c k q
f q e i n l c o j  Š  ¦   ƒ ƒ ¥ ¤  e h k e f p j
}
c k d e n
n ∗ W S
x { h f p s j e i f o p h n v p e h j t j q j g
 e n t e k f q j l t u j ¢ j o c e f q w k v n i   d n k l f q
z b { s n l j o n s m k i j l e n p c o o j p p f y j p f q w d j
e h i j k l j l s n l j x
•
 °  ´ {  j f w h e j l z m j j l c m — ˜ ³ œ ¬ { h f p
s j e i f o f p k y k i f k q e n
r
e h j  j f w h e j l
z m j j l c m s j e i f o x  e c p j p k p t k p j d f q j e h j
 ª ° n
r
j k o h e h i j k l n t e k f q j l v h j q e h j
 °  ´ {
r
j e o h m n d f o u f p c p j l x { h f p y k i f g
k q e l n j p q n e e k   j f q e n k o o n c q e w d n t k d m j i g
r
n i s k q o j n
r
e h i j k l p t c e e h j p m j j l c m n
r
e h j m n d f o u o n s m k i j l v f e h  °  ´ { x  e f p
l j  q j l f q j
}
c k e f n q ³ x
W Sicount =
1
n


t∈W
IPCtW
IPCtW icount
• ³ –
« n v j y j i  c p f q w t n e h
W S
k q l e h f p y k i f g
k q e o k q w f y j n m m n p f e j i j p c d e p x { k t d j
˜ p h n v p k q j ¢ k s m d j v h j i j
T put

W S
k q l
W Sicount
l n q ! e h k y j o n h j i j q e i j g
p c d e p x { h f p e k t d j p h n v p e h j  ª ° n
r
e h j
e v n e h i j k l p f q k w f y j q v n i   d n k l x ´ p f q w
k q n e h j i t k p j d f q j o n s m d j e j d u o h k q w j p e h j
s j e i f o x { h j k i f e h s j e f o s j k q n
r
q n i s k d g
f ¨ j l l k e k s c p e t j k q k d u ¨ j l o k i j
r
c d d u x
•
z e k q l k i l ­ j y f k e f n q £ i n s ² y j i k w j b j k q ¬
{ h f p s j e i f o s j k p c i j p e h j l j y f k e f n q n
r
e h i j k l ! p i j d k e f y j  ª °
r
i n s e h j s j k q k y g
j i k w j n
r
e h j  ª ° p n
r
e h j e h i j k l f q k v n i   g
d n k l x  e € c p e i j m i j p j q e p
r
k f i q j p p k q l l n j p
q n e e k   j f q e n k o o n c q e k o e c k d  ª ° y k d c j p x
´
p j l v f e h e h j e v n m i j y f n c p s j e i f o p m i n g
y f l j p k w n n l o n s m i n s f p j x
•
² y j i k w j £ j e o h ª i f n i f e u ­ j y f k e f n q ¬ { h f p
s j e i f o s j k p c i j p e h j l f
j i j q o j f q e h j k o g
o j p p e n i j p n c i o j p x  q m k i e f o c d k i f e
r
n g
o c p j p n q e h j
r
j e o h t k q l v f l e h c p j l t u j k o h
e h i j k l x ² p s k d d l j y f k e f n q f q e h j
r
j e o h c p j
s k l j t u k d d e h i j k l p f q k v n i   d n k l f s m d f j p
s n i j
r
k f i q j p p — " œ k q l y f o j g y j i p k x ² p e h j
z e k q l k i l ­ j y f k e f n q  f e n q d u d n n   p k e
r
k f i g
q j p p k q l h k y j q n q n e f n q n
r
m j i
r
n i s k q o j x
•
« k i s n q f o b j k q ¬ { h f p s j e i f o s j k p c i j p
e h j s j k q n
r
e h i j k l ! p i j d k e f y j ° ª  • ° u o d j
ª j i  q p e i c o e f n q – x  e e k   j p
r
k f i q j p p f q e n k o g
o n c q e x  e m i n e j o e p
r
i n s w f y f q w s k q u i j g
p n c i o j p e n k e h i j k l k q l p e k i y f q w k q n e h j i
n q j x  q e h f p o k p j  « s j k q o n q y j i w j p e n
0
x
Hmean =
n


t∈W
IPCtalone
IPCtW
• ¡ –
{ h j p j k i j e h j s j e i f o p m i n m n p j l f q e h j z b {
d f e j i k e c i j x j ¢ e  v j m i j p j q e e h j ® j n s j e i f o
b j k q
r
n i j y k d c k e f q w z b { p m j i
r
n i s k q o j x
# $ %
 &  ‘ '  ^ _ ” a   `

£ d j s f q w k q l  k d d k o j f q e i n l c o j ‚ ƒ „ … ƒ † ‡ ˆ ‰
Š ƒ ‹ Œ e n s k   j e h j s j k q t j e v j j q q n i s k d f ¨ j l
l k e k p c o h k p t j q o h s k i   i j p c d e p — š œ x  q e h f p m k g
m j i  v j j ¢ e j q l e h j c p j n
r
‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ e n
e h j z b { k i j k x  j m i n m n p j k p s j e i f o e h j ® j g
n s j e i f o b j k q t j e v j j q e h j  ª ° n
r
e h j e h i j k l p
f q k w f y j q v n i   d n k l x
{ h j ® j n s j e i f o b j k q •
GM
– n
r
e h j  ª ° n
r
e h j
n
e h i j k l p n
r
k v n i   d n k l f p l j  q j l k p p h n v q
f q j
}
c k e f n q š x
XVI Jornadas de Paralelismo, JP '2005 69
• k – ® j n s j e i f o b j k q
• t –  j f w h e j l z m j j l c m
I 9 Z ; > 3
G

1 B 9  3 > 3 8 6 > 3 R > 3 ? 3 8 6 @ 6 9 1 8 ? 1 V 6 7 3 R > 1
L
0 3 ? ? 1 > R 3 > V 1 >
S
@ 8 0 3
GM = n

t∈W
IPCt
• š –
® b k m m d f j p v j d d
r
n i k v n i   d n k l n
r
o n n m j i g
k e f y j e h i j k l p x  e o k q t j p j j q k p k m n f q e f q
k q g l f s j q p f n q k d p m k o j  v h j i j e h j k ¢ f p i j m i j g
p j q e p e h j  ª ° n
r
j k o h e h i j k l f q e h j v n i   d n k l 
p j j £ f w c i j ³ • k – x  q o i j k p f q w e h j ® j n s j e i f o
b j k q s j k q p e n f q o i j k p j e h j y n d c s j n
r
e h j
q g l f s j q p f n q k d t n ¢ x ° n s m k i k e f y j d u  { h i n c w h g
m c e m j i o j f y j p m i n o j p p n i m j i
r
n i s k q o j k p e h j d f q g
j k i p c s n
r
k d d e h i j k l p  ª ° k p p h n v q f q £ f w g
c i j ³ • t – x
 q n i l j i e n q n i s k d f ¨ j e h j ® b v f e h e h j
 j f w h e j l z m j j l c m k q l e h j « k i s n q f o b j k q v j
f q e i n l c o j k o n q p e k q e ¬
GMalone = n

t∈W
IPCt alone
• › –
´ p f q w e h f p o n q p e k q e v j m i n m n p j  „ ‡ … ‹ ˆ  ƒ ¥
‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ 
NGM = GM
GMalone
 e h k e f p k q
f q e j i s j l f k e j s j e i f o v f e h i j p m j o e e n  ƒ ˆ   † ƒ ¥
  ƒ ƒ ¥ ¤  k q l  ‹ ‡ … „ Œ ˆ ‰ Š ƒ ‹ Œ x { h j ® b 
« s j k q  k q l  z
r
n d d n v e h j
r
n d d
n v f q w i c d j ¬
min
t∈W
IPCtW
IPCt alone
< Hmean < NGM < . . .
. . . < W S < max
t∈W
IPCtW
IPCt alone
• µ –
j ¢ e  v j p h n v p n s j f q e j i j p e f q w m i n m j i e f j p
n
r
e h j ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ x
  
  
  
® f y j q e h k e q n e h i j k l o k q w n
r
k p e j i v h j q o n g
p o h j l c d j l e h k q v h j q f e f p j ¢ j o c e j l k d n q j  v j
h k y j k d n v j i t n c q l
r
n i e h j i j d k e f y j  ª ° n
r
k q u
e h i j k l f q e h j v n i   d n k l ¬
IPCωW
IPCtalone
>
Hmean
n − (n − 1) ∗ Hmean
•  –
IPCωW
IPCtalone
> NGMn • " –
|
}
c k e f n q p  k q l " k i j e i c j
r
n i e h j j q e f i j j ¢ j o c g
e f n q n
r
e h j v n i   d n k l p x { h j u k i j
ž
k m n p e j i f n i f Ÿ
j
}
c k e f n q p x { h j p j j
}
c k e f n q p o k q    t j c p j l
r
n i z k
r
j ± j k d g { f s j z u p e j s p k p e h j u w f y j q n
p k
r
j t n c q l x
         
     
       
b c d e f m d u f q w k e h i j k l ! p  ª ° t u k
r
k o e n i
x
k q l
k q n e h j i e h i j k l ! p  ª ° t u k
r
k o e n i
1/x
i j p c d e p
f q q n o h k q w j
r
n i e h j s j e i f o ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ 
i j w k i l d j p p n
r
e h j e h i j k l p x
GM(IPC1, IPC2) = GM(x∗IPC1,
1
x
∗IPC2)
• ˜ ™ –
{ h f p m i n m j i e u w f y j p k
r
c d d s c d e f m d f o k e f y j p u s g
s j e i u n y j i k d d e h i j k l p x ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ f p e h j
n q d u s j e i f o e h k e k p p j i e p j
}
c k e f n q ˜ ™  v h f o h f p
p c m m n p j l e n t j e h j q k e c i k d o n s m i n s f p j t j g
e v j j q e h i n c w h m c e k q l
r
k f i q j p p x { h f p y k d f g
l k e j p ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ k p k p e k q l k i l s j e i f o
r
n i b c d e f g e h i j k l j l m i n o j p p n i p x
70 Arquitectura del Procesador y Multiprocesadores

    
    



GM NGM RGMP 1/icount

        

         
     
                
  
 
{ k t d j ¯ ¬ ° n q p f p e j q o u n
r
e h j ® j n s j e i f o b j k q
   
     
   
   
   
 h j q o n s m k i f q w e v n l f
j i j q e s j e h n l p  u n c
n q d u q j j l e n s k   j e h j i k e f n t j e v j j q e h j s ¬
RGM1/2 =
GM1
GM2
= n


t∈W
IPC1
t
IPC2
t
• ˜ ˜ –
{ h j i j
r
n i j  e h j i j p c d e f p q n e q n i s k d f ¨ k e f n q g
l j m j q l j q e k p v h j q o n s m k i f q w s j e h n l p v f e h
 ‹ ‡ … „ Œ ˆ ‰ Š ƒ ‹ Œ n i  ƒ ˆ   † ƒ ¥   ƒ ƒ ¥ ¤  x { h j
p u s s j e i u n
r
e h j ® j n s j e i f o b j k q j q p c i j p k
w d n t k d f s m i n y j s j q e v h j q
RGM > 1
x  h j q
RGM = 1
 t n e h s j e i f o p k i j o n q p f l j i j l
j
}
c k d p  c p f q w e h j m i j y f n c p o n s m i n s f p j t j g
e v j j q e h i n c w h m c e k q l
r
k f i q j p p • ˜ ™ – x { n c p j
GM
f e f p q n e q j o j p p k i u e n o n s m c e j e h j  ª °
n
r
e h i j k l p v h j q e h j u k i j p o h j l c d j l k d n q j n q
e h j m i n o j p p n i x  n c € c p e q j j l e n j ¢ j o c e j u n c i
v n i   d n k l n q e h j l f
j i j q e m i n o j p p n i p k q l u n c
o k q s k   j e h j o n s m k i f p n q v f e h n q d u e h f p l k e k x
{ k t d j ¯ p h n v p k q j ¢ k s m d j
r
n i k v n i   d n k l
v f e h e v n e h i j k l p x  q e h k e j ¢ k s m d j  v j o k q n t g
p j i y j e h k e e h j
GM

NGM
 k q l
RGM1/2
m i n g
y f l j p e h j p k s j o n q o d c p f n q ¬  „ ˆ ‰
f p ˜  x ¡ 
v n i p j e h k q f o n c q e x

  ^ _ ” a ]   a ^ ” ‘

 q o j v j h k y j p j j q k d d s j e i f o p m i n m n p j l f q e h j
d f e j i k e c i j k p v j d d k p n c i m i n m n p k d  e h j
}
c j p g
e f n q f p h n v e n p j d j o e k s j e i f o x { h j   j u m n f q e
f p e h k e k s j e i f o p h n c d l h k y j k w n n l o n s m i n g
s f p j t j e v j j q e h i n c w h m c e  p u s s j e i u t j e v j j q
e h i j k l p  k q l
r
k f i q j p p x  j v f d d e i u e n c p j s j e g
i f o p e h k e n t j u e h j
r
n d d n v f q w p j e n
r
i c d j p ¬
•
b k ¢ f s c s ª j i
r
n i s k q o j ¬ { h j y k d c j n
r
e h j
s j e i f o c q l j i o n q p f l j i k e f n q p h n c d l t j k
o n q e f q c n c p f q o i j k p f q w
r
c q o e f n q n
r
e h j  ª °
n
r
e h j e h i j k l p f q k v n i   d n k l x
•
z u s s j e i u ¬ { h j s j e i f o p h n c d l q n e l j g
m j q l n q e h j o h k i k o e j i f p e f o p n
r
k e h i j k l 
t c e n q d u n q f e p i j d k e f y j  ª ° x
•
£ k f i q j p p ¬ b k ¢ f s c s
r
k f i q j p p f p k o h f j y j l
v h j q k d d e h i j k l p f q k v n i   d n k l w n k e e h j
p k s j i j d k e f y j p m j j l x
•
± j m i j p j q e k e f y j q j p p ¬ { h j s j e i f o p h n c d l
i j m i j p j q e m i n o j p p n i p m j i
r
n i s k q o j  k q l
w f y j k q j p e f s k e j n
r
e h i j k l p m j j l x
•
n z e k i y k e f n q ¬  h j q k e h i j k l
t
f p
p e k i y j l  e h k e f p 
IPCtW = 0
 e h j y k d c j
n
r
e h j s j e i f o p h n c d l t j j
}
c k d e n
0
x
{ h j e v n s j e i f o p e h k e k o o n s m d f p h v f e h s n p e
n
r
e h j p j i c d j p k i j  ‹ ‡ … „ Œ ˆ ‰ Š ƒ ‹ Œ k q l  „ ‡ ¦
… ‹ ˆ  ƒ ¥ ‚ ƒ „ … ƒ † ‡ ˆ ‰ Š ƒ ‹ Œ x { h j  ¤ ‹ ˆ † „

 ƒ ‡ ¦
 ˆ ‰ ƒ   ‹ ‰ ƒ n i  „    ‹ ‰ ƒ — ³ œ f p k w n n l v k u n
r
p h n v f q w e h j t j h k y f n i n
r
e h j l f
j i j q e s j e i f o p x
£ f w c i j ¯ p h n v p k q j ¢ k s m d j n
r 
n z p m k o j v h j q
e h j i j k i j ¯ e h i j k l p x  q e h f p p m k o j  k ¢ f p i j m i j g
p j q e e h j i j d k e f y j  ª ° n
r
j k o h e h i j k l x  q £ f w c i j
¯ • k – k q u m n f q e
X, Y
d j k l p e n e h j y k d c j ™ x š n
r
e h j o n i i j p m n q l f q w s j e i f o x { h k e f p  v h j q e h j
 i p e e h i j k l i c q p k e k i j d k e f y j  ª ° n
r 
 k q l
e h j p j o n q l k e k i j d k e f y j  ª ° n
r
  e h j q  e h j
y k d c j n
r
e h j o n i i j p m n q l f q w s j e i f o f p ™ x š  q  w g
c i j ¯ • t – k d d m n f q e p f q j k o h o c i y j d j k l e n e h j
y k d c j ™ x ¯ x
 
‘ '  ` _ ” ] ‘

‘  ^
%
 '  ^ _ ” a ]
 q £ f w c i j ¡ v j m i j p j q e k i e f  o f k d i j p c d e p k q l
e h j y k d c j e h j u v n c d l n t e k f q v f e h e h j l f
j i j q e
s j e i f o p x j ¢ e v j k q k d u ¨ j e h j p j y k d c j p
r
n i  y j
k i e f  o f k d i j p c d e p e h k e p h n v l f
j i j q e k p m j o e p n
r
e h j s j e i f o p x
£ f w c i j ¡ p h n v p e h j i j d k e f y j  ª ° n
r r
n i ¡ g
e h i j k l v n i   d n k l
r
n i l f
j i j q e k i e f  o f k d p f e c k g
e f n q p x | k o h i n v f p l j y n e j l e n j s m h k p f ¨ j k
m k i e f o c d k i o h k i k o e j i f p e f o n
r
e h j s j e i f o p x
XVI Jornadas de Paralelismo, JP '2005 71
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
Thread
2
Relative
IPC
Thread 1 Relative IPC
QoS Space
Better performance
Fairness line
iso-Throughput
iso-WS
iso-GM
iso-Hmean
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
Thread
2
Relative
IPC
Thread 1 Relative IPC
QoS Space
Better performance
Fairness line
iso-Throughput
iso-WS
iso-GM
iso-Hmean
• k – { h j y k d c j n
r
k d d s j e i f o p f p ™ x š • t – { h j y k d c j n
r
k d d s j e i f o p f p ™ x ¯
I 9 Z ; > 3
M
9 ? 1
S
3 6 > 9 0 0 ; > = 3 ? V 1 >
G L
6 7 > 3 @ B


1 > 2 1 @ B ?
•
• ² – £ k f i q j p p ¬  j p j j e h k e v h j q k d d
e h i j k l p j ¢ j o c e j k e e h j p k s j i j d k e f y j  ª °
x
 k d d s j e i f o p w f y j e n e h j v n i   d n k l e h j
p k s j y k d c j
x
x £ k f i q j p p f p k q j k p u i j m g
i j p j q e k e f n q n
r
e h j y k d c j n t e k f q j l v f e h k
s j e i f o ¬ v h j q s j e i f o
A
m i n y f l j p e h j y k d c j
x
r
n i
r
k f i q j p p e h j q  f e o n q p f l j i p e h f p p n g
d c e f n q f p k p w n n l k p f
r
k d d e h i j k l p v h j i j
j ¢ j o c e j l k e e h j i j d k e f y j  ª °
x
x
•
•
¶
– « s j k q ¬ « s j k q ! p t j p e p o n i j x { h j
h f w h j p e y k d c j
r
n i e h j « s j k q o n s j p v h j q
q n e h i j k l h k p i j o j f y j l k p j y j i j l i k v t k o  
f q f e p i j d k e f y j  ª ° x
•
• ° –  z ¬  q e h f p o k p j  e h i j j e h i j k l p k i j
j ¢ j o c e j l q j k i d u k e
r
c d d p m j j l  t c e n q j
e h i j k l f p p e k i y f q w  w n f q w k e
2%
n
r
f e p n i f w g
f q k d p m j j l ¬
W S
w f y j p e h j t j p e y k d c j n
r
k d d j ¢ k s m d j p  v h j i j k p
Hmean
o n q p f l j i p
f e f p d f   j k d d e h i j k l p v h j i j j ¢ j o c e j l k e
d j p p e h k q
8%
n
r
e h j f i n i f w f q k d
r
c d d p m j j l x
{ h j p j e v n s j e i f o p s k u t j o n q p f l j i j l k p
n m m n p f e j j ¢ e i j s j p x 
r
v j c p j e h f p p o h j l c d j
r
n i k h k d
r
n
r
e h j e f s j k q l e h j q p o h j l c d f q w
e h j
r
n c i e h e h i j k l k d n q j
r
n i e h j n e h j i h k d
r

e h j q v j v n c d l n t e k f q i j d k e f y j  ª ° p d f e e d j
p s k d
d j i e h j q f q p n d c e f n q
ž
² ¬ £ k f i Ÿ x
•
• ­ – | w n f p s ¬  q j e h i j k l j ¢ j o c e j p q j k i d u
k e f e p
r
c d d p m j j l k q l e h j i j s k f q l j i e h i j j
k e
1/3
n
r
e h j f i n i f w f q k d p m j j l x  e p k e f p g
 j p q n s j e i f o t c e i j k o h j p e h j t j p e p f q w d j
e h i j k l i j d k e f y j  ª ° x
•
• | – ® b ¬ { v n e h i j k l p k i j w n f q w q j k i d u k e
r
c d d p m j j l k q l e v n n e h j i p w n f q w k e
30%
n
r
e h j f i n i f w f q k d
r
c d d p m j j l x  e i j k o h j p
e h j t j p e y k d c j
r
n i
GM
x ° n s m k i j l e n
e h j
ž
² ¬ £ k f i Ÿ p n d c e f n q  f e h k p q j k i d u l n c g
t d j l
(+80%)
e v n e h i j k l p  ª ° v h f d j i j g
l c o f q w t u
40%
e h j e v n n e h j i e h i j k l p m j i g
r
n i s k q o j x


‘

a “ ] ” ‘

b k q u m i n m n p k d p h k y j t j j q l n q j f q n i l j i e n
f s m i n y j e h j
ž
m j i
r
n i s k q o j Ÿ n
r
z b { m i n o j p p n i p x
{ h j p j d j o e f n q n
r
k q k m m i n m i f k e j s j e i f o f p k   j u
p e j m f q n i l j i e n
r
k f i d u o n s m k i j e h j p j m i n m n p k d p x
 ƒ ˆ   † ƒ ¥   ƒ ƒ ¥ ¤  n q d u d n n   p k e p m j j l c m x  e
o n s m d j e j d u d k o   p n
r r
k f i q j p p  k q l l n j p q n e w c k i g
72 Arquitectura del Procesador y Multiprocesadores

  
   

 


  
i j d k e f y j  ª ° p s j e i f o p
 ª ° ˜  ª ° ¯  ª ° ³  ª ° ¡  z ® b « s j k q
² ¬ £ k f i q j p p ™  š ™  š ™  š ™  š ™  š ™  š ™  š
¶
¬ « s j k q ™  › š ™  š ¯ ™  ¡ š ™  ¡ š ™  š ˜ µ ™  š ˜ ˜     
° ¬  z ™  " ¡ ™  " ³ ™  " ˜                 
­ ¬ | w n f p s     ™  ³ › ™  ³ š ™  ³ ¡    ™  ¡ ¡ " ™  ¡ ˜ š
| ¬ ® b ™  " ˜ ™  " ™  ³ ™  ¯ " ™  ›      ™  ¡ ¡ š
    


 
  ! " #

! 

  

        $   %
I 9 Z ; > 3
O &
3 ? ; 2 6 ? 1 ' 6 @ 9 8 3 B


9 6 7 B 9  3 > 3 8 6
S
3 6 > 9 0 ?
k q e j j e h k e e h j i j f p q n p e k i y k e f n q n
r
k m k i e f o c d k i
e h i j k l x  h j q e h j m c i m n p j f p e n h k y j s k ¢ g
f s c s
r
k f i q j p p   ‹ ‡ … „ Œ ˆ ‰ … ƒ ‹ Œ  e k   f q w d j p p
o k i j n
r r
k p e e h i j k l p  w f y j p k s n i j i j d f k t d j d n v j i
t n c q l n q p d n v e h i j k l p x  ‹ ‡ … „ Œ ˆ ‰ … ƒ ‹ Œ l f p g
i j w k i l p p u s s j e i u k q l j
}
c k d f e u k s n q w e h i j k l p
e n f q o i j k p j
r
k f i q j p p x
 q e h f p m k m j i v j h k y j m i n m n p j l ‚ ƒ „ … ƒ † ‡ ˆ ‰
… ƒ ‹ Œ k p s j e i f o
r
n i z b { m i n o j p p n i p x  q e h j
w j q j i k d o n q e j ¢ e n
r
o n n m j i k e f y j e h i j k l p v f e h
r
k f i q j p p  e h j ® j n s j e i f o s j k q h k p e h j k l y k q g
e k w j n
r
t k d k q o f q w
r
k f i q j p p k q l e h i n c w h m c e 
v h f d j o n q p j i y f q w p u s s j e i u k s n q w e h i j k l p x  e
f p j k p u e n j y k d c k e j k q l w f y j p f s s j l f k e j c q g
l j i p e k q l f q w n
r
e h j w k f q p n t e k f q j l x ² d p n c p j l
e n p c s s k i f ¨ j t j q o h s k i   i j p c d e p  ‚ ƒ „ … ƒ † ‡ ˆ ‰
Š ƒ ‹ Œ k m m j k i p e n t j k p e k q l k i l s j e i f o k l k m e j l
r
n i m j i
r
n i s k q o j j y k d c k e f n q n
r
z f s c d e k q j n c p
b c d e f g { i j k l j l m i n o j p p n i p x
[ a (

‘ )  ’ * ' 

^ ]
{ h f p v n i   h k p t j j q p c m m n i e j l t u e h j b f q g
f p e i u n
r
z o f j q o j k q l { j o h q n d n w u n
r
z m k f q c q l j i
XVI Jornadas de Paralelismo, JP '2005 73
o n q e i k o e p {  ° g ¯ ™ ™ ˜ g ™ " " š g ° ™ ¯ g ™ ˜  {  ° g ¯ ™ ™ ¡ g
™ µ µ ³ " g ° ™ ¯ g ™ ˜  k q l w i k q e £ ª g ¯ ™ ™ ˜ g ¯ › š ³ • £ i k q g
o f p o n  x ° k ¨ n i d k –  e h j « f ª | ² ° | c i n m j k q j e g
v n i   n
r
| ¢ o j d d j q o j  k q l k q  q e j d
r
j d d n v p h f m x
   _ 

a  ]


F 
I D C @ W 1 > 2 @ X / D I 3 > 8 @ 8 B 3 W X  D
&
@
S
9 > 3 W X @ 8 B
 D  @ 2 3 > 1 D  5 8 @
S
9 0 @ 2 2 5 0 1 8 6 > 1 2 2 3 B > 3 ? 1 ; > 0 3
@ 2 2 1 0 @ 6 9 1 8 9 8 Q  R > 1 0 3 ? ? 1 > ? D  

  
 
                 
     !



 
!





!





X R @ Z 3 ?
F " F # F H G
X
G
N N
O
D


G 
I D J D C @ W 1 > 2 @ X / D I 3 > 8 @ 8 B 3 W X  D
&
@
S
9 > 3 W X @ 8 B
 D  @ 2 3 > 1 D  C @ 0 7 3 $ @ > 8 @ 8 %
L
I 3 6 0 7 R 1 2 9 0 5
6 1 9 8 0 > 3 @ ? 3 Q  3 & 0 9 3 8 0 5 D  

     
 '
 
!
  



       ( )
!

 ! *
  (
 


!
 +
    !

 X  R > 9 2
G
N N
O
D


M 
I D J D C @ W 1 > 2 @ X 4 D  D $ D , 8 9
-
8 3 8 ' ; > Z X
&
D Q @ 3 2 2 @ > 9 1 ; X / D I 3 > 8 . 8 B 3 W X  D
&
@
S /
> 3 W X
@ 8 B  D  @ 2 3 > 1 D I 3 @ ? 9 ' 9 2 9 6 5 1 V 0 1 Q V 1 > Q  D
% 8
 
 ' 

 X R @ Z 3 ? 1
M
1
#
1
O
N X
G
N N
O
D


O 
 D / 2
L
 1 ; > ? 5 @ 8 B  D  2 ' 1 8 3 ? 9 D I > 1 8 6
L
3 8 B
R 1 2 9 0 9 3 ? V 1 > 9
S
R > 1 = 3 B 9 ? ? ; 3 3 & 0 9 3 8 0 5 9 8 Q 
R > 1 0 3 ? ? 1 > ? D  

   2    



 


3 !
+ 




 
 

 
 
 





!





X
I 3 ' D
G
N N
M
D


1

4 D J D I 2 3
S
9 8 Z @ 8 B J D J D $ @ 2 2 @ 0 3 D 4 1


8 1 6 6 1
2 9 3


9 6 7 ? 6 @ 6 9 ? 6 9 0 ? 6 7 3 0 1 > > 3 0 6


@ 5 6 1 ? ;
S
L
S
@ > 9 W 3 ' 3 8 0 7
S
@ > > 3 ? ; 2 6 ? D

 
 

  
X
G E 5 M 6 G F H # G G F
X
F E H 7
D


7 
4 D , 8 9
-
8 3 8 ' ; > Z X  D
&
@
S
9 > 3 W X J D 8 @ > > 9 ' @ X @ 8 B
 D  @ 2 3 > 1 D
P
> @ 8 0 7 0 2 @ ? ? 9 9 0 @ 6 9 1 8 V 1 > Q 
V 3 6 0 7 Z @ 6 9 8 Z D  

   :  ;
 <



  
!


  (  (  = 


!
 > 



!




 >   (

  !
 
!

X R @ Z 3 ?
O E #
1
7
X
G
N N
G
D


" 
C D 8 9
S
1 ; ? 9 8 X J D Q 3 ' 1 6 X  D  @ > 6 @ 8 9 @ 8 X @ 8 B
? D  > @ 0 7
L
3
S
@
S
D %
S
R > 1 = 9 8 Z
M
 Z 3 1
S
3
L
6 > 5 6 > @ 8 ? V 1 >
S
@ 6 9 1 8 ? 1 8 @ ? 9
S
; 2 6 @ 8 3 1 ; ?
S
; 2 6 9
L
6 7 > 3 @ B 3 B Q %   R > 1 0 3 ? ? 1 > D  

   @ A 
  



 







 

!
 +
X  @ 5
G
N N
F
D


H 
, D 8 ; 1 X  D I > @ 8 2 9 8 X Q D  ; 7 3 >
-
3 3 X @ 8 B
 D Q 3 W 8 3 0 D
P
1 1 ? 6 9 8 Z Q  R 3 > V 1 >
S
@ 8 0 3 ' 5
? R 3 0 ; 2 @ 6 9 1 8 0 1 8 6 > 1 2 D  

     

 
'

!
  



       ( )
!

 ! *
  (
 


!
 +
    !

 X  R > D
G
N N
M
D


E 
, D 8 ; 1 X J D K ;
S S
@ > @
-
; X @ 8 B  D I > @ 8 9 2 8 D
P
@ 2 @ 8 0 9 8 Z 6 7 > 1 ; Z 7 R ; 6 @ 8 B V @ 9 > 8 3 ? ? 9 8 Q 
R > 1 0 3 ? ? 1 > ? D % 8  

  (
!
 +

  
!
 

 
'

!
  
   !







 
 

    
 '
!

 


  (

 B 


X R @
Z 3 ?
F 7 O # F " F
X
? 1 = D
G
N N
F
D


F
N

 D  D ? 3
S
9 > 1 = ? 5 X I D
P
> 3


3 > X @ 8 B
&
D C D
$ 1 1 B D  9 ? 0 B 5 8 @
S
9 0 9 8 ? 6 > ; 0 6 9 1 8 ? 6 > 3 @
S
0 1
S
R ; 6 3 > D % 8
   C D E F G
 

  (
!
 +

  
E F       
!
 

 
!
  
   !


 
! '






!





X R @ Z 3 ?
F 7 M # F " F
X
F E E F
D


F F  H
D Q @ W 3 9 B 3 ? @ 8 B D J ; @ 8 D 4 1


6 1 0 1
S
R @ > 3
6 7 3 R 3 > V 1 >
S
@ 8 0 3 1 V 6


1 Q 
S
9 0 > 1 @ > 0 7 9 6 3 0
L
6 ; > 3 ? D % 8
  

 
!
  
    !





 '

 
 

    
 !

 


  (

 B 


X
R @ Z 3 ?
F " F # F " E
X ? 1 = D
G
N N
F
D


F G 
 D Q 8 @ = 3 2 5 @ 8 B  D  D ; 2 2 ? 3 8 D Q 5
S
' 9 1 6 9 0
-
1 '
L
? 0 7 3 B ; 2 9 8 Z V 1 > @ ? 9
S
; 2 6 @ 8 3 1 ; ?
S
; 2 6 9 6 7 > 3 @ B 3 B
R > 1 0 3 ? ? 1 > D % 8

  I
D
 '
 J G
 

  (
!
 +

  

!
 
!
 

 
!
  

  

 



 



!


'


  
  

  
+


  !
 +    +   +    (




!
 +


 X R @ Z 3 ?
G M O # G O O
X
G
N N N D


F M 
 D  D ; 2 2 ? 3 8 @ 8 B J D  D
P
> 1


8 D 4 @ 8 B 2 9 8 Z
2 1 8 Z
L
2 @ 6 3 8 0 5 2 1 @ B ? 9 8 @ ? 9
S
; 2 6 @ 8 3 1 ; ?
S
; 2 6 9
L
6 7 > 3 @ B 9 8 Z R > 1 0 3 ? ? 1 > D % 8
   C D

F G
  '

  (
!
 +

  

F               
!

'


 
!
  
   !


 
!





!





X
R @ Z 3 ?
M F H # M G "
X
G
N N
F
D


F O 
 D  D ; 2 2 ? 3 8 X Q D J D / Z Z 3 > ? X J D Q D /
S
3 > X 4 D  D
8 3 = 5 X J D 8 D 8 1 X @ 8 B
&
D 8 D Q 6 @
S S
D / K R 2 1 9 6
L
9 8 Z 0 7 1 9 0 3 9 8 ? 6 > ; 0 6 9 1 8 V 3 6 0 7 @ 8 B 9 ? ? ; 3 1 8
@ 8 9
S
R 2 3
S
3 8 6 @ ' 2 3 ? 9
S
; 2 6 @ 8 3 1 ; ?
S
; 2 6 9 6 7 > 3 @ B
L
9 8 Z R > 1 0 3 ? ? 1 > D % 8


  L 2 : G
 

  (
!
 +


  E


(      
!
 

 
!
  
   !




 
 





!





X R @ Z 3 ?
F E F # G
N
G
X
F E E 7
D


F
1

 D  D ; 2 2 ? 3 8 X Q D J D / Z Z 3 > ? X @ 8 B 4 D  D
8 3 = 5 D Q 9
S
; 2 6 @ 8 3 1 ; ?
S
; 2 6 9 6 7 > 3 @ B 9 8 Z
S
@ K
L
9
S
9 W 9 8 Z 1 8
L
0 7 9 R R @ > @ 2 2 3 2 9 ?
S
D % 8


  L 2 A G
 

  (
!
 +

   E E  (      
!
 

 
!
  
   !


 
 
 





!





X R @ Z 3 ?
M E G # O
N
M
X
F E E
1 D


F 7 
$ D
H
@
S
@
S
1 6 1 X  D J D Q 3 > > @ 8 1 X  D
&
D @ 2
L
0 1 6 6 X
&
D C D $ 1 1 B X @ 8 B  D ? 3
S
9 > 1 = ? 5 D 4 3 >
L
V 1 >
S
@ 8 0 3 3 ? 6 9
S
@ 6 9 1 8 1 V
S
; 2 6 9 ? 6 > 3 @
S
3 B X ? ;
L
R 3 > ? 0 @ 2 @ > R > 1 0 3 ? ? 1 > ? D % 8 M
B  
 ' 
 N   
3
 B 
! !
  

 
!
   

  

 




 



!
 


X R @ Z 3 ?
F E
1
# G
N
O
X J @ 8 D
F E E O
D
74 Arquitectura del Procesador y Multiprocesadores
$UTXLWHFWXUD&OXVWHUL]DGD$VLPpWULFD%DVDGDHQHO&RQWHQLGR
5XEpQ*RQ]iOH]$GULiQ&ULVWDO
0LTXHO3HULFiV\0DWHR9DOHUR

'HSDUWDPHQWRGHDUTXLWHFWXUDGH
&RPSXWDGRUHV
83&8QLYHUVLWDW3ROLWqFQLFDGH&DWDOXQ\D
%DUFHORQD
^JRQ]DOH]DGULDQPSHULFDVPDWHR`#DFXSFHGX
$OH[9HLGHQEDXP

8QLYHUVLGDGGH,UYLQH
&DOLIRUQLD

DOH[Y#LFVXFLHGX


5HVXPHQ

(VWHDUWtFXORSURSRQHXQDQXHYDRUJDQL]DFLyQGH
SURFHVDGRUHV FOXVWHUL]DGRV EDVDGRV HQ HO
FRQWHQLGRGHORVYDORUHVHQWHURV
(VWDQXHYDIRUPDGHGHILQLUORVSURFHVDGRUHV
GDUi OXJDU D XQ FRQMXQWR GH YHQWDMDV HQ OR
UHIHUHQWH D OD HVFDODELOLGDG HILFLHQFLD GH
HMHFXFLyQ UHGXFFLRQHV GH SRWHQFLD \
SRWHQFLDOPHQWHYHORFLGDGHVGHOUHORMPiVDOWDV
/DV GLILFXOWDGHV HQ OD DVLJQDFLyQ GHO FOXVWHU
VWHHULQJVRQVDOYDGDVVDWLVIDFWRULDPHQWHSRUHVWD
SURSXHVWDGHFOXVWHUGLVPLQX\HQGRHOLPSDFWRGH
ODODWHQFLDGHFRPXQLFDFLyQHQWUHFOXVWHUV
/D $UTXLWHFWXUD &OXVWHUL]DGD $VLPpWULFD
%DVDGD HQ HO &RQWHQLGR $&$%& SURSXHVWR
FRQVLVWHHQODXWLOL]DFLyQGHGRVWLSRVGLIHUHQWHVGH
FOXVWHUV GH HMHFXFLyQ GH HQWHURV \ XQ QXHYR
DOJRULWPRGHDVLJQDFLyQGHFOXVWHU8QWLSREDVDGR
HQXQFOXVWHUHVWiQGDUGHELWV\RWURHVWUHFKR
EDVDGRHQELWV%DQFRGHUHJLVWURV
(O DOJRULWPR GH DVLJQDFLyQ GH FOXVWHU
VWHHULQJ HVWi IXQGDPHQWDGR HQ XQ SUHGLFWRU
EDVDGR HQ HO OD KLVWRULD SUHYLD GH OD HMHFXFLyQ
GHPRVWUDQGR WDVDV GH DFLHUWR HQ OD SUHGLFFLyQ
VXSHULRUHV DO  (VWH DOJRULWPR SURSXHVWR QR
VyOR HV XQ PRGHOR VLPSOH \ HILFLHQWH GH
DVLJQDFLyQ GH FOXVWHU VLQR TXH WLHQH OD JUDQ
KDELOLGDG GH SRGHU WRPDU GLFKD GHFLVLyQ HQ OD
HWDSD GH )HWFK GHO SURFHVDGRU SHUPLWLHQGR OD
DVLJQDFLyQFLFORVDQWHVTXHODVYDULDQWHVHVWiQGDU
SUHVHQWDGDV
3RU RWUR ODGR VH FRQVLJXH XQ PRGHOR GH
HMHFXFLyQ GH OD QXHYD DUTXLWHFWXUD TXH OOHJD D
FRQVHJXLU HILFLHQFLDV VXSHULRUHV D ODV GH OD
DUTXLWHFWXUD QR FOXVWHUL]DGD \ VXSHULRUHV D ORV
PRGHORVHVWiQGDUGHFOXVWHUH[LVWHQWHV
/DEDVHGHOPRGHORGHFOXVWHUHVODDVLJQDFLyQ
GH OD PD\RU SDUWH GH LQVWUXFFLRQHV GH IRUPD
DVLPpWULFDDXQFOXVWHUDQJRVWR


 ,QWURGXFFLyQ
/D HVFDODELOLGDG GH HILFLHQFLD GH ORV PRGHUQRV
SURFHVDGRUHV IXHUD GH RUGHQ HVWi VLHQGR GLItFLO
GHELGR DO FRQWLQXR DXPHQWR GH OD IUHFXHQFLD GH
UHORM\DODQFKRGHHPLVLyQGHOQ~PHURVLPXOWiQHR
GHLQVWUXFFLRQHV
(QORVDUWtFXORV>@>@SXHGHYHUVHFRPROD
OyJLFDGH³ZDNHXSVHOHFFLyQ´MXQWRFRQODOyJLFD
GHE\SDVV\HOEDQFRGHUHJLVWURVFRQVWLWX\HQXQD
GH ODV SDUWHV PiV FRPSOHMDV GH GLVHxDU \D TXH
WLHQHQXQJUDQLPSDFWRVREUHODHILFLHQFLDILQDOGH
ORVSURFHVDGRUHV(VWDVSDUWHVGHOSURFHVDGRUVRQ
ODV SDUWHV TXH FRQWUDYLHQHQ OD PHMRUD GH ORV
UHORMHV\DTXHLQFUHPHQWDUODODWHQFLDQ~PHURGH
FLFORVGHHVWDVVHWUDGXFHHQXQJUDQGHVFHQVRHQ
ODHILFLHQFLD
3RU RWUR ODGR HO DXPHQWR GHO Q~PHUR GH
LQVWUXFFLRQHV TXH SXHGH HPLWLU FDGD FLFOR DO
SURFHVDGRUSURYRFDXQFUHFLPLHQWRGUiVWLFRHQODV
PHQFLRQDGDVHVWUXFWXUDVTXHVHWUDGXFHGHQXHYR
HQ WLHPSRV GH FLFOR PiV HOHYDGRV R HQ ODWHQFLDV
PD\RUHV JHQHUDQGR DO ILQDO WDPELpQ XQ IXHUWH
LPSDFWRVREUHODHILFLHQFLDGHOSURFHVDGRU
/DSURSXHVWDGHODVDUTXLWHFWXUDVFOXVWHUL]DGDV
TXHPLWLJDQHQSDUWHHOLPSDFWRGHORVSUREOHPDV
DQWHULRUPHQWH H[SXHVWDV QR HV UHFLHQWH &RPR
SULPHU HMHPSOR GH LPSOHPHQWDFLyQ FRQ p[LWR GH
HVWHWLSRGHDUTXLWHFWXUD WHQHPRVOD$UTXLWHFWXUD
$OSKD  >@ (Q HVWD DUTXLWHFWXUD FDGD
FOXVWHU GLVSRQH GH OD FROD GH LQVWUXFFLRQHV OD
OyJLFDGHZDNHXSVHOHFFLyQHOEDQFRGHUHJLVWURV
H[FHSWXDQGRODLQWHUFRPXQLFDFLyQHQWUHFOXVWHUV
\ ODV 8QLGDGHV)XQFLRQDOHVOLPLWDGDVHQE\SDVV
WDQVyORDOSURSLRFOXVWHU6HGHGLFDQXQFDPLQR
GH FRPXQLFDFLyQ GH GDWRV HQWUH FOXVWHUV TXH
 

FRPXQLFDQ YDORUHV GH ORV UHJLVWURV HQWUH DPERV
(O EDQFR GH UHJLVWURV TXHGDQ FRSLDGR HQ DPERV
FOXVWHU FRQ OD GLIHUHQFLD TXH ODV HVFULWXUDV HQ HO
SURSLR FOXVWHU QR SDJDQ OD ODWHQFLD GH
LQWHUFRQH[LyQKD\UHWDUGRV\HVSHUDVHQHOFOXVWHU
TXHHVSHUDGDWRVGHRWURFOXVWHU
/D FRQVHFXHQFLD GH ODV DUTXLWHFWXUDV
FOXVWHUL]DGDVHVTXHVHFRQVLJXHPHMRUHOWLHPSR
GHFLFOR\DTXHOHVHVWUXFWXUDVVRQPiVSHTXHxDV
HQ FXHQWR D SXHUWRV HWF \ HO Q~PHUR GH
XQLGDGHV IXQFLRQDOHV SRU FOXVWHU WDPELpQ TXH
TXHGD GLYLGLGR HQ GRV SDUWHV 3RU RWUR ODGR OD
DUTXLWHFWXUD FOXVWHUL]DGD SDGHFH GH UHWDUGRV TXH
DQWHV QR WHQtD TXH DFDEDUiQ LPSDFWDQGR
QHJDWLYDPHQWH VREUH HO ,3& Q~PHUR GH
LQVWUXFFLRQHVTXHHMHFXWDHOSURFHVDGRUSRUFLFOR
(OFyPSXWRILQDOVREUHODHILFLHQFLDVHUiIDYRUDEOH
SDUD OD DUTXLWHFWXUD FOXVWHUL]DGD \D TXH JDQDUi
PiVHQODUHGXFFLyQGHOWLHPSRGHFLFORTXHHQOD
SpUGLGDGH,3&
+DVWDHOPRPHQWRODVSURSXHVWDVGHHVWHWLSR
GH DUTXLWHFWXUDV VH EDVDQ HQ PHMRUDV HQ OD
HILFLHQFLD PHMRUDV HQ ODV FRPXQLFDFLRQHV GH
GDWRVHQWUHFOXVWHUVPHMRUDVHQORVDOJRULWPRVGH
DVLJQDFLyQHWF
(VWH DUWtFXOR SURSRQH XQD QXHYD DUTXLWHFWXUD
EDVDGD HQ OD LGHD GH FOXVWHU DVLPpWULFR HQ HO
VHQWLGR GH TXH FDGD FOXVWHU HMHFXWDUi XQ WLSR GH
LQVWUXFFLRQHV GH WDO PDQHUD TXH GLFKRV FOXVWHU
FRPRVHYHUiVHUiQGLIHUHQWHVHQWpUPLQRVGHiUHD
\SRWHQFLDFRQVXPLGD/DEDVHGHODDVLPHWUtDVHUi
HOFRQWHQLGRGHORVYDORUHVORTXHGDUiHOQRPEUH
ILQDODOD$UTXLWHFWXUD&OXVWHUL]DGD%DVDGDHQHO
&RQWHQLGR
 0RWLYDFLyQ
(VHVWXGLRGHODVLQVWUXFFLRQHV\ORVYDORUHVGHVXV
RSHUDQGRVQRHVDOJRQRYHGRVR(Q>@>@>@>@
VHHVWXGLDODORQJLWXGGHORVGLIHUHQWHVRSHUDQGRV
XWLOL]iQGRVH EiVLFDPHQWH PpWRGRV HVWiWLFRV
PiVFDUDVHVWiWLFDV'HVWDFDXQHVWXGLR>@HQHO
FXDO VH SURGXFH XQD FDSWXUD RSHUDQGRV GH
GLIHUHQWHV ORQJLWXGHV HVWD YH] SDUWLHQGR GH XQD
YDULDQWHGLQiPLFDEDVDGDHQFRQVHJXLUUHGXFLUORV
YDORUHVEDVDGRVHQGLUHFFLRQHVGHPHPRULD
3DUWLHQGR GHO HVWXGLR GH ORV YDORUHV GH ORV
RSHUDQGRV>@HQHOTXHORVYDORUHVVRQEDVHGH
WUHV ORQJLWXGHV YDORUHV EDVDGRV HQ GLUHFFLRQHV
YDORUHVSHTXHxRV\YDORUHVODUJRVVHOOHJDDGRV
WLSRVGHRSHUDQGRVEDVDGRVHQODORQJLWXGYDORUHV
HVWUHFKRV\YDORUHVDQFKRV'LFKDORQJLWXGGHORV
RSHUDQGRV SXHGH VHU YDULDGD HQ IXQFLyQ GH OD
FRQILJXUDFLyQTXHVHGHVHHTXHGDQGRGHILQLGRHO
WpUPLQR G FRPR HO Q~PHUR GH ELWV GH ORV
RSHUDQGRVHVWUHFKRV
6LVHGHILQHQWLSRVGHLQVWUXFFLRQHVEDVDGRVHQ
VXV RSHUDQGRV SRGHPRV OOHJDU D OD FRPELQDFLyQ
VLJXLHQWH
 ,QVWUXFFLRQHV DQJRVWDV QDUURZ
LQVWUXFWLRQV FRPR DTXHOODV HQ OD TXH
WRGRVORVRSHUDQGRVIXHQWH\HORSHUDQGR
GHVWLQRVRQGHWLSRHVWUHFKR
 ,QVWUXFFLRQHVODUJDVQRUPDOHV(OUHVWR
GHLQVWUXFFLRQHVTXHVHUHDOL]DUiQFRQ
ELWV

/DILJXUDHVWXGLDHOUDWLRGHLQVWUXFFLRQHVGHWLSR
DQJRVWRHQIUHQWHDODVGHWLSRQRUPDOODUJRHQ
IXQFLyQGHOSDUiPHWURGELWV
LQVWUXFFLRQHV FRUWDV  LQVWUXFFLRQHV FRUWDV
LQVWUXFFLRQHVODUJDV

0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
4 8 12 16 20 24
FP
INT
SPEC2k

)LJXUD 
&RPR SXHGH REVHUYDUVH HQ OD ILJXUD  VH
SURGXFH XQ FRPSRUWDPLHQWR TXDVLOLQHDO HQ
IXQFLyQ GHO Q~PHUR GH ELWV DQJRVWRV (Q HO FXDO
WHQGUHPRV SRU HMHPSOR TXH SDUD HO FRQMXQWR GH
DSOLFDFLRQHVGHO63(&NFRQRSHUDFLRQHVGHG 
ELWV VHUtDPRV FDSDFHV GH UHDOL]DU DOJR PiV GHO
 GH ODV LQVWUXFFLRQHV HQWHUDV FRQ  ELWV
PLHQWUDVTXHSDUDG ELWVHVWDUtDPRVFHUFDQRV
DO
 'HILQLFLyQGHODDUTXLWHFWXUD
(QHVWDVHFFLyQVHGHILQH\GHWDOODFRPSOHWDPHQWH
OD DUTXLWHFWXUD SDUWLHQGR LQLFLDOPHQWH GH XQ
SURFHVDGRU HVWiQGDUIXHUD GH RUGHQ SDVDQGR SRU
XQD DUTXLWHFWXUD VLPpWULFD QR FOXVWHUL]DGD SDUD
OOHJDUDOILQDODODDUTXLWHFWXUDSURSXHVWD
76 Arquitectura del Procesador y Multiprocesadores


 $UTXLWHFWXUD%DVHQR&OXVWHUL]DGD
/D DUTXLWHFWXUD EDVH QR FOXVWHUL]DGD VHUi XQD
PiTXLQDEDVDGDHQXQSURFHVDGRUIXHUDGHRUGHQ
GH  HWDSDV HQ HO SLSHOLQH \ GH FXDWUR
LQVWUXFFLRQHV GH HPLVLyQ SRU FLFOR 6H GDUi XQ
PD\RUGHWDOOHGHHVWHHQODVHFFLyQGHHYDOXDFLyQ
 $UTXLWHFWXUD&OXVWHUL]DGD%iVLFD
VLPpWULFD
/D $UTXLWHFWXUD %DVH GHO &OXVWHU 6LPpWULFR
PRVWUDGD HQ OD )LJXUD  VHUi OD DUTXLWHFWXUD
FOXVWHUL]DGD TXH VHUYLUi FRPR EDVH GH
FRPSDUDFLyQ FRQ GLYHUVRV PRGHORV HVWiQGDU GH
FOXVWHUVLPpWULFR

)LJXUD $UTXLWHFWXUD&OXVWHUL]DGD6LPpWULFD

(VWDVHEDVDHQODDUTXLWHFWXUDFOiVLFDGHO$OSKD
 EDVDGD HQ XQ SLSHOLQH GH  HWDSDV XQD
PiV TXH OD QR FOXVWHUL]DGD GHELGR D OD HWDSD GH
DVLJQDFLyQ GH FOXVWHU VWHHULQJ GH HPLVLyQ GH
FXDWUR LQVWUXFFLRQHV SRU FLFOR FRQ UpSOLFD GHO
EDQFRGHUHJLVWURV
+HPRVXWLOL]DGRHVWHPRGHOR\DTXHHVHOPRGHOR
PiV XWLOL]DGR SDUD OD FRPSDUDFLyQ HQWUH
DUTXLWHFWXUDVFOXVWHUL]DGDV
 $UTXLWHFWXUD&OXVWHUL]DGD$VLPpWULFD
%DVDGDHQHO&RQWHQLGR$&$%&
/DLGHDEiVLFDGHHVWHFOXVWHUHVWHQHUGRVFOXVWHUV
TXHHMHFXWHQGRVWLSRVGHLQVWUXFFLRQHVGLIHUHQWHV
HOTXHHMHFXWDODV,QVWUXFFLRQHV1DUURZ\HOTXH
HMHFXWDVODVLQVWUXFFLRQHV1RUPDOHV$OSULPHUROR
GHQRPLQDUHPRV &OXVWHU 5iSLGR \ DO VHJXQGR
&OXVWHU/HQWR
(Q OD ILJXUD  VH PXHVWUD XQ HVTXHPD
UHVXPLGRGHODQXHYDDUTXLWHFWXUD


)LJXUD $UTXLWHFWXUD&OXVWHUL]DGD$VLPpWULFD
/DV GLIHUHQFLDV LPSRUWDQWHV VREUH OD DUTXLWHFWXUD
EDVHVRQ
• /D GLYLVLyQ GHO EDQFR GH UHJLVWURV HQ WUHV
HVWUXFWXUDV GLIHUHQWHV GHULYDGDV GHO WLSR GH
UHJLVWUR>@
(O%DQFR/DUJR/RQJFRQYDORUHVGH
ELWVVyORSUHVHQWHHQHO&OXVWHU*UDQGH
(O%DQFRGH9DORUHV3HTXHxRV6,03/(
GHGELWVFRQXQDFRSLDSUHVHQWHHQORVGRV
FOXVWHUV
(O%DQFRGHYDORUHVEDVDGRVHQ'LUHFFLyQ
6+257$FFHVLEOHSRUORVGRVFOXVWHUV
• 3UHGLFWRU GH WLSR GH ,QVWUXFFLyQ SDUD OD
DVLJQDFLyQ GH FOXVWHU PLUDU OD VXEVHFFLyQ

• /D DSDULFLyQ GH XQ PHFDQLVPR GH UHHPLVLyQ
GH LQVWUXFFLRQHV HMHFXWDGDV HQ HO FOXVWHU
LQFRUUHFWRPLUDUODVXEVHFFLyQ
• /DHMHFXFLyQUiSLGDDGREOHYHORFLGDGGHODV
LQVWUXFFLRQHV HQ HO &OXVWHU 5iSLGR D GREOH
YHORFLGDG
 $OJRULWPRGHDVLJQDFLyQGHFOXVWHU
3UHGLFWRUGHWLSRGHLQVWUXFFLyQ
/DEDVHGHODOJRULWPRGHDVLJQDFLyQGHFOXVWHUHV
XQ SUHGLFWRU GH XQ ELW EDVDGR HQ OD KLVWRULD
LQPHGLDWD OD ~OWLPD YH] TXH VH HMHFXWy OD
LQVWUXFFLyQGHPDSHR GLUHFWR\VLQXVRGH7$*
SDUDDFFHGHUDpO
'XUDQWH OD HWDSD GH )HWFK GHO SURFHVDGRU VH
SURFHGH D OHHU HO SUHGLFWRU SDUD VDEHU HQ TXH
FOXVWHUYDDHMHFXWDUODLQVWUXFFLyQ
6HGLVSRQHDVtGHPXFKRVPiVFLFORVTXHHOUHVWR
GHSURSXHVWDVGHVWHHULQJTXHGHEHQHVSHUDUDOD
HWDSDGHGHFRGLILFDFLyQ\TXHSRUORWDQWRGHEHQ
SDJDUXQFLFORH[WUDHQHOSLSHOLQHSDUDDVLJQDUHO
FOXVWHU FRVD TXH PDQWHQHPRV HQ QXHVWUD
SURSXHVWD
XVI Jornadas de Paralelismo, JP '2005 77
 

 )DOORHQODSUHGLFFLyQGHOWLSRGH
LQVWUXFFLyQ
/DQRUPDOHMHFXFLyQGHODVLQVWUXFFLRQHVGHSHQGH
GLUHFWDPHQWHGHOSUHGLFWRUTXHTXHGDFRQILUPDGR
WUDVODHMHFXFLyQGHODLQVWUXFFLyQ
(O SUREOHPD VXUJH FXDQGR OD SUHGLFFLyQ GHO
WLSR GH LQVWUXFFLyQ HV HUUyQHD (Q HO FDVR GH
KDEHUVH HTXLYRFDGR HQ XQD LQVWUXFFLyQ TXH VH
SUHGLMR FRPR ODUJD GH  ELWV \ TXH DFDED
UHVXOWDQGRVHUGHPHQRVELWVQRSURGXFLUiQLQJXQD
SHQDOL]DFLyQ \D TXHVHSRGUiWHUPLQDU OD QRUPDO
HMHFXFLyQGHHVWDHQXQLGDGHVGHELWVDSHVDUGH
VHUGHELWV&XDQGRHOSUREOHPDVHSURGXFHDOD
LQYHUVD WHQGUHPRV TXH HQYLDU D HMHFXWDU OD
LQVWUXFFLyQ GH  ELWV PDO SUHGLFKD GHO FOXVWHU
UiSLGRDOFOXVWHUOHQWRORTXHVHWUDGXFLUiHQXQD
SHQDOL]DFLyQ WHPSRUDO \ SRU OR WDQWR HQ XQD
SpUGLGDGHHILFLHQFLD
 2SWLPL]DFLyQHQOD7/%
(O %DQFR GH 5HJLVWURV GH 'LUHFFLRQHV TXH HV HO
HQFDUJDGR GH LQWHQWDU FDSWDU ODV GLUHFFLRQHV
IUHFXHQWHV GH XQ SURJUDPD >@ SXHGH VHU YLVWR
FRPRXQD7/%GHWUDGXFFLyQ&DGDYH]TXHVHXVH
XQD HQWUDGD GHO %DQFR GH 'LUHFFLRQHV VH SXHGH
HVWDEOHFHU XQ PpWRGR GH WUDGXFFLyQ GLUHFWD
DPSOLDQGR HVWH EDQFR SDUD FRQWHQHU FLHUWD
LQIRUPDFLyQGHOD7/%
'HHVWDIRUPDVHSURGXFHXQDOLEHUDFLyQHQOD
QHFHVLGDGGHOHHUOD7/%WUDGLFLRQDOFDGDYH]TXH
WHQJDPRV XQ RSHUDQGR HQ HO DFFHVR D PHPRULD
TXH WHQJD YDORUHV TXH XWLOLFHQ XQD HQWUDGD GHO
%DQFRGH'LUHFFLRQHV

 (YDOXDFLyQ
 &DUDFWHUtVWLFDVGHOD$UTXLWHFWXUD
&OXVWHUL]DGD$VLPpWULFD
,VVXH)HWFK&RPPLWZLGWK LQVWUXFWLRQVF\FOH
%UDQFKSUHGLFWRU &RPELQLQJ.HQWULHV
,/VL]H .%ZD\F\FOH
'/VL]H .%ZD\5G:USRUWVF\FOH
/VL]H 0%ZD\F\FOHODWHQF\
0HPRU\ODWHQF\ F\FOHV
0HPRU\EXVZLGWK E\WHV
&OXVWHUV ,QWHJHUIORDWLQJSRLQW
,QWHJHU)XQFWLRQDO8QLWVODW SHUFOXVWHUODWHQF\
)3)XQFWLRQDO8QLWVODW ODWHQF\
3K\VLFDOUHJLVWHUV ,QWSHUFOXVWHU5G:USRUWV
)ORDWLQJ3RLQW
5HRUGHU%XIIHU 
/RDG6WRUH4XHXH 
,QWHJHU4XHXHV LQHDFKFOXVWHU
)34XHXH 

7DEOD&RQILJXUDFLyQ&OXVWHU$VLPpWULFR
/RV SURJUDPDV XWLOL]DGRV SDUD OD HYDOXDFLyQ
GH OD HILFLHQFLD XWLOL]DGRV VRQ WRGRV ORV 63(&
%HQFKPDUN6XLWH)XHURQFRPSLODGRVSDUDHO
,6$ GH $OSKD < VLPXODGRV VREUH XQ VLPXODGRU
EDVDGR HQ 6LPSOHVFDODU DOWDPHQWH PRGLILFDGR
HMHFXWDQGR  PLOORQHV GH LQVWUXFFLRQHV
UHSUHVHQWDWLYDV>@
 (YDOXDFLyQGHODILDELOLGDGGHOSUHGLFWRUGH
WLSRGHLQVWUXFFLyQ
(OSUHGLFWRU GHOWLSR GH LQVWUXFFLyQ VHUi HVHQFLDO
SDUD OD DUTXLWHFWXUD \D TXH HV OD EDVH GHO
DOJRULWPRGHDVLJQDFLyQ
/D VLJXLHQWH ILJXUD PXHVWUD ILDELOLGDG GHO
SUHGLFWRU HQ IXQFLyQ GHO WDPDxR HQ Q~PHUR GH
HQWUDGDVGHODWDEODGHHVWH


93%
94%
95%
96%
97%
98%
99%
1 2 4 8 16 32 64

)LJXUD )LDELOLGDGGHO3UHGLFWRUGH7LSRGH
,QVWUXFFLyQHQPLOHVGHHQWUDGDV
78 Arquitectura del Procesador y Multiprocesadores


(QpVWD)LJXUDVHDSUHFLDTXHODILDELOLGDGHV
PX\ DOWD FRQ SRFDV HQWUDGDV 'HEH WHQHUVH HQ
FXHQWD TXH WDQ VyOR VH SDJDUiQ FRQ FLFORV GH
SHQDOL]DFLyQ DTXHOODV LQVWUXFFLRQHV TXH VH
SUHGLMHURQ TXH SXHGHQ HMHFXWDUVH FRQ  ELWV \
UHVXOWD TXH VRQ GH  ELWV \D TXH QR SRGUiQ
HMHFXWDUVH HQ HVH FOXVWHU \ WHQGUiQ TXH VHU
HQYLDGDVDORWURFOXVWHU
 (YDOXDFLyQGHODWpFQLFDGH$VLJQDFLyQGH
&OXVWHU6WHHULQJ
$TXtVHHYDO~DQXQDVHULHGHPRGHORVSUHYLRVGH
VWHHULQJ FRQRFLGRV FRQWUD QXHVWUD SURSXHVWD GH
&OXVWHU DOJRULWPR 02' Q >@>@ $OSKD 
XVDHO02'),567B),7>@\HO'(3*5$3+
>@ HO PHMRU DOJRULWPR GHO JpQHUR SHUR HO PiV
FRPSOHMR
1XHVWUR PRGHOR GH FOXVWHU HQ HVWD HWDSD HV
VLPpWULFR \D TXH VyOR VH WHVWHD HO DOJRULWPR GH
DVLJQDFLyQ SRU OR WDQWR QR KDEUi SRVLEOHV
SHQDOL]DFLRQHVGHSRUIDOORVGHSUHGLFFLyQGHOWLSR
GHLQVWUXFFLyQQLHMHFXFLyQDGREOHYHORFLGDGQL
WDPSRFRUHGXFFLRQHVSRU7/%
(QOD)LJXUDSXHGHYHUVHODFRPSDUDFLyQGH
,3&6 UHODWLYRV DO PRGHOR EDVH QR FOLVWHUL]DGR
 HQ IXQFLyQ GHO Q~PHUR GH FLFORV GH
LQWHUFRPXQLFDFLyQHQWUHFOXVWHUV/DFRPSDUDFLyQ
GH ODV SURSXHVWDV DQWHULRUHV H[SXHVWDV MXQWR FRQ
$&$%& FRQ G  ELWV &$$&B PHMRU
EDODQFHDGRGHLQVWUXFFLRQHVHQWUHFOXVWHU\DTXH
HVWDPRVDQWHXQFOXVWHUVLPpWULFR

70%
75%
80%
85%
90%
95%
100%
0 1 4 16
caac_8 depgraph firstfit mod1 mod3

)LJXUD &RPSDUDFLyQGHO0RGHORGH$VLJQDFLyQ
GH&OXVWHU

&yPRSXHGHYHUVHHOPRGHORGHDVLJQDFLyQGH
$&$%&VHXWLOL]DFRQ
1XHVWUD DUTXLWHFWXUD VH FRPSRUWD EDVWDQWH ELHQ
LQFOXVRDODWHQFLDVHQWUHFOXVWHUVHOHYDGDV
 (YDOXDFLyQGHORVGLIHUHQWHVPRGHORV
(QHVWDVXEVHFFLyQVHHYDO~DODHILFLHQFLDGHODV
GLIHUHQWHV YHUVLRQHV GHO $&$%& &$$& R
&RQWHQW$ZDUH$V\PPHWULF&OXVWHU
 ) 0RGHOR GH &$$& VLQ GREOH
YHORFLGDG
 ;B)  0RGHOR GH &$$& FRQ XQD
XQLGDG GH GREOH YHORFLGDG &OXVWHU
5iSLGR
 ;B) 0RGHOR GH &$$& FRQ GRV
XQLGDGHV GH GREOH YHORFLGDG &OXVWHU
5iSLGR
 '(3*5 0RGHORGHODPHMRUSURSXHVWD
GHFRPSDUDFLyQ
 7/%B)0RGHOR GH &$$& FRQ XQD
XQLGDG GH GREOH YHORFLGDG \
RSWLPL]DFLyQGH7/%
 7/%B)0RGHOR GH &$$& FRQ GRV
XQLGDGHV GH GREOH YHORFLGDG \
RSWLPL]DFLyQGH7/%

(VWDYHUVLyQGHDUTXLWHFWXUD\DVLTXHSRVHHUi
XQDGLVWDQFLDGHFRPXQLFDFLyQHQWUHFOXVWHUVGH
FLFORV\GHSHQDOL]DFLyQGHIDOORGHSUHGLFFLyQGH
WLSRGHLQVWUXFFLyQGHGRVWLSRV
/D ILJXUD VLJXLHQWH PXHVWUD OD FRPSDUDFLyQ
GHO ORV ,3& UHODWLYRV DO PRGHOR EDVH QR
FOXVWHUL]DGRGHODVGLIHUHQWHVYDULDQWHVGHQXHVWUR
PRGHOR FRPSDUDGR FRQ HO PHMRU PRGHOR
FRPSDUDGR'(3*5$3+

90%
92%
94%
96%
98%
100%
102%
104%
106%
108%
2F 2X_1F 2X_2F DEPGR TLB_1F TLB_2F
FP
INT
SPEC2k

)LJXUD &RPSDUDFLyQ0RGHORV$&$&%'(3*5

'HORVPRGHORVH[SXHVWRVWDQVyORHOSULPHUR
TXHQRWLHQHQLQJXQDRSWLPL]DFLyQUHDOL]DGD\HV
XVI Jornadas de Paralelismo, JP '2005 79
 

HVWH HO~QLFR TXH SLHUGH ,3&UHVSHFWRDO PRGHOR
'(3*5 (O UHVWR GH PRGHORV QR VyOR HVWiQ SRU
HQFLPD GH HVWH VLQR TXH HVWi SRU HQFLPD GH OD
DUTXLWHFWXUDQRFOXVWHUL]DGD
 (YDOXDFLyQGHORVDFFHVRVDOD7/%
(QHVWDVXEVHFFLyQVHHYDOXDUiODHILFLHQFLDGHOD
QXHYDSURSXHVWDDODKRUDGHHOLPLQDUDFFHVRVDOD
7/% QHFHVLWDQGR VyOR DFFHGHU DO %DQFR GH
'LUHFFLRQHV6KRUW
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
FP INT 2K
LOADS NO TLB(%)
STORES NO TLB(%)

)LJXUD $FFHVRVTXHQRUHTXLHUHQ7/%
 3RWHQFLD\ÈUHD
&XDOLWDWLYDPHQWHVHSXHGHDSUHFLDUTXHHO&OXVWHU
5iSLGRTXHWDQWRODV8QLGDGHV)XQFLRQDOHVFRQVX
OyJLFDGHE\SDVVFRPRHQHO%DQFRGH5HJLVWURV
VRQ GH  ELWV IUHQWH D ORV  ELWV GHO &OXVWHU
/HQWR(VRQRVLQGXFHDSHQVDUHQTXHHO&OXVWHU
5iSLGRHVXQ&OXVWHUFRQXQFRQVXPR \XQiUHD
VXEVWDQFLDOPHQWHPHQRUTXHHO&OXVWHU/HQWR
3DUDSRGHUDUHDOL]DUXQDYHUVLyQFXDQWLWDWLYD
VHUtD QHFHVDULR GLVHxDU HO SURFHVDGRU D QLYHO
HOHFWUyQLFR FRVD TXH VDOH GHO DOFDQFH GH HVWH
DUWtFXOR
 7UDEDMRVUHODFLRQDGRV
'LYLGLUHPRVORVWUDEDMRVUHDOL]DGRVHQGRVJUXSRV
EiVLFRV ODV RSWLPL]DFLRQHV EDVDGDV HQ GDWRV \
DUTXLWHFWXUDVFOXVWHUL]DGDV
(Q ODV RSWLPL]DFLRQHV HQ GDWRV HQFRQWUDPRV
ORV HVWXGLRV GH %URRNV HW DO >@ D FHUFD GHO
WDPDxR GH ORV RSHUDQGRV HQ DUTXLWHFWXUDV GH 
ELWV (QFRQWUDURQ TXH PiV GHO  GH ORV
RSHUDQGRVVHSXHGHQHMHFXWDUFRQELWVGDQGR
FRPR UHVXOWDGR UHGXFFLRQHV GH SRWHQFLD HQWUH HO
 \ HO  HQ OD XQLGDG IXQFLRQDO (VWRV
UHVXOWDGRV IXHURQ EDVDGR HQ 1DJHQGUD HW DO>@
TXH HVWXGLDURQ HO LPSDFWR GH ORV RSHUDQGRV
HVWUHFKRVHQiUHDWLHPSR\SRWHQFLD
/RK>@SURSXVRXQD DUTXLWHFWXUD0XOWL%LW
:LGWK TXH LQWHQWDED SUHGHFLU FRQ SUHFLVLyQ HO
WDPDxRGHORVRSHUDQGRV(OREMHWLYRHUDHMHFXWDU
YDULDVLQVWUXFFLRQHVGHPHQRVELWVHQODVXQLGDGHV
FRQ PD\RU  GH  ELWV IRPHQWDQGR DVt PD\RU
SDUDOHOLVPR
8Q WUDEDMR TXH GHVWDFD HV XQR UHDOL]DGR SRU
*XSWDHWDO>@HQHOFXDOVHPRVWUDEDTXHFRQXQ
SHTXHxR JUXSR GH YDORUHV HUD UHSHWLGR FRQ
IUHFXHQFLDSURORVSURJUDPDV/DLGHDDPSOLDGDGH
HVWH WUDEDMR GHVGH YDORUHV IUHFXHQWHV KDVWD
³YDORUHVSUy[LPRVDIUHFXHQWH@GDOXJDUDO>@
/D LGHD GH ODV XQLGDGHV \ VFKHGXOHU
SODQLILFDGRUGHGREOHYHORFLGDGKDVLGRXWLOL]DGD
\DXQDYH]FRQp[LWRHQHO3HQWLXP,9>@SHUR
VLQODLGHDGHFOXVWHUGHWUiV
'HORVWUDEDMRVUHODFLRQDGRVFRQDUTXLWHFWXUDV
FOXVWHUL]DGDVGHVWDFDHOHVWXGLRGH3DODFKDUOD>@
VREUHODFRPSOHMLGDG \UHWDUGRGHODV HVWUXFWXUDV
EDVDGRV HQ ODV WHFQRORJtDV IXWXUDV (Q HVWH VH
LGHQWLILFDQ ODV SDUWHV SULQFLSDOHV GHO SURFHVDGRU
TXHWHQGUiQPiVSUREOHPDV\WHQGUiQPiVLPSDFWR
VREUHODHILFLHQFLDILQDOGHODPiTXLQD
+RURZLW] HW DO >@ GHPXHVWUDQ OD
LPSRUWDQFLD GHO FRVWH GH FRPXQLFDFLyQ GH ODV
HVWUXFWXUDV FUtWLFDV DO VHU SDUWLFLRQDGDV HQ ORV
SURFHVDGRUHVSUHVHQWHV\IXWXURV
$JJDUZDO HW DO >@ HVWXGLDURQ HO LPSDFWR GH
IUHFXHQFLDVGHUHORMDOWDVHQHO,3&\DTXHFLHUWDV
HVWUXFWXUDV FUtWLFDV YHUiQ DXPHQWDGDV HQ OD
IUHFXHQFLD
)DUNDV HW DO>@SURSXVLHURQ XQD DUTXLWHFWXUD
FOXVWHUL]DGD GLYLGLHQGR ODV XQLGDGHV IXQFLRQDOHV
UHJLVWURV \ ODV YHQWDQDV GH LQVWUXFFLRQHV HQ GRV
FOXVWHUV XWLOL]DEDQ SDUD HOOR XQ SODQLILFDGRU
HVWiWLFR GH LQVWUXFFLRQHV SDUD PDQWHQHU ODV
GHSHQGHQFLDV 5RWHQEHUJ HW DO >@ SURSXVLHURQ
ORV 7UDFH 3URFHVVRUV ORV FXDOHV GLYLGtDQ ODV
LQVWUXFFLRQHVGHSURJUDPDHQP~OWLSOHVHOHPHQWRV
GH SURFHVDPLHQWR 6RKL HW DO>@ SURSXVR ORV
3URFHVDGRUHV 0XOWLHVFDODUHV TXH GLYLGtDQ HO
SURJUDPD HQ SHTXHxDV WDUHDV JXLDGDV SRU
VRIWZDUH HMHFXWDQGR FDGD XQD GH HOODV HQ XQ
SHTXHxRFOXVWHU
%DQLDVDGL HW DO >@ HYDOXDURQ SURSXHVWDV GH
HVTXHPDVFOXVWHUL]DGRVHVWXGLDQGRHODOJRULWPRGH
DVLJQDFLyQGHFOXVWHU%DODVXEUDPRQLDQHWDO>@
HVWXGLDURQ HO LPSDFWR GH XQD DUTXLWHFWXUD
80 Arquitectura del Procesador y Multiprocesadores


FOXVWHUL]DGDGHKDVWDFOXVWHUVSURSRQLHQGRXQ
PHFDQLVPRGLQiPLFRGHGHVDFWLYDFLyQGHFOXVWHUV
3RU~OWLPRVHGHVWDFDHOWUDEDMRGH&DQDOHWDO
>@ HQ HO TXH VH HYDOXDURQ \ SURSXVLHURQ YDULRV
HVTXHPDVGHDVLJQDFLyQGHLQVWUXFFLRQHVDFOXVWHU
 &RQFOXVLyQ
(VWH DUWtFXOR LQWURGXFH OD LGHD GH FOXVWHU
DVLPpWULFR SUHVHQWDQGR XQ $UTXLWHFWXUD
&OXVWHUL]DGD%DVDGDHQHO&RQWHQLGRGHO9DORUGH
ORVRSHUDQGRV\GHODVRSHUDFLRQHV
8Q&OXVWHU5iSLGREDVDGRHQRSHUDFLRQHVGH
 ELWV TXH SXHGH IXQFLRQDU D GREOH YHORFLGDG
FRQ XQ FRQVXPR GH SRWHQFLD SRU LQVWUXFFLyQ
VXEVWDQFLDOPHQWHPHQRUDODYH]TXHVHFRQVLJXH
XQDKRUURHQHOiUHDODV8QLGDGHV)XQFLRQDOHVHO
%DQFRGH5HJLVWURV\ORVE\SDVHVWUDEDMDQFRQ
ELWV HQ OXJDU GH  \ XQ &OXVWHU /HQWR FRQ
RSHUDFLRQHV GH  ELWV HTXLYDOHQWH D XQ FOXVWHU
EDVDGRHQODDUTXLWHFWXUD$OSKD6REUHHO
SULPHU FOXVWHU VH VLW~D VREUH HO  GH OD
HMHFXFLyQGHODVLQVWUXFFLRQHVGHWDOIRUPDTXHVH
SURGXFHXQSUHYLVLEOHDKRUURHQHOFRQVXPRHQHO
SURFHVDGRU
/D HILFLHQFLD FRQVHJXLGD VHJ~Q OD
FRQILJXUDFLyQ VH VLW~D SRU HQFLPD LQFOXVR GH OD
DUTXLWHFWXUDQRFOXVWHUL]DGDFRPRODDUTXLWHFWXUD
FOXVWHUL]DGD TXH SRVHH HO PHMRU DOJRULWPR GH
VWHHULQJ
(ODOJRULWPR GHVWHHULQJSURSXHVWRHVVLPSOH
EDVDGRHQXQSUHGLFWRUGHOWLSRGHLQVWUXFFLyQGH
XQ ELW VREUH OD KLVWRULD PiV UHFLHQWH GH OD
HMHFXFLyQ GH OD LQVWUXFFLyQ UiSLGR \ SXHGH
UHDOL]DU YDULRV FLFORV DQWHV TXH HQ ODV GHPiV
SURSXHVWDVGHVWHHULQJORTXHSRGUtDGDUOXJDUD
HOLPLQDU HVWD HWDSD GH VWHHULQJ R DVLJQDFLyQ GH
FOXVWHU(OSUHGLFWRUGHPXHVWUDVHJ~QHOWDPDxRXQ
JUDGRGHILDELOLGDGHQWRUQRDO
3RU ~OWLPR VH SURSRQH HO JHQHUDU XQ
PHFDQLVPR TXH VXEVWLWX\H HO  GH DFFHVRV D
XQD7/%FOiVLFDDWUDYpVGHODFFHVRDO%DQFRGH
5HJLVWURV GH 'LUHFFLRQHV OR TXH VH WUDGXFLUi HQ
XQD UHGXFFLyQ GH OD ODWHQFLD GH PHPRULD TXH
SURYRFDUiXQLPSDFWRGHODOHQHO,3&ILQDO
D OD YH] TXH QRV DKRUUDUHPRV OD SRWHQFLD
FRQVXPLGD HQ HO DFFHVR DO  GH DFFHVRV D OD
7/%
5HIHUHQFLDV
>@ $$JJDUZDODQG0)UDQNOLQ³$QHPSLULFDO
VWXG\RIWKHVFDODELOLW\DVSHFWVRILQVWUXFWLRQ
GLVWULEXWLRQ DOJRULWKPV IRU FOXVWHUHG
SURFHVVRUV´,Q,63$661RY
>@ 6 %DODNULVKQDQ DQG * 6RKL ³([SORLWLQJ
YDOXH ORFDOLW\ LQ SK\VLFDO UHJLVWHU ILOHV´
5HVHDUFK UHSRUW 8QLYHUVLW\ RI :LVFRQVLQ

>@ 5 %DODVXEUDPRQLDQ 6 'ZDUNDGDV DQG '
$OERQHVL ³'\QDPLFDOO\ PDQDJLQJ WKH
FRPPXQLFDWLRQSDUDOOHOLVPWUDGHRIILQIXWXUH
FOXVWHUHG SURFHVVRUV´ ,Q WK ,6&$ -XQH

>@ $ %DQLDVDGL DQG $ 0RVKRYRV ³,QVWUXFWLRQ
GLVWULEXWLRQ KHXULVWLFV IRU TXDGFOXVWHU
G\QDPLFDOO\VFKHGXOHG VXSHUVFDODU
SURFHVVRUV´,QUG,QWHUQDWLRQDO6\PSRVLXP
RQ0LFURDUFKLWHFWXUH'HF
>@ ' %URRNV DQG 0 0DUWRQRVL ³'\QDPLFDOO\
H[SORLWLQJQDUURZZLGWKRSHUDQGVWRLPSURYH
SURFHVVRUSRZHUDQGSHUIRUPDQFH´,Q+3&$
SDJHV±
>@ ( %RUFK ( 7XQH 6 0DQQH DQG - (PHU 
³/RRVH/RRSV6LQN&KLSV´3URFHHGLQJVRIWKH
(LJKWK+3&$
>@ 5&DQDO$*RQ]iOH]DQG-(6PLWK³9HU\
ORZ HQHUJ\ SLSHOLQHV XVLQJ VLJQLILFDQFH
FRPSUHVVLRQ´,QUG0,&52
>@ 5 &DQDO -0 3DUFHULVD DQG $ *RQ]DOH]
³'\QDPLF FOXVWHU DVVLJQPHQW PHFKDQLVPV´
,Q3URFHHGLQJVRIWKH+3&$-DQ
>@ . )DUNDV 3 &KRZ 1 -RXSSL DQG =
9UDQHVLF ³7KH PXOWLFOXVWHU DUFKLWHFWXUH
5HGXFLQJF\FOHWLPHWKURXJKSDUWLWLRQLQJ´,Q
WK ,QWHUQDWLRQDO 6\PSRVLXP RQ
0LFURDUFKLWHFWXUH'HF
>@ 5 *RQ]iOH]  $ &ULVWDO ' 2UWHJD $
9HLGHQEDXP DQG 0 9DOHUR ³$ &RQWHQW
$ZDUH,QWHJHU5HJLVWHU)LOH2UJDQLVDWLRQ´,Q
WK,6&$-XQH
>@ *+LQWRQ'6DJHU08SWRQ'%RJJV'
&DUPHDQ$.\NHUDQG35RXVVHO3³7KH
0LFURDUFKLWHFWXUHRIWKH3HQWLXP3URFHVVRU´
,QWHO7HFKQRORJ\-RXUQDO4
>@ 0+RURZLW]5+RDQG.0DL³7KHIXWXUH
RI ZLUHV´ ,Q 6HPLQFRQGXFWRU 5HVHDUFK
&RUSRUDWLRQ :RUNVKRS RQ ,QWHUFRQQHFWV IRU
6\VWHPVRQD&KLS0D\
XVI Jornadas de Paralelismo, JP '2005 81
 

>@ 5 .HVVOHU ³7KH DOSKD 
PLFURSURFHVVRU´,Q,(((0LFUR0DUFK$SULO

>@ 1DJHQGUD0,UZLQDQG52ZHQV³$UHD
WLPHSRZHUWUDGHRIIVLQSDUDOOHODGGHUV´,(((
7UDQV&LUF6\VW
>@ 63DODFKDUOD13-RXSSLDQG-(6PLWK
³&RPSOH[LW\ HIIHFWLYH VXSHUVFDODU
SURFHVVRUV´,QWK,6&$-XQH
>@ (5RWHQEHUJ4-DFREVRQ<6D]HLGHVDQG
-6PLWK³7UDFHSURFHVVRUV´,QWK0,&52
'HF
>@ * 6RKL 6 %UHDFK DQG 7 9LMD\NXPDU
³0XOWLVFDODU SURFHVVRUV´,Q QG $QQXDO
,QWHUQDWLRQDO 6\PSRVLXP RQ &RPSXWHU
$UFKLWHFWXUH-XQH
>@ / 9LOOD 0 =KDQJ DQG . $VDQRYLü
³'\QDPLF]HURFRPSUHVVLRQIRUFDFKHHQHUJ\
UHGXFWLRQ´,QUG0,&52
>@ <=KDQJ-<DQJDQG5*XSWD³)UHTXHQW
YDOXH ORFDOLW\ DQG YDOXH FHQWULF GDWD FDFKH
GHVLJQ´,Q3URFHHGLQJVRI WKHWK$63/26
SDJHV$&03UHVV
>@ *+/RK³([SORLWLQJ'DWD:LGWK/RFDOLW\
WR ,QFUHDVH 6XSHUVFDODU ([HFXWLRQ
%DQGZLGWK´ ,Q 3URFHHGLQJV WK ,QWO
6\PSRVLXPRQ0LFURDUFKLWHFWXUH3DJHV
±
>@ 7 6KHUZRRG ( 3HUHOPDQ DQG % &DOGHU
³%DVLF EORFN GLVWULEXWLRQ DQDO\VLV WR ILQG
SHULRGLF EHKDYLRU DQG VLPXODWLRQ SRLQWV LQ
DSSOLFDWLRQV´ ,Q 3URFHHGLQJV RI WKH ,QWO
&RQIHUHQFH RQ 3DUDOOHO $UFKLWHFWXUHV DQG
&RPSLODWLRQ 7HFKQLTXHV SDJHV ± 6HSW

82 Arquitectura del Procesador y Multiprocesadores
KIMP: Multicheckpointing Multiprocessors
Enrique Vallejo1
, Marco Galluzzi2
, Adrián Cristal2
, Fernando Vallejo1
, Ramón
Beivide1
, Per Stenström3
, James E. Smith4
and Mateo Valero2
1
Grupo de Arquitectura de Computadores, Universidad de Cantabria
2
Departament d’Arquitectura de Computadors, Universitat Politècnica de Catalunya
3
Dept. of Computer Science and Engineering, Chalmers University of Technology
4
Dept. of Electrical and Computer Engineering, University of Wisconsin-Madison
Abstract
Multiprocessors are coming into wide-spread use
in many application areas, yet there are a number
of challenges to achieving a good tradeoff
between complexity and performance. For
example, while implementing memory coherence
and consistency is essential for correctness,
efficient implementation of critical sections and
synchronization points is desirable for
performance.1
The multi-checkpointing mechanisms of Kilo-
Instruction Processors can be leveraged to achieve
good complexity-effective multiprocessor designs.
We describe how to implement a Kilo-Instruction
Multiprocessor that transparently, i.e. without any
software support, uses transaction-based memory
updates. Our model not only simplifies memory
coherence and consistency hardware, but at the
same time, it provides the potential for
implementing high performance speculative
mechanisms for commonly occurring
synchronization constructs.
1. Introduction
Multiprocessors are rapidly becoming the
standard for computing platforms, including
1
This work has been supported by the Ministry of
Education of Spain under contracts TIN-2004-07739-
C02-01 and TIN-2004-07440-C02-01, grants AP2003-
0539 (M. Galluzzi) and AP-2004-6907 (E. Vallejo), the
HiPEAC European Network of Excellence, and the
Barcelona Supercomputing Center. J. E. Smith is partly
supported by the NSF grant CCR-0311361. Per
Stenström is partly supported by the Swedish Research
Council under contract VR 2003-2576.
simple single-board and even single-chip systems.
Many of these designs implement shared memory
multiprocessors because it provides a clear
programming model where sharing code and data
structures is simplified. However, there are
several aspects that complicate the design and
programming of a shared memory system and
limit its performance:
x The interconnection hardware, which
provides quick access to data held in memory
or in remote caches.
x The coherence protocol, which manages the
correct sharing of memory values among
private caches.
x The consistency model, which manages the
correct ordering of memory operations to
different memory locations.
x The need for data sharing can generate access
conflicts, which are solved with exclusion
mechanisms.
x Finally, synchronization operations which
ensure that different program threads can
cooperate with each other.
A way to solve the above-mentioned problems
is to employ transactional memory systems.
These systems implement memory operations as
transactions that are guaranteed to be atomic, and
which simplify the design or improve the
performance of a multiprocessor system. Much
work has been done on this field and we list some
important recent work:
x Transactional Lock Removal (TLR) [15]
detects critical sections, and dynamically
substitutes them with transactions, eliding the
lock acquisition. Transactions are used as a
substitute for critical sections, to augment
parallelism when no conflict occurs.
x Thread-level Transactional Memory (TTM)
[13] is a software-hardware approach that
covers different levels of the system. It
implements transactional support at thread
level, so that the programmer specifies the
transactions, with support in lower levels of
the operating system and hardware.
x Transactional Coherence and Consistency
(TCC) [9] proposes a new shared memory
model where atomic transactions are the basic
unit for communication, simplifying both
parallel applications and coherence and
consistency hardware. As TTM, this proposal
also modifies the programming model, forcing
the programmer to divide the program into
transactions.
In prior work, the memory latency problem
has been shown to be significantly reduced by
Kilo-Instruction Processors [1][2][3][4]. These
processors can hide the memory latency by
supporting thousands of in-flight instructions.
Later, in [5] a new multiprocessor composed of
Kilo-Instruction Processors is introduced, called
Kilo-Instruction Multiprocessor.
In this paper, we describe a correct
implementation of a Kilo-Instruction
Multiprocessor, which will henceforth be referred
as KIMP, which takes advantage of the
underlying uniprocessor mechanisms to simplify
the design and to improve performance. KIMP
leverages the multiple checkpointing mechanism
of the Kilo-Instruction Processors 1) to perform
memory updates in a transactional manner, and 2)
to apply speculation mechanisms to execute
through critical sections and synchronization
points in a straightforward manner.
Performing memory updates in KIMP as if
they are transactions leads to implicit
transactions; i.e., they are orchestrated in
hardware, without any software support and are
transparent to the programmer. Consequently, the
proposed KIMP comprises all the advantages of a
transactional memory system, including the
implementation of sequential consistency, in a
natural and efficient manner. On the other hand,
having the ability to speculate through critical
sections and synchronization points can improve
system performance when such constructs are
conservatively coded. Hence, the KIMP design is
a high-quality complexity-effective option for
future multiprocessor systems.
2. Background
2.1. Kilo-Instruction Processors
Kilo-Instruction Processors [1] hide large
latencies, specifically due to memory accesses,
because the processor allows thousands of
instructions to be in-flight at the same time.
However, in order to increase the number of in-
flight instructions we must increase the capacities
of several resources, the most important ones
being the re-order buffer, the instruction queues,
the load/store queues and the physical registers.
Unfortunately, simply up-sizing these structures,
is not feasible. In order to overcome these
difficulties, Kilo-instruction processors employ a
number of different techniques, to arrive at an
overall implementation. Such an approach is
possible because critical resources are
underutilized in present out-of-order processors
[2]. The main technique consists of multi-
checkpointing long latency instructions instead of
having a large ROB [1].
Multi-checkpointing. At specific instructions
during program execution, generally branches and
long latency instructions like loads that miss in the
L2 cache, a checkpoint is taken. The checkpoint is
a snapshot of the processor state. If an exception
or branch misprediction occurs the state is rolled
back to the closest checkpoint prior to the
excepting instruction.
As the execution advances, in-flight
instructions corresponding to the different
checkpoints are executed. When these
speculatively executed instructions finish, they
remain in the processor queues if they are memory
operations, otherwise are flushed from the
processor. Only when all the instructions
corresponding to the oldest checkpoint are
finished, the processor commits the checkpoint
atomically, consequently removing memory
operations from the load or store queue and
committing all the results speculatively calculated.
Then, with this action, the speculative instructions
become globally performed. Figure 1 shows an
example of the multiple checkpointing
mechanism, where oldest instructions are to the
left. Black instructions are finished, but their
results are not committed. In case a), instructions
from three consecutive checkpoints are in flight.
In case b), the second checkpoint is finished, as all
84 Arquitectura del Procesador y Multiprocesadores
the instructions within it are finished, but it can
not commit as it is not the oldest checkpoint in the
pipeline. In case c), the first checkpoint (the oldest
one) finishes, so it and the second checkpoint can
commit, making the third checkpoint to be the
new oldest checkpoint.
2.2. Kilo-Instruction Multiprocessors
A Kilo-Instruction Multiprocessor under a
NUMA configuration [5] has been shown to
effectively hide large latencies coming from both
local and remote memory accesses, including
latencies due to the interconnection network.
Figure 2 shows the reduction in the execution time
for different benchmarks from the Splash2 suite,
when using 1024 in-flight instructions as
compared with 64; the memory access time is 500
cycles. However, in [5] only an evaluation of the
performance achieved by the system is done,
leaving out any kind of architectural detail.
Describing the system architecture in more detail
is one of the goals of this paper.
3. KIMP overview
The KIMP design is based on a small-scale
SMP interconnected via a snoopy bus. Our
proposal takes advantage of the multiple
checkpointing, so the cost of implementing a
KIMP can be very low.
Figure 3 shows an example of the execution
flow for four processors. Different processors
execute different portions of code, taking different
checkpoints as the execution advances, and being
able to roll back execution to a certain checkpoint
in case of an exception, branch misprediction or
memory consistency violation as showed below.
All the in-flight instructions remain
speculative until their corresponding checkpoint
commits. This means that memory instructions
remain in the processor queues and do not modify
the local cache or the global memory, and they are
subject to a rollback. In Figure 3, for example, P3
can commit checkpoint Chk31, when all the
instructions up to Chk32 have been completed. In
the KIMP system, this commit is followed by the
atomic broadcast of all the cache tags that the
processor has modified during the checkpoint
execution, these are, the pending memory updates.
By “atomic” we mean that after the processor gets
access to the bus it does not release the bus until
all the tags have been broadcast.
Remote processors snoop the memory updates
searching for a conflict with the loads they have in
their load queues, which are speculatively
executed and are not already committed. In case
of a conflict, the remote processor is forced to roll
back, because it has speculatively used data that,
P3
Chk34
Chk33
Chk32
Chk31
st a
P1
Chk11
Chk12
Chk13
Chk14
P4
ld a
Chk44
Chk43
Chk42
Chk41
P2
Chk24
Chk23
Chk22
Chk21
ld a
Executed Instruction
Checkpoint
In-flight Instruction
Chk34
Figure 3. Execution flow for 4 processors.
0
10
20
30
40
50
60
70
80
90
100
FFT Ocean Radix Water-nsq Water-sp
Splash 2 benchmark
percentage
Figure 2. Performance of Kilo-Instruction Multiproc.
a)
b)
c)
In-flight instruction Executed instruction
Figure 1. Multiple checkpoints.
XVI Jornadas de Paralelismo, JP '2005 85
at this point, is discovered to be “previously”
modified. Thus, as long as conflicts are not found,
speculatively executed instructions are not
discarded. Finally, if no rollback happens, the
speculatively executed instructions are globally
performed when the checkpoint commits. In the
example from Figure 3, the broadcasting of a store
to a given memory location “a” conflicts with two
other processors that have already speculatively
loaded from location “a”, but the loads have not
been already committed. In this example, P2 is
rolled back to Chk23 and P4 to Chk42, forcing its
newest instructions to be discarded.
Furthermore, multi-checkpointing yields
improved performance if simple hardware
modifications are made to support the concurrent
execution of critical sections and speculative
execution beyond synchronization points. These
improvements are described in section 6.
3.1. Implicit transactions
In the KIMP system, we define a transaction
as the atomic execution of the instructions
included between a committing checkpoint and
the next one. We say the proposed system
executes implicit transactions. They are implicit
because they are automatically hardware
delimited, by means of the checkpointing
mechanism, and the programmer does not need to
know that the system provides such transactional
behavior. Therefore, the ISA does not need any
change, and current binaries can be directly
executed. Note that this idea differs from the
concept of transactions in previous works [9][13]
where transactions are considered as programming
constructs that normally need a hardware support.
The transactional behavior is provided by the
speculative execution (which provides isolation
between different transactions) and the atomic in-
order validation (providing consistency and
atomicity), together with the described conflict
detection mechanism. The system does not care
about conflicts that can exist during the execution
of transactions because they are not revealed (not
released to the memory hierarchy) until one
transaction commits, this is, they are isolated.
Therefore, KIMP provides a correctness
substrate, constituted of speculative execution,
atomic validation, and the rollback mechanism,
which ensures that code is executed correctly.
3.2. Adaptive transaction length
We propose that transaction lengths should be
adaptive, decreasing in case of frequent rollbacks
and increasing as long as no rollbacks occur. In
case of frequent consistency violations, the length
of the transactions decreases, also decreasing the
number of violations and the number of
instructions that are discarded in case of a
rollback. This is valid as the correctness substrate
ensures correct work independently of the
instruction where a checkpoint is taken.
4. Memory coherence
In KIMP, a snoopy bus based multiprocessor,
the overall coherence protocol is simplified. Lines
are not maintained in “shared” or “exclusive”
state, as dictated by MESI-like cache coherence
protocols. Our broadcast-based approach works as
either a snoopy write invalidate or write update
protocol as follows.
Basic Operation. During a transaction, the cache
is not modified by local stores, only speculative
loads are performed. Once a transaction commits,
the pending stores are atomically performed and
the broadcast mechanism transmits the changes to
the rest of processors, updating or invalidating the
remote cache lines. This way, when the stores
from a transaction need to be broadcast, the
corresponding processor will get control of the
bus and release it only when all its memory
updates are globally performed. This operation
prevents other processor from broadcasting
memory updates simultaneously and protects the
memory system from coherence and consistency
problems.
Finally, if there is an update or invalidation of
a cache line, the corresponding remote processor
will update or invalidate those cache lines
matching a snooped address, and the execution
will roll back to the previous checkpoint.
Broadcast Information. The contents of the
broadcast message will determine the snoopy
type: if the packet contains the written data, the
protocol will behave as write update. Else, if the
packet only contains the updated cache line
addresses, remote processors will invalidate those
lines, and the protocol will work as write
invalidate.
86 Arquitectura del Procesador y Multiprocesadores
5. Memory consistency
5.1. Consistency models
The memory consistency model of a shared-
memory multiprocessor determines how the
system can overlap or reorder memory operations.
Different models offer a trade-off between
programming simplicity and performance:
x Sequential Consistency (SC) [10], the most
restrictive model, guarantees that interleaved
memory operations from different processors
appear to execute in program order, at the cost
of a generally lower performance.
x On the other hand, less restrictive models,
such as Release Consistency (RC) [6] provide
a higher performance, at the cost of not
ensuring strict ordering of operations.
x Other consistency models provide
intermediate performance and restrictions,
such as Processor Consistency [7].
Sequential Consistency is the most desirable
model, as it is the simplest model to understand
and it provides the most intuitive programming
interface. A basic implementation of SC requires a
processor to delay each memory access until the
previous one is completed, what is simple but
clearly leads to a low performance. However,
recent proposals preserve SC without
compromising performance. Some of these are:
x SC++ [8] makes use of hardware speculation
for both load and store operations, and
preserves SC by rolling back when a
consistency violation is found. This way the
system can rely on reordering and overlapping
memory operations for performance similar to
that achieved with the RC model.
x TCC [9] proposes a parallel model based on
software-delimited transactions, with a
sequential ordering between them.
5.2. KIMP maintains SC
We can extend the definition of sequential
consistency to transactions, and require only
transactions from each processor to be in order.
The resulting global order will be an arbitrarily
interleaved succession of transactions that will
also meet the basic definition of SC since it
corresponds with one of the possible sequentially
consistent global orderings. We show an example
in Figure 4; the third column shows that
respecting the program order for transactions will
also respects program order for memory
operations.
Furthermore, the KIMP environment allows
the execution of memory operations out-of-order.
This does not compromise the correctness of the
SC model because:
1. All the memory operations are executed
speculatively, the stores are delayed until the
transaction can commit.
2. All the speculative loads that match the address
of a previous pending store receive the correct
value thanks to the usual store-forwarding
mechanism.
3. The snooping of memory updates from the bus
ensures that the values speculatively loaded are
valid unless an address match is found, which
would produce a rollback of the transaction.
4. Finally, the memory updates from the
transaction are atomically broadcast only when
the transaction commits, making the pending
stores globally performed at this moment.
Thus the result of a transaction is the same,
independently of the instructions execution order.
6. Locks and barriers
Lock structures control the access to critical
sections by allowing only one process, the lock
owner, to enter and to read and modify shared
variables. A typical critical section, using load-
linked and store-conditional instructions, is shown
in Figure 5.
TR
B2
TR
B1
TR
A2
TR
A1
Process A
A1
A2
A3
Process B
B1
B2
B3
Global order
process A,B
A4
A5
A6
B4
B5
TR
A2
TR
A1
A1
A2
A3
A4
A5
A6
TR
B1
B1
B2
B3
TR
B2
B4
B5
Figure 4. Sequentially consistent reordering of
checkpoints from 2 processors.
XVI Jornadas de Paralelismo, JP '2005 87
Critical sections ensure exclusive access to the
lock owner, forcing any other threads desiring to
enter the critical section to stall until the lock is
released. Sometimes, this stall is unnecessary, as
some threads may not actually modify any data, or
they modify different fields of a shared data
structure. In these cases, parallel execution could
be allowed, avoiding the stall of threads waiting
for the lock.
The parallel execution of the critical section
eliminates the dependence of other threads on the
lock owner, which can sometimes generate very
long waits, for example if the lock owner is
suspended. The problem of critical sections is
even more important in these cases.
On the other hand, Flags and barriers are used
to synchronize different threads. A correct
execution should make all threads wait for the
barrier to open, before continuing execution.
Similar to the critical section case, this stall can be
avoided in those cases, in which there is no real
data interaction between different threads.
6.1. Related work
In [14][15] Rajwar and Goodman propose
SLE, a hardware approach that detects lock
constructions and avoids acquiring them, leaving
the critical section open and thus allowing several
instances of the same critical section to execute
concurrently. Correctness is preserved by
detecting data collisions. All the data used during
a speculative section is kept in the local cache,
and a remote request to write that address forces
the execution to roll back to the checkpoint. Thus,
if no collision is detected, several instances of the
critical section can be executed in parallel, and if a
collision happens, only one of them advances.
In [12] Martínez and Torrellas propose
Speculative Synchronization. It preserves one safe
thread, which actually acquires the lock, and
multiple speculative threads, that detect the busy
lock and execute speculatively. When the lock
owner releases it, the rest of the threads commit
their state or compete for ownership of the lock.
Relating barriers, when such a construct is
detected, execution is continued further, in a
speculative state. The instructions after a barrier
remain speculative, waiting for the barrier to open
before validating.
In [16] SLR, an improvement to the previous
ideas is proposed. All the speculative threads
execute their critical section, even though they
may have a conflict. An arbiter dictates the order
in which they commit, minimizing collisions.
In TCC [9] every access to shared data has to
fall in the same transaction as the computation and
the update of the data. Software locks are replaced
with special instructions that mark a transaction
change. This naturally allows the parallel
execution of critical sections, and detects conflicts
in case of data collision, without the need of using
control variables. Flags and barriers are
substituted with phase numbers assigned to each
transaction. This way, transactions with the same
phase numbers can commit in any order, whereas
transactions with consecutive phase numbers are
ensured to commit sequentially. Speculation is
implemented naturally, as transactions after the
phase change can be executed, but not committed.
6.2. KIMP and critical sections
The correctness substrate ensures valid
operation, including critical sections execution. In
this section, we study and propose some
improvements that allow KIMP to execute critical
sections in parallel, in those cases where there is
no real data collision. As the code from a critical
section is executed different checkpoints are
taken. In Figure 6, cases a) to c) show different
possible checkpointing schemes.
Basic KIMP behavior. When a processor reaches
the lock, it checks the value of the lock and
acquires it if it is free. This acquire operation
remains in speculative state in the processor
queues. If a new checkpoint is taken inside the
LOCK(t)
UNLOCK(t)
Critical
section
Execution
flow
Short
set of
instr.
L1:ldl t0, 0(t1)
bne t0, L1
ldl_l t0, 0(t1)
bne t0, L1
lda t0, 1(0)
stl_c t0, 0(t1)
beq t0, L1
stl 0 ,0(t1)
Figure 5. A typical critical section.
88 Arquitectura del Procesador y Multiprocesadores
critical section, as in Figure 6 a), the validation of
T1 will globally acquire the lock, forcing remote
processors inside the critical section to rollback,
due to the lock variable invalidation. After that,
remote processors will not enter the critical
section. The validation of T2 unlocks the section
and remote processors can start executing it. The
same invalidation happens if no checkpoint is
taken until unlocking the critical section, as the
lock variable is also written. This case is shown in
Figure 6 b), and it should be the most frequent
case, due to the short nature of critical sections.
Thus, the validation of a transaction that has
executed a critical section will cause any other
processor that is executing it to rollback, which
means that only a single valid processor stays
inside a critical section. These examples show that
basic KIMP ensures the correctness of code,
wherever checkpoints are taken.
Enhancing KIMP. If the lock variable is the only
interaction between different processors accessing
the same critical section, parallel execution is
feasible. In case b), the store of the lock variable
writes an “open” value in a memory position that
already contains that value, which constitutes a
silent store and unnecessarily forces remote
processors to rollback. We propose the use of two
mechanisms that allow KIMP to naturally
speculate through critical sections.
Firstly, a silent store detection and removal
mechanism, which detects that the value does not
globally modify memory, and removes that update
from the update packet. When applied to a lock
variable, the lock is removed from the update
packet and this would allow a checkpoint
configuration such as Figure 6 b) to be executed in
parallel, avoiding processor stalls.
Additionally, to make no checkpoint taken
within a critical section, we make use of a lock
and barriers detection mechanism, which
dynamically detects typical Test&Test&Set lock
constructs and lock release. This hardware forces
a new checkpoint to be taken just before the lock
acquire and after the release, so that the lock
remains open for the rest of the processors at the
beginning of the new transaction. This makes the
transaction length equal to the critical section, and
avoids unnecessary rollbacks. This example is
shown in Figure 6 c).
6.3. Silent stores and store merging
A silent store [11] is defined as a memory
write that does not change the system state. An
ordinary store merging mechanism reduces the
number of stores to the same address within a
transaction to only one, and silent store removal
avoids broadcasting the remaining stores.
Store merging consists of removing a store
when a younger store is to the same address. After
performing the store merging, we carry out the
silent store removal. To detect silent stores our
mechanism searches older loads before executing
a store, and, if an address and value match is
found, the store is removed. Figure 7 shows an
example of use of these mechanisms.
C
A B
Instruction
Checkpoint
Chk1
Chk1
Chk3
UNLOCK(t)
Chk2
LOCK(t)
Chk1
Chk2
UNLOCK(t)
LOCK(t)
Chk1
Chk2
UNLOCK(t)
LOCK(t)
T1
T2
Figure 6. Different checkpointing schemes.
LD A
Critical
section
Execution
flow
Chk1
ST #1, A
Chk2
ST #0, A
Merged:
ST #0, A
Silent Store
detected:
removed
Figure 7. Silent store elimination.
XVI Jornadas de Paralelismo, JP '2005 89
6.4. KIMP speculation past barriers
KIMP can be adapted to speculate after
barriers, in a similar manner to [12]. As in the
previous section, there is the need to detect the
barrier code and take a new checkpoint just prior
to it. Speculative execution starts after the barrier,
as shown in Figure 8. All the transactions after
this barrier remain fully speculative, meaning that
none of them can be validated, as long as the
barrier remains closed. This is ensured by setting a
“pure speculative mode” in the processor.
To determine the moment in which the barrier
opens, the processor tracks the cache line
containing the barrier variable, waiting for a cache
event (an invalidation or an update of the line) to
check the value again. When the barrier opens, the
“pure speculative mode” is disabled, and the
processor can start committing all the transactions
in the pipeline.
7. Conclusions
This paper introduces KIMP, a framework
that makes Kilo-instruction Processors capable of
executing parallel code in a transactional fashion,
similar to the TCC model, but modifying neither
the code nor the programming methodology. Our
model maintains Sequential Consistency with a
low hardware cost and a high performance
potential. The hardware requirements are low, as
most of the mechanisms are already proposed for
Kilo-Instruction Processors, and the processor
model is simplified thanks to the transactional
behavior.
Speculative execution in critical sections,
together with the advantages of transactional
behavior, will provide high performance with no
required code modifications.
References
[1] A. Cristal, M. Valero, J. Llosa, and A. González,
“Large virtual ROBs by processor checkpointing”,
TR. UPC-DAC-2002-39, UPC, Spain, July 2002.
[2] A. Cristal, J. F. Martínez, J. Llosa, and M. Valero,
“A Case for Resource-conscious Out-of-order
Processors”, In IEEE TCCA Comp. Architecture
Letters, 2, October 2003.
[3] A. Cristal, D. Ortega, J. Llosa, and M. Valero, “Out-
of-Order Commit Processors”, In Proc. of the 10th
HPCA, February 2004.
[4] A. Cristal et al., “Kilo-instruction Processors:
Overcoming the Memory Wall”, To be published on
IEEE Micro Magazine,Vol. 25, N. 3, May/June 05.
[5] M. Galluzzi et al., “A First Glance at Kilo-
Instruction based Multiprocessors”, In Proc. of the 1st
Conf. on Computing Frontiers, pp. 212-221, Ischia,
Italy, April 2004.
[6] K. Gharachorloo et al., “Memory Consistency and
Event Ordering in Scalable Shared-Memory
Multiprocessors”, In Proc. of the 17th
ISCA, 1990.
[7] J. R. Goodman, “Cache Consistency and Sequential
Consistency”, Tech.Rep. no.61, SCI Committee,
March 1989.
[8] C. Gniady, B. Falsafi, and T. N. Vijaykumar, “Is SC
+ ILP = RC?”, In Proc. of the 26th
ISCA, 1999
[9] L. Hammond et al., “Transactional Memory
Coherence and Consistency”, In Proc. of the 31st
ISCA, Germany, June 2004.
[10] L. Lamport, “How to make a Multiprocessor
Computer that Correctly Executes Multiprocess
Programs”, IEEE Transactions on Computers, C-
28(9):690-691, 1979.
[11] M. H. Lipasti, K. M. Lepak, “On the Value Locality
of Store Instructions”, In Proc. of 27th
ISCA, 2000.
[12] J. Martínez, J. Torrellas, “Speculative
Synchronization: Applying Thread-Level
Speculation to Explicitily Parallel Applications”, In
Proc. of the 10th
ASPLOS, Oct. 02.
[13] K. E. Moore, M. D. Hill and D. A. Wood, “Thread-
Level Transactional Memory”, TR1524, Comp.
Science Dept. UW Madison, March 31, 2005.
[14] R. Rajwar, and J. R. Goodman, “Speculative Lock
Elision: Enabling Highly-Concurrent Multithreaded
Execution”, In Proc. of 34th Intl. Symp. on
Microarchitecture, pp.294-305, Dec. 2001.
[15] R. Rajwar, and J. R. Goodman, “Transactional
Lock-Free Execution of Lock-Based Programs”, In
Proc. of the 10th
ASPLOS, Oct. 02.
[16] P. Rundberg, and P. Stenström, “Speculative Lock
Reordering”, In Proc. of IPDPS, April 2003.
BARRIER(t)
Speculative
execution
Chk1
Chk2
Normal
execution
Figure 8. A speculated barrier.
90 Arquitectura del Procesador y Multiprocesadores
   
                  !   $   $           $
 
  ,  
/   
0
  $  / 
    
    
0

0

   

0
/   $          6   
8 : < = > @ B D B F G H J K M = : N P 8 Q J Q S B T V B F X H P Z J > Q ^ J
_ ` a c e g c h ` i g l m ` n i p ` i r ` e t c w x ` y i l z l p t c m ` { l h a | g c m l e ` ~
 c y | z g c m m ` n i ƒ l e h … g r y c
‡ i r ˆ ` e ~ r m c m m ` ‰ | e y r c
Š ‹ ‹ Œ 
‰ | e y r c
Ž
c  e l ~  h ` c y c y r l  ‘ h p c e y r c ’ “ m r g ` y  | h  ` ~
” – — ˜ ™ – š
› œ  Ÿ   ¡  ¢ £ ¤  ¥ ¡   ¦ ¨ ¢ ¦ ª ¢ « ¦ £  ¤ ­ ¨ œ ­   ¢ Ÿ  
¡ ¨ ¢ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨ ¢ ± ± ³ ´ › µ ·   ¢ ¯ °   ¡ ¨ ± ¨ œ ­ « ³
Ÿ ¨ Ÿ Ÿ   ¦   ¦  ¤ « ¨ œ   ±   ¢ ¨ ¤ « ¨ £ ¨ ¤ ¨ ¦ ¨ œ ­   œ   ¤ ¡ ¨
±  ¼   ¤   œ ± « ¨ Ÿ   ¡  ¢ ¥ ¡  ¯ °   ¢   œ ± ¨ ± ¼   À « œ Á  ¤ ¦ ¨ ³
± « à œ Ÿ   Ÿ « ¤   ± ­  ¤ «  Å £ °   Ÿ   ¡ ¡   Æ ¨ ¤ ¨ ¢   ¤   Ç ±   ¢ « È ¨ É
Ê
¡  ¯ °     ¢ £    ¤ É ¨ ° ¦   œ ­ ¨ ¤ ¡ « œ   ¨ ¡ ¦   œ ­   ±  œ
  ¡ œ Ë ¦   ¤  Ÿ   £ ¤  ±   ¢ ¨ Ÿ  ¤   ¢ Ÿ   ¡ ¢ « ¢ ­   ¦ ¨ Ì Í   ³
¢ ¨ Á  ¤ ­ ° œ ¨ Ÿ ¨ ¦   œ ­   É ¡ ¨ ¢ ¢  ¡ ° ± «  œ   ¢ ¨ ± ­ ° ¨ ¡   ¢ ¤   ³
Ÿ ° ±   œ   ¡ ­ ¨ ¦ ¨ Î  Ÿ     ¢ ­ ¨ ¦   ¦  ¤ « ¨ ¨ ± ¨ ¦ ¥ «  Ÿ  
Ÿ   Æ ¤ ¨ Ÿ ¨ ¤   ¡ ¤   œ Ÿ « ¦ «   œ ­  Ì Ï ¢ ­   ¨ ¤ ­ Ð ± ° ¡  £ ¤   ¢   œ ³
­ ¨   ¡ Ñ Ò Ó Ô Õ Ö × Ó Ò × Ø Ò Ù Ô Ó × É ° œ œ °   È    œ Á  ¯ °   ¨ ¡ ¨
¼  ¤ ¨ Ÿ    ¤ Æ ¨ œ « Ú ¨ ¤ ¡ ¨ « œ Á  ¤ ¦ ¨ ± « à œ Ÿ   Ÿ « ¤   ± ­  ³
¤ «  ¯ °   ¤   Ÿ ° ±   ±  œ ¢ « Ÿ   ¤ ¨ ¥ ¡   ¦   œ ­   ¡ ¨ ¢  ¥ ¤   ± ¨ ¤ ³
Æ ¨ Ÿ   ¦   ¦  ¤ « ¨
Ê
¦   Û  ¤ ¨   ¡ ¤   œ Ÿ « ¦ «   œ ­    œ ¡  ¢
¢ « ¢ ­   ¦ ¨ ¢ ± ± ³ ´ › µ · Ì Ï ¢ ­ ¨ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨   ¡ « ¦ « œ ¨
±  ¦ £ ¡   ­ ¨ ¦   œ ­   ¡ ¨   ¢ ­ ¤ ° ± ­ ° ¤ ¨ Ÿ   Ÿ « ¤   ± ­  ¤ «  Ÿ  
¡ ¨ ¦   ¦  ¤ « ¨ £ ¤ « œ ± « £ ¨ ¡ Ì · ¼  ¤ ¨ ¡ ¨ « œ Á  ¤ ¦ ¨ ± « à œ Ÿ  
Ÿ « ¤   ± ­  ¤ «  ¤   ¢ « Ÿ     œ ± ¨ ± ¼   É ¯ °   £  ¢     ¦ ° ± ¼ ¨ ¢
¦   œ  ¢   œ ­ ¤ ¨ Ÿ ¨ ¢ ¯ °   ¡ ¨ ¦   ¦  ¤ « ¨ £ ¤ « œ ± « £ ¨ ¡ É ±  œ
¡  ¯ °   ¢   ¡  Æ ¤ ¨ ° œ ¨ ±  œ ¢ « Ÿ   ¤ ¨ ¥ ¡   ¤   Ÿ ° ± ± « à œ   œ
­ ¨ ¦ ¨ Î  É ¨ Ÿ   ¦ ª ¢ Ÿ   ° œ ¨ ± ±   ¢  ¦ ª ¢ ¤ ª £ « Ÿ  ¨
Ÿ « ± ¼ ¨ « œ Á  ¤ ¦ ¨ ± « à œ Ÿ   Ÿ « ¤   ± ­  ¤ «  Ì
ß à â
š ã ä å æ ˜ ç è é š ë ™ å ã è ì í ç è é š
Ï œ ¡ ¨ ¨ ± ­ ° ¨ ¡ « Ÿ ¨ Ÿ É ¡ ¨ ¦   Û  ¤  £ ± « à œ £ ¨ ¤ ¨ Ÿ « ³
¢   Î ¨ ¤ ¦ ° ¡ ­ « £ ¤  ±   ¢ ¨ Ÿ  ¤   ¢   ¢ ± ¨ ¡ ¨ ¥ ¡   ¢ Ÿ   ¦   ¦  ³
¤ « ¨ ±  ¦ £ ¨ ¤ ­ « Ÿ ¨ ¢  œ ¡ ¨ ¢ ¡ ¡ ¨ ¦ ¨ Ÿ ¨ ¢ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨ ¢
± ± ³ ´ › µ · Ì Ï ¢ ­ ¨ ¢ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨ ¢ ¢   ¥ ¨ ¢ ¨ œ   œ
° œ ¨ ¤   Ÿ Ÿ   « œ ­   ¤ ±  œ   Ç « à œ £ ° œ ­  ¨ £ ° œ ­  ð ñ ò
Ê
¡ ¨ ¦   ¦  ¤ « ¨ £ ¤ « œ ± « £ ¨ ¡ Á Ð ¢ « ± ¨ ¦   œ ­   Ÿ « ¢ ­ ¤ « ¥ ° « ³
Ÿ ¨ É £ ¨ ¤ ¨ Æ ¨ ¤ ¨ œ ­ « Ú ¨ ¤ ¯ °     ¡ ¨ ± ±   ¢  ¨ ¡ ¨ ¦   ¦  ³
¤ « ¨   ¢ ± ¨ ¡   ¢   Æ Ë œ   ¡ œ Ë ¦   ¤  Ÿ   £ ¤  ±   ¢
¨ Ÿ  ¤   ¢ Ì
· Ÿ   ¦ ª ¢ É œ   ±   ¢ « ­ ¨ œ ° œ ¨   ¢ ­ ¤ ° ± ­ ° ¤ ¨ Ÿ   Ÿ « ¤   ± ­  ³
¤ «  £ ¨ ¤ ¨ ¦ ¨ œ ­   œ   ¤ ¡ ¨ ±  ¼   ¤   œ ± « ¨ Ÿ   ¡  ¢ ¥ ¡  ¯ °   ¢
  œ ± ¨ ± ¼   ð ó ò Ì
ô ¨ Á  ¤ ¦ ¨ ±  œ È   œ ± «  œ ¨ ¡ Ÿ    ¤ Æ ¨ œ « Ú ¨ ¤ ¡ ¨ « œ ³
Á  ¤ ¦ ¨ ± « à œ Ÿ   Ÿ « ¤   ± ­  ¤ «  ±  œ ¢ « ¢ ­     œ ­   œ   ¤ ° œ ¨
  œ ­ ¤ ¨ Ÿ ¨ Ÿ   Ÿ « ¤   ± ­  ¤ «  £ ¨ ¤ ¨ ± ¨ Ÿ ¨ ¥ ¡  ¯ °   Ÿ   ¡ ¨
¦   ¦  ¤ « ¨ £ ¤ « œ ± « £ ¨ ¡ Ì Ï œ ± ¨ Ÿ ¨   œ ­ ¤ ¨ Ÿ ¨ ¢     ¢ £   ± « ³
õ
± ¨ ¯ ° ö œ  Ÿ  ¢ ± ¨ ± ¼   ¨ œ Ÿ « ± ¼  ¥ ¡  ¯ °   À ± à Ÿ « Æ 
Ÿ   ±  ¦ £ ¨ ¤ ­ « ± « à œ Å
Ê
± ° ª ¡   ¢   ¡   ¢ ­ ¨ Ÿ  Ÿ   Ÿ « ± ¼ 
¥ ¡  ¯ °   À ¥ « ­ ¢ Ÿ     ¢ ­ ¨ Ÿ  Å Ì Í   ¥ « Ÿ  ¨ ¡ ° ¢  Ÿ   ¡ ¨   ¢ ³
­ ¤ ° ± ­ ° ¤ ¨ Ÿ   Ÿ « ¤   ± ­  ¤ «  É œ  ¢ ¨ £ ¨ ¤   ±   œ  ­ ¤  ¢ Ÿ  ¢
£ ¤  ¥ ¡   ¦ ¨ ¢ ¨ Ÿ « ± «  œ ¨ ¡   ¢ ¯ °   ¨ Á   ± ­ ¨ œ ¨ ¡ ¨   ¢ ± ¨ ³
¡ ¨ ¥ « ¡ « Ÿ ¨ Ÿ Ÿ     ¢ ­ ¨ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨ Ì Ï ¡ £ ¤ « ¦   ¤  Ÿ  
  ¡ ¡  ¢ ­ «   œ   ¯ °   È   ¤ ±  œ ¡ ¨ ¢  ¥ ¤   ± ¨ ¤ Æ ¨ Ÿ   ¦   ¦  ³
¤ « ¨ ¯ °   ¤   £ ¤   ¢   œ ­ ¨ ¡ ¨   ¢ ­ ¤ ° ± ­ ° ¤ ¨ Ÿ   Ÿ « ¤   ± ­  ¤ «  É
Ê
¨ ¯ °     ¡ ± à Ÿ « Æ  Ÿ   ±  ¦ £ ¨ ¤ ­ « ± « à œ ¢ °   ¡   ° ¢ ¨ ¤
° œ ¥ « ­ £ ¨ ¤ ¨ ± ¨ Ÿ ¨ œ  Ÿ  À ÷ ø Ø Ø ù ú û ü  ý Ò Ö ù þ Ô Õ Ö × Ó
ð ó ò Å É ±  œ ¡  ¯ °   ¨ ° ¦   œ ­ ¨ ¤ ª ¡ « œ   ¨ ¡ ¦   œ ­   ¢   Æ Ë œ
  ¡ œ Ë ¦   ¤  Ÿ   œ  Ÿ  ¢ Ÿ   ¡ ¢ « ¢ ­   ¦ ¨ Ì Ï ¡  ­ ¤  £ ¤  ³
¥ ¡   ¦ ¨ ±  œ ¢ « ¢ ­     œ ¯ °   ¨ ¡   ¢ ­ ¨ ¤   ¡ Ÿ « ¤   ± ­  ¤ «    œ
¡ ¨ ¦   ¦  ¤ « ¨ £ ¤ « œ ± « £ ¨ ¡ É ¡ ¨ ¢ ¡ ¨ ­   œ ± « ¨ ¢ Ÿ   ¡  ¢ Á ¨ ¡ ¡  ¢
Ÿ   ± ¨ ± ¼   ¢  œ ¦ °
Ê
  ¡   È ¨ Ÿ ¨ ¢ Ì
Ï œ   ¢ ­   ¨ ¤ ­ Ð ± ° ¡  £ ¤  £  œ   ¦  ¢ ¡ ¨ ¨ ¤ ¯ ° « ­   ± ­ ° ¤ ¨
Ÿ   Ñ Ò Ó Ô Õ Ö × Ó Ò × Ø Ò Ù Ô Ó × É ¯ °   ­  ¦ ¨ ¡ ¨ ¢ È   œ ­ ¨ Û ¨ ¢ Ÿ  
¡ ¨ « œ ­   Æ ¤ ¨ ± « à œ Ÿ   œ ­ ¤  Ÿ   ¡ ± ¼ « £ Ÿ   ¡ £ ¤  ±   ¢ ¨ Ÿ  ¤
£ ¨ ¤ ¨ Ÿ « ¢   Î ¨ ¤ ° œ ¦ ° ¡ ­ « £ ¤  ±   ¢ ¨ Ÿ  ¤ ± ± ³ ´ › µ ·   ¢ ³
± ¨ ¡ ¨ ¥ ¡   Ì Ï œ œ °   ¢ ­ ¤ ¨ £ ¤  £ °   ¢ ­ ¨ É ¡ ¨ « œ Á  ¤ ¦ ¨ ± « à œ
Ÿ   Ÿ « ¤   ± ­  ¤ «  ¢   ¨ ¢  ± « ¨ Ë œ « ± ¨ ¦   œ ­   ¨ ¥ ¡  ¯ °   ¢
¯ °     ¢ ­ ö œ   œ ¨ ¡ Æ ° œ ¨ ± ¨ ± ¼   É  ¥ ­   œ «   œ Ÿ  ¨ ¡ ¨ È   Ú
° œ ¨ ¦   œ  ¤ œ   ±   ¢ « Ÿ ¨ Ÿ Ÿ   ¦   ¦  ¤ « ¨
Ê
° œ ¨ ± ±   ¢ 
¦ ª ¢ ¤ ª £ « Ÿ  ¨ ¡ ¨ « œ Á  ¤ ¦ ¨ ± « à œ Ÿ   Ÿ « ¤   ± ­  ¤ «  Ì
   
                    
    
"
  #  % &   )    %    &   )   .  #  & 0  &       "
)    &  #      &  
    #  &      & #  # 8   &  &
    &       ;   #           
  ? @

  & "
  C #   &    & &     # #      &   )  
   "
  C     # 
C  
  &  #   &      G  &        "

     
 &    C     # 8    #     &   C J   
K

8 
      # #       
  &      #     

 # #       
J   &
   @
  
K
#    8  #    
   #       
 #  
 
#  &   & #   &   #   &     
   #   & W      
#  # 8  C   # 8  W        &  [    &     \ ] ^   
  )   #  &  
_
&      & 
   & W 
  #  % &  
 
 #  
  @ &   #       
   #       
 # "
 
    a 
 C  &   
  

 W 
 & #   ;   #   

     ?     )         #  &   &   & 

    &
  #  # 8     &     \ ] ^  
   &   & 
   & W 
"
  #  % &    
 #  
      &     @ f          C
     #      
 W 
 & #       # 8    )    & #  & "


 &    & W 
  #  % & &  #   
   &   #  # 8    
&     \ ] ^ C #  &   )   &    &  #   
   # #   

    
  
 & #     C
   #   &     [       & #  
   W     @

 &   
a  C   8  # 8   
  
 
 &   #  # 8 
 & 
    #  &  & W 
  #  % &    
 #  
      

   # 
 
      G     &   )       #  # 8 
)     
[     
   &    # #     
K
C  
  & "
  C  &     &    &         W        #  # 8  @
h W 
  &      &   C     #           
  )  
 i 8   &    
K

[           #  #   &   8  # 
)           W          &   & a  @ &  
_
a  "

       
  
   #  % &  i     &    & 
  
& n  
        )        #  &     ;     &   & "
  #  # 8             ?  &   #  # 8      
 # 
"
a     
   
   #    #  &   & #   &  
K
 
  

   #       
 #  
    a 
 @

       
 "
#  
)           #      [ &    C    &         "
#  #  % &       )   #  &    &    &        
"
0    #    #  &   &  %    &  o     & #
   &  
 &   & n  
     )    )    
[  &        &
#  # 8  @
p    
 
       C  
  &   C   
    
 & 
_
#    W  &     &      @ & 
  
  a 
C  
 
 # 
a           & W 
  #  % &    
 # "
 
   
   #     &  & W  #  
    o    
#    
   #  &            
 #  
  #  &   & "
#   &   @ &   a  &     a 
C  
   #     # #    
   & W 
  #  % &    
 #  
  C    &   &     0  "

    8      &     &            0  #  #  % &

s t u v w x
y  
z {  v | } x ~ ~ |  t  { } € { w z x ~ x ~ ! |  ‚ } } { "
#
w | ~ x w u x  x „
         #  #   &   @

       
 [ #      
a  &  G       a    & "
      @ …    # #  % &   W
 #   &     #
  "
#  % &  # 
#         )       
   # #  % &   
    .     
 #  
   i     &    @ …     # #   &  

K
o    #
  &   
)     #  
     .   
K
 

   #       #      
    
    #       &   @
…    # #  % & &  & 
   #            a [        "
   &         #   &   @ …    # #  % & '     
   

           &    
 
       @ )  &     &   C
    # #  % & ˆ     
    #  & #      &        

  0 
K
   W   
   [      &      a  #  % & @
* ‰ ,
Š ‹ . ‹ 0 Œ Š  2 ‹   Œ ‘ ‹ ’ Œ
“ &       
 & #       
              "
     # # " p “ ” h      
 # 
a        "

  )    & 
   #      
 #  
    
 #  
  @
f  # 8   
 # 
a    
[     a 

 
   &  

 & #        #   &                
  )  
&  #     
[      
    
 0  #   
       #  "
#   &           C     &    &      & n  
  
&              
K
# %   a    #    
  #  % &
   a    • – @
h   8 
  
   # 
      .      
 #   "

    8  &    &      
   #   &     &        "
 
&       8 
 6 
 7
   # #  % &  & — 8 ˜  ™ š —
K

   # #  % &  & — › œ ™ š — • ' – @

…  W 
   

   # 
   & # 8        
 # "
 
     
 #  
      
 
 W 
    #   
_
"
#  #  % &    #   
      
   # %   a    #   "
 
  #  % &      &        ž ™ › › Ÿ ] —   @

 0   "
   C ; \ — š = ^ ¡ ^ ˜ œ \ š • > –       )           &
       
 #     

 ? A C

 a  &     E     • –
K
      &         & n &  #       # %   a 
92 Arquitectura del Procesador y Multiprocesadores
Principal
Memoria
Principal
Memoria
CM/CD
Procesador
IR
CM/CD
Procesador
IR
...
Red de Interconexión Punto a Punto
Chip del procesador Chip del procesador
Nodo 0 Nodo N−1
Dir Cache L2 Dir Cache L2
   



 
  
                 
  


                      #
$ & ( ) * , - . / 0 ( 0 3 4 , - . - $ & : 0 < 4 - . - > 4 ( ) 4 @ > 4 / )
$ &  4 ) $ ) : $ & E : 0 : / & * - G
H J  K L K M N  O Q / - * T 0 U 4
E E - * - $ )  V W M H  M K  X  M Y M Z - E * - ( & 4 - > 4 - , - E - ^
T . - $ & _ $ ` < 0 / ) : $ ) 4 $ & ( - $ - $ ` < 0 / ) ) / ) * - > 4 )
$ & & 4 / . & / . & : e - E ) . & :  f  ) L Y g h  f $ & 4 ) / - 4 $ )
/ ) $ ) : E ) : ( ) * , - . / 0 $ ) . & : ( >
i
) : 0 $ & 4 / 0
j
( - $ ) . & :
( ) 0 4 ( 0 $ & 4 - : 0 < 4 - 4 $ ) - L Y g h  E ) : e - E ) . & : 3  G

H L m K H J  K L K M N   O * & @ ) . - K H J  K L K M & 4 - E < > 4 ) :
( - : ) : > : - 4 $ ) & E ( 3 $ 0 < )

H L , - . - 4 > * & . - . E ) :
4 ) $ ) : G  ) . u E / 0 * ) f > 4 - ( ) $ 0
j
( - ( 0 3 4 T - : - $ - & 4
& E ( ) 4 ( & , / ) $ & - < . > , - * 0 & 4 / ) * > E / 0 ( - , - & 4 w . ^
T ) E & : T 0 4 - . 0 ) : & : 0 4 / . ) $ > ( 0 $ ) & 4 N  O : 0 & 4 $ ) : >
* w : & E - T ) . - $ - , . ) , > & : / - g J  L H K H M M  J K   V g m
K H M M  z > & > : - $ ) : w . T ) E & : T 0 4 - . 0 ) : , - . - 0 4 ( E > 0 .
- / ) $ ) : E ) : ( ) * , - . / 0 $ ) . & : G { 4 ) $ & & E E ) : & : ( - E ^
( > E - $ ) $ & : $ & & E 4 ) $ )  h Y M
i
& E ) / . ) $ & : $ & > 4
4 ) $ ) : 0 * U / . 0 ( ) G

/ . ) : - > / ) . & : , . ) , ) 4 & 4 . & $ > ( 0 . & E - 4 ( ~ ) $ &
E - : & 4 / . - $ - : $ & E $ 0 . & ( / ) . 0 ) f , ) 4 0 & 4 $ ) & 4 ~ - . $ ^
 - . & / - 4 : 3 E ) > 4 4 u * & . ) E 0 * 0 / - $ ) $ & , > 4 / & . ) :
Q & E & < 0 $ ) , - . - z > & ( > T . - & E ( - : ) * w : ( ) * u 4 Z -
( - $ - T E ) z > & $ & ( - ( ~ &
i
* - 4 & @ - 4 $ ) Q ~ - T 0 / > - E ^
* & 4 / & , ) . : ) € /  - . & Z E - : : 0 / > - ( 0 ) 4 & : & 4 z > & : &
, . ) $ > ( & > 4 $ & : T ) . $ - * 0 & 4 / ) & 4 $ 0 ( ~ - & : / . > ( ^
/ > . - N  O G
{ 4 - € ) . * - , - . - . & $ > ( 0 . & E - E / ) $ & E $ 0 . & ( / ) ^
. 0 ) f & : $ & ( 0 . f & E 4 u * & . ) $ & & 4 / . - $ - : $ & E * 0 : * ) f
( ) 4 : 0 : / & & 4 ( ) * T 0 4 - . e - . 0 - : & 4 / . - $ - : $ & $ 0 . & ( ^
/ ) . 0 ) & 4 > 4 - : ) E - N   O G

. < - 4 0 … - . E - & : / . > ( / > . -
$ & $ 0 . & ( / ) . 0 ) ( ) * ) > 4 - ( - ( ~ & N  † O & : ) / . - & : ^
/ . - / & < 0 - , - . - & e 0 / - . z > & E ) : $ 0 . & ( / ) . 0 ) : : & - 4
* >
i
$ 0 : , & . : ) :
i
& : / U 4 ~ - T 0 / > - E * & 4 / & e - ( ` ) : G
‰ 4 N   O : & ~ - T E - $ & > 4 - ( - ( ~ & $ & $ 0 . & ( / ) . 0 ) :
z > & : 3 E ) - E * - ( & 4 - E - : & 4 / . - $ - : $ & > 4 T E ) z > &
: 0 - E < u 4 4 ) $ ) . & * ) / ) , ) : & & > 4 - ( ) , 0 - $ & $ 0 ( ~ )
T E ) z > & G
 Š 
 ‹ Œ  Ž   ‘  Œ ‘  Œ  Ž  ‘
“ - $ 0 € & . & 4 ( 0 - € > 4 $ - * & 4 / - E & 4 / . & > 4 - - . z > 0 / & ( ^
/ > . - $ & $ 0 . & (
/ ) . 0 ) ( ) 4 e & 4 ( 0 ) 4 - E
i
E - - . z > 0 / & ( ^
/ > . - $ & $ 0 . & ( / ) . 0 ) E 0 < & . ) & : E - & E 0 * 0 4 - ( 0 3 4 $ & E
$ 0 . & ( / ) . 0 ) $ & E - * & * ) . 0 - , . 0 4 ( 0 , - E G • ~ ) . - & : ^
/ - 0 4 € ) . * - ( 0 3 4 : & < > - . $ - . w - 4 0 e & E $ & E - ( - ( ~ &
“  f ( ) 4 E ) z > & : & ) T / 0 & 4 & 4 $ ) : e & 4 / - @ - : 0 * , ) . ^
/ - 4 / & : G “ - , . 0 * & . - e & 4 / - @ - & : > 4 - 0 * , ) . / - 4 / &
. & $ > ( ( 0 3 4 & 4 * & * ) . 0 - , - . - E - 0 4 € ) . * - ( 0 3 4 $ & E
$ 0 . & ( / ) . 0 ) G “ - : & < > 4 $ - e & 4 / - @ - ( ) 4 : 0 : / & & 4 > 4
- ( ( & : ) * w : . w , 0 $ ) - E $ 0 . & ( / ) . 0 ) f , ) . & : / - . & 4
( - ( ~ & G

0 4 & * T - . < ) f & : / & . w , 0 $ ) - ( ( & : ) - E - 0 4 ^
€ ) . * - ( 0 3 4 $ & $ 0 . & ( / ) . 0 ) & 4 E - ( - ( ~ & $ & : & ^
< > 4 $ ) 4 0 e & E 4 ) : & . ` - , ) : 0 T E & : 0 & E ( ) 4 / . ) ^
E - $ ) . $ & $ 0 . & ( / ) . 0 ) & : / > e 0 & . - € > & . - $ & E ( ~ 0 , $ & E
, . ) ( & : - $ ) . G • € ) . / > 4 - $ - * & 4 / & f E ) : - e - 4 ( & : / & ( ^
4 ) E 3 < 0 ( ) : ~ - 4 , & . * 0 / 0 $ ) 0 4 / & < . - . - E < > 4 ) : ( ) * ^
, ) 4 & 4 / & : ( E - e & $ & E : 0 : / & * - ( ) * ) & E ( ) 4 / . ) E - $ ) .
$ & * & * ) . 0 - f & E  L H _  L H M $ & ( ) ~ & . & 4 ( 0 -
i
& E 0 4 ^
/ & . € - … $ & . & $ $ & 4 / . ) $ & & : / & ( ~ 0 , G ‰ : / & & : & E
( - : ) $ & E  h Y W L     W  L     " $ & N ' O
i
$ & E
 ) + - L Y Y M H N  O G  ) . / - 4 / ) f & 4 & : / & / . - T - @ )
- : > * 0 * ) : z > & $ 0 ( ~ ) : ( ) * , ) 4 & 4 / & : & : / w 4 $ & 4 ^
/ . ) $ & E ( ~ 0 , $ & E , . ) ( & : - $ ) . f @ > 4 / ) ( ) 4 E - ( - ( ~ &
“  G
“ -
j
< > . -  * > & : / . - E - ) . < - 4 0 … - ( 0 3 4 , . ) , > & : ^
/ - , - . - > 4 * > E / 0 , . ) ( & : - $ ) . $ & ¡ 4 ) $ ) : G “ ) :
4 ) $ ) : $ & E : 0 : / & * - & : / w 4 ( ) 4 & ( / - $ ) : * & $ 0 - 4 / &
E - . & $ $ & 0 4 / & . ( ) 4 & ¢ 0 3 4 , > 4 / ) - , > 4 / ) - / . - e U :
$ & E 0 4 / & . € - … $ & . & $ Q
 /
Z G “ - € > 4 ( 0 3 4 $ & E ( ) 4 ^
/ . ) E - $ ) . $ & * & * ) . 0 -
i
$ 0 . & ( / ) . 0 ) Q 0 ¤ 0 ¥ Z & :
- : 0 : / 0 . - E ) : € - E E ) : $ & ( - ( ~ & G 0 > - 4 $ ) E - ( - ( ~ &
$ & : & < > 4 $ ) 4 0 e & E 4 ) , > & $ & : - / 0 : € - ( & . > 4 - , & / 0 ^
( 0 3 4 $ & E , . ) ( & : - $ ) . f & E ( ) 4 / . ) E - $ ) . $ & $ 0 . & ( / ) ^
. 0 ) : & & 4 ( - . < - $ & - e & . 0 < > - . & E 4 ) $ )  h Y M $ & E
XVI Jornadas de Paralelismo, JP '2005 93
                         "  $      (
" *      , -    1       4 5 7 8    " 
    $        "  " * "       =   ?  "  A  
   " $      "      ,


    "   $  
D
   
         $  "  A      "        " "   
? ?         "     ,


      "   $      
 "                   "  " * 
   M N     
D
8    $   $  8   "       " "  
 ? ?         "     ,
0           "  " * R    "   $     (
            $     U W X  Z   "   $   8
 $   $    "     8     =   ?  "  A      " $  (
   ]
D
     $   , _   " "     ?      $ 
   "  " *  *  "         8  $   ?   
     " "      "  " *  "    "     =   (
?  "  A      " $    
D
   $        8   
    4 5 7 ?   $  a     "     , R     $ 
   U W X   $ e =   ?       "   $   "  ?    =   (
  ?  $       $    $        8   $   
 "  " * 8   $         " $    
D
 " A   M 
 "  ?    $  "  A  ,
_  "  ?      $     "  " *    $  ?  
       "   $              $  "    j _


k l 8 $          M  
m
"       "        "   
   $   
I
Z    e     ] , _      $  "    j _


   "    "  A     " *   $      "  " *   (
$   
I
                     
 ?    1  , _      $  "        " $       M   8
        $           =   ?  "  A 
    " $     Z          $   ] , _   "  (
  8        e    ?    1   
D
$    
   "         " *                    
?   $     "  *   "   Z      " "  A  t    
? e   $     ] , _  "  ?     $        " $  (
      $  ?            Z    $ ] 
•



W v 7 w  "  ?    $    8        (
"   $   "  ?    $           "  " *  8 $  (
       "      "      e     , R  "  " *
      4 5 7         e    (
"   M           "        8
D
   $    e
   "                    * 
D

 "   $    ,
•

   7 w       $     8        (
"   $      
D
 A      "  " *
D
* 
        ?   
m
"       y  $  , R  N   (
"  "      e       $    e   " *  "  " *
D

             "      e      , _    (
  4 5 7   ?   $    e     $     
  "  " * 
        Z   $   

 
         $     ] ,
  ?  y  z   $    $     ?   a "  $  - Z  |
} W } 7 w ] 8         " "          
  "   $   N   "  ?  $  ? ?         "  (
   8          *          "  $      
   M N      8       =   ?    1      
 $       ,
_  " A   M   "  ?    $  "  A    ?  "        (
$                ?   $       "    
          "  " *  ,             (
$ " $        " $       M    "  ?   $   "  
"        $     " A   M   "  ?    $  "  A  Z   
ƒ ?    8    " A   M   "  ?    ?     ] 8      ? (
   "     * ?     $            " A   M  „ … † † |
5 W ‡ , _  $ "  ?   "    $   e     $    "   
         $ ?  8
D
 $   e  " $          " * 
    $      "           ,
 ˆ 
‰ Š ‹ Š Œ Š  Š Ž  Œ Š
 ‰   Œ ‘ ’
R       $ " $      "   $    $     ?  $  (
         $  "     "  *   "    "  " *
  ?          $  "    j _


"     M      (
  •   ?   
m
"  "     , _  $   ?   
m
"  "     
    1       M     $  1         $          (
      $ y     M    "  " * 8     =   ?  "  A 
    " $       $       $    "  " *
R        4 5 7 ,   ? e  8 "           
 ? ?        ?    1       " *  "  " * 8
$        "                     (
?  $                  M       "  *   "   ,
-    ?    $ y  ?     =       "      
 =           =       R     "      
    4 5 7 8
D
 $ y  ?    =      ?  $      
"    "   $      ,     =        "    8     $  "   
 " "       =   ?  "  A      " $     Z    $ 
   U W X  ]
D
    1     ?   ?    " "       
   $  "    "     "      ,
    $       8    =       ?  $          (
         4 5 7 8      "   $           (
 " $     "  ?           =   ?  "  A   "     
           =       "   $    "  " * ,



     "   $   8  $  ?     $   $     ? (
  a "  $  … } W } 7 w , _   "    8    " "  
       ? ?         "    
D
        
 $  "        8   ? e             $    
   "  " *       4 5 7         =   ?  "  A 
    " $     ,
94 Arquitectura del Procesador y Multiprocesadores
            
              "   
$
 &       ) *
 + -   - / 1 2 3 4 5 6 / 1 2 3 4 5 6 / 1 2 3 4 5 6
   / 1 2 3 4 5 6 / 1 2 3 4 5 6 8 6 : < 1 > 4 3 > 5 1 ? 6 4 5 6
A  D  
*
 + -   - E 8 6 : < 1 I J K L 8 6 : < 1 I J K L
   / 1 2 3 4 5 6 8 6 : < 1 I J K L 8 6 : < 1 > 4 3 > 5 1 ? 6 4 5 6
0
            
        "  %           
+
      
     .  
 
 "   
  1          .       6        %      9   :

  "      %    
        "  %   
               B      C D E     F     G
           %  %   .    .   : J   % F  K 
                    O P E Q K   B     B 
  % S T  .   
   .     S  V

+
K .     G
 K .   F   6 F       %      %       .   G
    :
Z  
         % .   \  K   .      
 "          _ Z

      V
   .  G

          B        C D E :

      
   S  V
    % .   \       O P E Q K       G
              S  S
       "  %   
       V
       .     S  V

+
  G
6      %     d      6       : 0
    G
          .      
g
 %        G
6           .       F      % .   \ :

 
        S  V
    % .   \     C   E Q
+
 
j     .    .   
     %  K   % S T 
    S   6         .  .       .
T     % G
.   \   
+
  
  \     %  %   .    .   :
Z                %    d      
+
 G
%
+
  B      .               G
6       : Z  
     
%     6     d    

     .  .
    : Z         9    6   
 %  %   .    .    S
       "  %     
      
              O P E Q C   E Q :
J   % F  K             O P E Q        B    
   C D E   V
   6    S  V
 :   j   % K
        %   "  %            .   
S  V
         m  n O n  E Q    V
   
 G
%         S   %       %  %          
.    %           B       :
N o 
p q r s p r u v v w x  z x { | } p
O  % 
  
  6     % 
g
        %
G
    9
  .     d  
 
. 
_ € P  n E  D ƒ
m „ O … C P † C P R S T ( m „ …  ‡ P C n E   C P  ˆ Š  ‹ : O  % 
 %
  
     %    G  Ž _ J      G
  V
 % .   %       .            G
U V W X Y Z \ ] Y ^ _ a b ] b W d f g b X b h b i b j V k Y g b
f \ g l Z Y X g b W ] Y i o g b h Y W \ ] b g p j f
r s t u v w x y x x s t z { u v s } y x u { ~  € 
‚ y } y ƒ „ … w ƒ y † ‡ ˆ ‰ Š ‹ Œ ‡ ˆ Ž Œ ‡ 
r s  ‘ y  y x s w  } ‘ { ” v v w u  s } ~ • –
— { s x w v ‘ u { x s } y t ‘ u } ™ • š w ‘ y › { s s
 ž
u  ‘ y x u { s } • Ÿ  –
  
Š ¡ ¢ £ ¤ ¦ ¡ § § ‡ Œ ¨ –
f \ g l Z Y X g b W ] Y i \ h \ h © Y
‚ y ƒ y ª u x s t y t «  s y x s v y v ¬ s ­  š ® ‘ s }
ž
y v ¬ s ¯ ~ x w ° w x w x y s  ± ² ³ ™ ¤ Œ Ž ˆ ‡ ´ ˆ Š Œ £ µ ¶ Š

‚ y ƒ y ª u · y } u v w y ‘ w ° w x y x ~ ­ ¸ ¹ · ƒ y z s u x w { s v ‘ u

‚ w s ƒ z u x s y v w s { ‘ u • v w v t u }
ž
y v ¬ s ¯ • ”  w » v y x y ™ ¤ Œ Ž ˆ ‡ ´ ¼ ¡ ‰ ½

‚ y ƒ y ª u · y } u v w y ‘ w ° w x y x ­  ¸ ¹ ·  ¾ ° « y }

‚ w s ƒ z u x s y v w s { ‘ u ~ ¿ v w v t u } À ­ Á à Ä
f \ g l Z Y X g b W ] Y i ] V g Y h X b g V b
ž
u  ‘ { u t y x u { x s x w { s v ‘ u { w u ~ v w v t u À u  ¾ v ¬ w z Ä
±  Å u { ƒ y v w Æ  x s x w { s v ‘ u { w u ­ v w v t u } À ˆ ¡ ¶ ¯ • Ä
ž
{ s y v w Æ  x s z y Ç ” s ‘ s } ™

— { w ƒ s { ƒ s  } y È s  v w v t u }
 É
w › ” w s  ‘ s } ƒ s  } y È s } • v w v t u }
f \ g l Z Y X g b W ] Y Z Y Z b g V \
‚ w s ƒ z u x s y v v s } u y ƒ s ƒ u { w y – Ÿ v w v t u }
±  ‘ s { v y t y x u x s ƒ s ƒ u { w y  ° « y }
f \ g l Z Y X g b W ] Y i Ê Ë W
Ì
 v ¬ u x s š y  x y – š ® ‘ s }
ž
w v t u } x s š ” } ~ v w v t u
f \ g l Z Y X g b W ] Y Í Y ]
‚ u z u t u › « y Î y t t y š w x w ƒ s  } w u  y t
‚ y ƒ y ª u x s t Ï Ž ˆ – š ® ‘ s }
‚ y ƒ y ª u x s ƒ s  } y È s } w  x y ‘ u } • Ï Ž ˆ ¨
r s t u v w x y x x s t Œ £ µ ˆ ‡ Œ • ¿ Ÿ Î € 
Ð s ‘ y { x u x s
Ì
{ š w ‘ { y È s  v w v t u } x s t Œ £ µ ˆ ‡ Œ
r s t u v w x y x x s t v y  y t ¿ Ÿ Ÿ Î € 
Ì
 v ¬ u x s t v y  y t Ñ • š w ‘ }
0
        F %     S F           %  :
  9   : Z  
    %
       .   F %    

    .     6  
      V
   
  .  .
    :
Z      %
        %              
             .         … O  
+
     
        B   .    .         %    :   j  G
 % K  %      V
 B  % 
  \  
  6   G
  .  % \                   
    
   d  
       9     .  
   6   :
1    .       
  \           %
  G
    
S   
   % .   9  %    .      
   %
    
+
 % .
    : Ò Ó Ô Õ Ö × €  ' 

  .  K ‘ .    ˆ K Ù Ù Ú €    Û  % .   d  ˆ K
XVI Jornadas de Paralelismo, JP '2005 95


 
  
    
                
 
  

  
! 
 
    
$   &  '     
)        -
    - 1 ' - 3 
  )        -  
 

 8 :


<
=  > ?
! 
   
 
 $    
 
 )        ' -   )       G -
   $ ) ' 3    G -

  ' 
 
 - J $     K  
        '  3 
 
$   3  
   -   3    3 R  '         )  -
 -   
U    )       
     )        -   K 8   3  $  Y  

 )   Z   $ 
     )        -   ]  -  
   <
  ^ 
 
 3   $ 
 ` '       - 1 ' - 3  
 3   <
Z  1     - $ 
!
    ` '      )   


   
   ]   K
 d
e f g h  j k m o g q k t   v g v g
x -   3       G -   $ )    $     $  $     -    <
     )      $    -      - U   $    G -

    <
3     3  - 3  )        ` '  3   3 '   )   ) '   3    <
$  )     3      ` '  $  
   $ )     G -
 
 G
 ^ 
   $ )   3    G - K :
 $ J   $   3   $  
  $  1     - 3   $ ) 
  1   '   G -  Z 3  - 
   -
   )   3       ^  -  }    G -   -   -    -   K
   # % & ( * * , . / % / 2 % 2 4 5 , 7
x    3  -
  U   3     ` '   $ ) 
 -         <
Z   


 
    3     K x - )   $    ' ^       
'    ‚ ƒ ƒ „ … † ‡   - ˆ $   
 Z  3  '  
  )     
 G
 ^ 
   $ )   3    G - 3   -
   -    $  - 3  
  -    $  - 3    - U   $   ' $  - 3    - ˆ $   

- 
 
     3  $  K x -   ^ ' -
  ' ^      -    <
  3  - 3  - 3    - 3  
 

    3       $  Z   <
` '    - $  $     )   -   )   3   -       3  $  K
x   Z 1  3   
   3    3 R  '     $  1         <
    Z   


 
    3      
'    -
   - ˆ $   

  - 3  
  K

 -  $ Z   ^       ^  -  }    G - )   <
) '   3    ) ' 
   $ Z  -     - 3 &  -    
   <

'    G -
   G
 ^ 
   $ )   3    G - K 8 
Œ
^ ' <
   $ '   3         '   G -
     Z      ^ 

 $  $      - U ' -   G -
  - ˆ $   
 - 
  K
   3   $    G     )   3        )  -
  - 3    
  Z      ^ 
 ]   3  ' - 
 )    ) 
 
  3  - <
^ '   Z   -   
 U    -      - 3      3    ˆ  3  $  
  ` '  $   K
 $     -  
  
 ' - $ '  3  )     <
 
    -

GB

 $  $     )   -   )   

MB


   ]  8

!
3  $  Y 
 Z   ` '  
 Z
!
3    )   
     ` '  $    ‚ ƒ ƒ „ … † ‡   ‘ † ’  “ ” “  • ‘ ’   ' $   - <


K = 4
  – ’ †  „ • ’ —  • † • “  ˜ —  † ’  • ’ “ “  — •   ‚ ˜ „
• ’ “ “    ' $   -
  - 
    $ & 3      
!
- '   3  
™ š › œ  ž
Ÿ  9
 

 ¡ ¢ ž  › ž £ ¡ ¤ ¡ ¤    š ž £ ¡ £ š  ¡ ¢ ¥    š  
¦ ¡ › : § ¨   ¦ §   £   ¦ £ ¡ ¨ ¦ š ¦ ¥ ¡ ¤ ž ©
)   ) '   3  K
x    ` '  $   ‚ ƒ ƒ „ … † ‡ 3   -  ' -        Z   


  $  3 

!
)    ' -    3  $ 
 

 - 
   
3  $  Y 
   G
 ^ 
   $ )   3    G -  ^ '     

' - Z   ` ' 
 $  $       Z      ^ 
  

  K
! ‘ † ’  “ ” “  • ‘ ’  
'       Z      ^ 
 $  $  <
    )    -     '    -    )   Z   $ 
       Z  <
 

K

’ †  „ • ’ —  • † • “
!
˜ —  † ’  • ’ “ “ )     - 3  -
' -  $  1         Z   

 ' $  - 3  -

 U   <
$    ^   R 3 $      -   - ˆ $   
 - 
  K "  <
-   $  - 3    
    3       ^      ^   ' -  $ 
!
 
 
'    G - ` '       ` '  $    - 3       
!
     
)   U   3  $  - 3  )    ' -    3  $ 


  - 
  K
8  $  1     Z 3  - 

 )  -
  J
         G -

 3  $  Y   - 3      ] 
!
$  $     )   -   )   
)     ` '  - '   3   )   ) '   3   
'    J  ˆ - $ J 
    Z      ^   -    U ' 3 '      ` '  3   3 '      <
« ¬  : K
  <  = % @ 4 5 7 % / E , % 2 H 4 & % % @ % * ( * , . /
x 
    3       ^     Z 3   -  3  $ Z  & - Z  - 
Œ
   
 -   3   $ ) 
  1   '   G -
 Z 
    $  -  
  3  -   
           - U   $    G -

    3  <
   )     )    3    
  ) ' 
         ' - $  <
!
  - ˆ $   
    $ )   }  
 ^  
 -
   R  
  -
 $   - 3  K 8 
Œ
^ '    $ '   3     3   $ ) 

 1   '   G - )    ' -    ` '  3   3 '     -   -    -  
  $      

  ’ — – — 



$ 


=   ?   )   
' -    ` '  3   3 '  

    3       ^    
   
 -   ` '   G     3   -   -  '  - 3    Z  - 
Œ
<
  
  $  -   3   $ ) 
        
    3  <
   
!
)        ` '  3   3 '  

    3       ^   
    K

  Z      ` '     $  1    
      
  
  -
  &   
'  K     3    
      <
       Z 3   -  $  1       -    )   3       
96 Arquitectura del Procesador y Multiprocesadores
   

                
 
  


    &        )     
+      
/     
1

      


                  

   ! #  %  
&  %  ) *
+ , *
+  *
+ - *
* /
 *
* 0 *
* 0 *
* / *
* /

   *
+ , *
+ , *
* 0 *
+ /
1  3  4 *
+ + *
+ 5 *
* + *
+ /
  )  % 8   *
5 9 *
5 : *
5 9 *
* +
   % = 
> 
*
/ * *
/ * *
* 9 *
+ /
0 3 5 6 7 8


:
 =
 : 




 :    &     : +
:     
   

     
   =
 :  
:  &   
  1
G 8 H I J H G L 8 H 5 O P 5 7 5 R 8 6 5 S O 5 S 5 P O L G 5 G L 8 H J S S 5 O V
I 8 ?    X  Y
6 J 6 J \ 7 5 6 5 G L ] H _ `  5 7 R L G 3 O 5 7 V
b J H R J c   @ ? B
d
C ? D B @ F 8 f R L J H J H O 5 S b J h 8 7 J S
P 7 J S R 5 G L 8 H J S c G 8 H 3 H 5 7 J 6 3 G G L ] H 6 J O 

d
6 J O
 '
7 J S P J G R L I 5 b J H R J c b L J H R 7 5 S k 3 J P 5 7 5 O 5 S
8 R 7 5 S 5 P O L G 5 G L 8 H J S O 5 7 J 6 3 G G L ] H 8 S G L O 5 J H R 7 J Y

d
 
`
n O G 3 5 6 7 8
5
d
3 6 5 5 G 8 b P 7 J H 6 J 7 O 5 S 6 L o J 7 J H V
G L 5 S J H R 7 J J O G 5 S 8 L 6 J 5 O
d
J O 7 J 5 O ` r 3 J S R 7 5 P 7 8 V
P 3 J S R 5 H 8 5 o J G R 5 P 7 s G R L G 5 b J H R J 5 O R 8 R 5 O 6 J O 8 S
o 5 O O 8 S 6 J G 5 G t J c G 8 b 8 S 3 P 8 H u 5 b 8 S J H O 5 L H R 7 8 V
6 3 G G L ] H c
d
5 k 3 J H 8 S J P 7 8 6 3 G J 3 H L H G 7 J b J H V
R 8 S L \ H L
w
G 5 R L I 8 6 J O 8 S 7 J J b P O 5 y 8 S J H G 5 G t J ` z 5
5 P O L G 5 G L ] H

B F  D   D @  J S O 5 k 3 J b s S S J 5 S J V
b J h 5 5 O G 5 S 8 L 6 J 5 O c 6 J f L 6 8 5 k 3 J O 8 \ 7 5 7 J S 8 O I J 7
G 5 S L R 8 6 8 S O 8 S o 5 O O 8 S S L H 5 G G J 6 J 7 5 b J b 8 7 L 5
P 7 L H G L P 5 O ` n H G 5 b f L 8 c J O 7 J H 6 L b L J H R 8 6 J   @ ? B
S J 5 O J h 5 6 J O L 6 J 5 O 6 J f L 6 8 5 k 3 J 7 J S 3 J O I J R 7 J S
6 J G 5 6 5 G 3 5 R 7 8 o 5 O O 8 S 6 J G 5 G t J J H b J b 8 7 L 5 ` n O
J G t 8 6 J b 5 H R J H J 7 O 5 R 5 S 5 6 J o 5 O O 8 S R 8 R 5 O G 8 H S V
R 5 H R J S J R 7 5 6 3 G J J H O 5 7 J 6 3 G G L ] H 6 J O 
G 8 H
7 J S P J G R 8 5 O 5 5 7 k 3 L R J G R 3 7 5 G 8 H I J H G L 8 H 5 O `  L H 5 O V
b J H R J c J H ?    5 3 b J H R 5 O 5 R 5 S 5 6 J o 5 O O 8 S
d
O 5
b 5
d
8 7 u 5 R L J H J H k 3 J L 7 5 b J b 8 7 L 5 5 f 3 S G 5 7 O 5
L H o 8 7 b 5 G L ] H 6 J 6 L 7 J G R 8 7 L 8 ` n S R 8 t 5 G J k 3 J J O G 5 V
S 8 7 J 5 O 8 f R J H \ 5 b 3 G t 8 P J 8 7 7 J H 6 L b L J H R 8 k 3 J
J O L 6 J 5 O c
d
O 8 k 3 J J S P J 8 7 c O 5 R 5 S 5 6 J 5 G G J S 8 S
5 b J b 8 7 L 5 J S b 5
d
8 7 k 3 J J H J O G 5 S 8 G 8 H
I J H V
G L 8 H 5 O c P 8 7 O 8 k 3 J 6 J \ 7 5 6 5 S 3 7 J H 6 L b L J H R 8 G 8 H
7 J S P J G R 8 5 6 L G t 5 5 7 k 3 L R J G R 3 7 5 ` n H O 5
w
\ 3 7 5  S J
8 f S J 7 I 5 f 5 k 3 J c J H J O G 5 S 8 6 J ?    c O 5 b 5
d
8 V
7 u 5 6 J O 8 S f O 8 k 3 J S 5 O b 5 G J H 5 6 8 S J H G 5 G t J P 5 7 5
b 5 H R J H J 7 O 5 L H o 8 7 b 5 G L ] H 6 J 6 L 7 J G R 8 7 L 8 t 5 f u 5 H
S L 6 8 5 G G J 6 L 6 8 S 5 H R J S P 8 7 J O H 8 6 8  … † ‡ 8 S J 7 s H
5 G G J 6 L 6 8 S 6 J S P 3 ˆ S ` n O P 7 8 f O J b 5 P 8 7 R 5 H R 8 7 5 V
6 L G 5 J H J O 8 7 6 J H J H J O k 3 J S 8 H 5 O b 5 G J H 5 6 8 S c O 8
G 3 5 O S J P 8 6 7 u 5 S 8 O 3 G L 8 H 5 7 G 8 H 3 H 5 O \ 8 7 L R b 8 6 J
5 O b 5 G J H 5 b L J H R 8 8 7 J J b P O 5 y 8 J H G 5 G t J 6 L S R L H V
R 8 5 O 3 S 5 6 8 ` ‰ H 5 I L S L ] H b s S 6 J R 5 O O 5 6 5 6 J O 8 S
7 J S 3 O R 5 6 8 S P 3 J 6 J I J 7 S J J H Š   ‹ `

Π
 Ž    ‘ ’  Ž “ ‘ ” – — ˜  ˜     –  — 
n H J S R J 5 7 R u G 3 O 8 t J b 8 S P 7 J S J H R 5 6 8 O 5 5 7 k 3 L R J G V
R 3 7 5 6 J 6 L 7 J G R 8 7 L 8 O L \ J 7 8 G 8 b 8 3 H P 7 8 R 8 G 8 O 8 6 J
6 L 7 J G R 8 7 L 8 S J S G 5 O 5 f O J k 3 J J O L b L H 5 J O 6 L 7 J G R 8 7 L 8
6 J O 5 b J b 8 7 L 5 P 7 L H G L P 5 O ` I J b 8 S L H R 7 8 6 3 G L 6 8 J O
G 8 H R 7 8 O 5 6 8 7
d
O 5 L H o 8 7 b 5 G L ] H 6 J 6 L 7 J G R 8 7 L 8 J H
J O G t L P 6 J O P 7 8 G J S 5 6 8 7 ` ™ J J S R J b 8 6 8 c O 8 S o 5 O O 8 S
6 J G 5 G t J J I L R 5 H L 7 5 b J b 8 7 L 5 P 7 L H G L P 5 O
d
S 8 H
7 J S 3 J O R 8 S G 8 H b J H 8 7 O 5 R J H G L 5 `
I J b 8 S 6 J S G 7 L R 8 O 5 5 7 k 3 L R J G R 3 7 5
d
J O P 7 8 R 8 V
G 8 O 8 6 J G 8 t J 7 J H G L 5 5 6 J G 3 5 6 8 5 O 5 S P 5 7 R L G 3 O 5 7 L V
6 5 6 J S 6 J O 6 L S J š 8 P 7 8 P 3 J S R 8 ` I J b 8 S S L b 3 O 5 6 8
3 H G 8 H h 3 H R 8 6 J 5 P O L G 5 G L 8 H J S G L J H R u
w
G 5 S G 8 H J O
S L b 3 O 5 6 8 7
.  
› 5 6 5 P R 5 6 8 5 H 3 J S R 7 5 5 7 k 3 L R J G V
R 3 7 5 c 8 f R J H L J H 6 8 7 J S 3 O R 5 6 8 S 6 J t 5 S R 5 J O 

6 J b J h 8 7 5 J H R L J b P 8 6 J J h J G 3 G L ] H ` ž 6 J b s S c
t J b 8 S 7 J 6 3 G L 6 8 J O R 5 b 5 š 8 6 J O 5 L H o 8 7 b 5 G L ] H 6 J
6 L 7 J G R 8 7 L 8 6 J R 5 O b 8 6 8 k 3 J H 3 J S R 7 5 P 7 8 P 3 J S R 5
J S G 5 O 5 P J 7 o J G R 5 b J H R J P 5 7 5 3 H b 3 O R L P 7 8 G J S 5 6 8 7
6 J  Y " H 8 6 8 S `
0 8 b 8 o 3 R 3 7 5 S I u 5 S 6 J L H I J S R L \ 5 G L ] H P 7 8 V
P 8 H J b 8 S J S R 3 6 L 5 7 O 5 P 8 O u R L G 5 6 J 5 O b 5 G J H 5 b L J H V
R 8 6 J f O 8 k 3 J S J H O 5 G 5 G t J z c 6 J R 5 O b 8 6 8
k 3 J P 8 6 5 b 8 S 6 J G L 6 L 7 S L J S G 8 H I J H L J H R J 8 H 8
5 O b 5 G J H 5 7 J O f O 8 k 3 J J H O 5 G 5 G t J ` ž 6 J b s S c P 8 V
6 7 u 5 b 8 S J S R 3 6 L 5 7 J O L b P 5 G R 8 6 J R J H J 7 G 5 G t J S
S J P 5 7 5 6 5 S P 5 7 5 f O 8 k 3 J S G 8 H
d
S L H L H o 8 7 b 5 G L ] H
6 J 6 L 7 J G R 8 7 L 8 ` ™ J J S R 5 o 8 7 b 5 c 3 H 5 6 J O 5 S G 5 G t J S
H J G J S L R 5 7 u 5 b J H 8 S b J b 8 7 L 5 `  L H 5 O b J H R J c P 5 7 5
7 J 6 3 G L 7 b s S O 5 S 8 f 7 J G 5 7 \ 5 6 J O 6 L 7 J G R 8 7 L 8 P J H V
S 5 b 8 S J I 5 O 3 5 7 J O 3 S 8 6 J P 3 H R J 7 8 S O L b L R 5 6 8 S 8
G ] 6 L \ 8 S 6 J G 8 b P 5 7 R L G L ] H G 8 b P 7 L b L 6 8 S J H O 3 \ 5 7
6 J £ ¤ ¥ ¥ ¦ † § ¨ `
XVI Jornadas de Paralelismo, JP '2005 97
     
  
          " #



" & ' ) * + ' #
  


 -  /  #
 & 2
 4 6  7 "      " 9 ; + = + * 4 - +  7 " 9
-
@
 -  B 7 +  7 6 - + D " - G B *
@

  *  H * +   9
J L    6 * 7 P - "  + Q Q " - Q     S U  U X Y
Z \ ^  ^   U S U _ _ ` _ U  c  \ Z S \ d e Z ` c  Z ` f #
g h  i  i  #
 & 6  -
@
    
      G  -   * #



m " & #
 + & & + Q Q
@
#  & 2
  " - "  7 '    &  =  * 6  7 " & " D 4 - +  7 " -
@

 B + m + Q D " -    B +  " B + - + &  +    S ^ X  ^ p
Z  `  Z    Z  _   f q ^ \ e f ^   ^ f q e Z ` S

S X  \ Z ` X Z e S `   
    # P  G + Q        #
 
@
   
      B m + 2 #   " &  
@
#   6 G B + Q #  & 2
!   + H + -     4
"
P 7 + - " &


B  - + 2
 + m " -
@


@
Q 7 + m Q    S ^ X   Z 
^ Z   \ q  f q ^ \ e f #  6 G 6 Q 7     
 v  ;   + & Q + -  & 2  ! +  6 7 - + -    J + 

" 9
* 6 7 " & 7 "  " B + - + &  + - " H * + m Q &  6 * 7 9
   B +

@
Q 7 + m Q     S U  U X Z \ ^  ^ 
 ^ f q e Z ` S #  i g  h     # 4 +  + m H + -
 i  
   4   B  + & #
 6 H  7 "   ' #  & 2    G  - 9
  *   ; m 7 ; 
 
4 - +  7 " - + Q  

  *  H * +
   B +  " B + - + &  +

 B + m +    S ^ X  ^ p   Z  _
 ^  p ` S `  X ` ^ 
S X  \ Z ` X Z e S U _ e q q ^ S Z p ^ S
 S ^  S U f f \    U   e U  ` U  c  q ` S U Z \  
 Z ` f 
      # P  G + Q   v    v #
 P - *   
  4     6 * * + - #
 

& G B #  & 2  


6 P 7  
$
 U S U _ _ ` _  ^ f q e Z ` S
S X  \ Z ` X Z e S ` %
U S c Y
 U S ` ' ^ p Z  U S `
q q S ^ U X  )   " - G  &  6 D 9
m  & & 6 H * Q B + - Q #
'
&   #    
 i 
 4 6  7 " #

 +  *  m  &  B * #  & 2 ;  J 
$
  Y
Z ` S X ^   ` X Z \ ^  - ` Z  ^ S / %
   \  ` ` S \  

q q S ^ U X  )   " - G  &  6 D m  & & 6 H * Q B 9

+ - Q #
'
&   #     
    


6 P 7  #    + H + - #  & 2    "  -
@
 

+ 9
2 6  & G  + m " -
@
 -  0 

+ … 6 - + m + & 7 Q D " -

  *  H * + 4 - +  7 " -
@
9   Q + 2    B +  " B + - 9
+ &  +

 B + m + Q    S ^ X    Z  _  ^  p ` S `  X `
^   U S U _ _ ` _  S ^ X ` \         2 4  # P  G + Q
     #  6 G 6 Q 7    
   ; 


 + & &  P    * P B    v 7 "   Q +  + m 9
" -
@
 " 7 7 * + & +     \ X S ^ q S ^ X ` ^ S  ` q ^ S Z #
 g v h     #
"
 7 " H + -    
     6 G B + Q # 7   # 

 & G  &  7 B 
& #  & 2

  2 = +  
  '
 

m 6 *  7 & G

B  - + 2 9
 + m " -
@
 6 * 7 P - "  + Q Q " - Q  7 B
'
; - " 9
 + Q Q " - Q     ^ f q e Z ` S #   g  h # ! + H - 6 9
 -
@
    
 
 ;  6 2 " &  & 2 4  ; + & " Q
@
   B +

' "
- 9
G &     9 J L   G B *
@

  *  H * +

+ - = 9
+ -    S ^ X  ^ p Z  `   Z    Z  _  f q ^ \ e f ^ 
 ^ f q e Z ` S
S X  \ Z ` X Z e S `   
 2   # P  G + Q
 v    #
6 & +   i 
  



  6 B + - ‰ + +  & 2   4  * *    &  =  * 6 9
 7 " & " D 4 - +  7 " -
@
- " 7 "  " * Q D " -  + 2 6 m 9

  * +

B  - + 2 9  + m " -
@
 6 * 7 P - "  + Q Q " - Q  
 S ^ X  ^ p Z  `  Z    Z  _  ^  p ` S `  X ` ^  e Y
q ` S X ^ f q e Z \       2   # P  G + Q v  i v #
6 *
@
  v 
      J  & 2  #   J G 6
@
+ & #       B  + * #
 & 2 4 

" Q + P B   G B 9  B - " 6 G B " 6 7  " 9
B + - + &  +  " & 7 - " *  & 2  - 2   - +  + Q Q  G & G
&  = + - + Q 7    A  C ^ e S  U _ ^ p  ` ` U S X  U  c
 ` Š ` _ ^ q f `  Z # v  g  h       v v #   -  B    
 v   
" D
-  D   & 2   J +  7 " &    &
 m P -   *  =  * 6  7 " & " D   "  + m " -
@
9
 0  + & 7 4 - +  7 " -
@
 + 7 B " 2 Q    S ^ X  ^ p Z  `
 Z    Z   f q ^ \ e f ^   ^ f q e Z ` S
S X  \ Y
Z ` X Z e S `   
 2 4  # P  G + Q    v i #
6 & +
   
    

" Q #         " #  & 2
  


 -  /    
J " = + * ; G B 7  + G B 7 4 - +  7 " -
@
 -  B 7 +  7 6 - +
D " -

  *  H * +

B  - + 2 9  + m " -
@
 6 * 7 P - "  + Q 9
Q " - Q    ^ U q q ` U S \   S ^ X  ^ p e S ^ Y  U S #
 6 G 6 Q 7     
 



m " & 
$
 U X  `  ^  ` S `  X `  \ S ` X Z ^ S \ `
p ^ S X U _ U d _ `  e _ Z \ q S ^ X ` ^ S )  B 4 7 B + Q Q #

7  & D " - 2 L & = + - Q 7
@
#    
 i 

    " " #  
"
B  -  #    " - - + #
 

& G B #  & 2  


6 P 7     B +

; 

9 
- " G -  m Q   B  -   7 + - '  7 " &  & 2  + 7 B " 2 9
" * " G   *  " & Q 2 + -  7 " & Q    S ^ X  ^ p Z  `
   c   Z  _  f q ^ \ e f ^   ^ f q e Z ` S
S Y
X  \ Z ` X Z e S `   
 2   # P  G + Q  v   #
6 & +
   
98 Arquitectura del Procesador y Multiprocesadores
Redes y Comunicación
                     !   !     !           
 ) +       )     2 4 6 8 :     )     )     ! > ) !   
? A C E G H I J K M J K O P K R S G H U C A V X ? P G P Z K \ ] K ^ _ S X b G J P d G
e f g i k m i n f p m r s f t p v f p x f k z i | } f ~ p r  r v z i s f € r n g  m i s r k f „
… p x † f k „ x s i s s f ‡  k ~ x i
‰ Š Š ‹ Š
‡  k ~ x i Œ Ž „ g i  i 
f ‘ n i x  ’ “ ” • – “ ˜ ™ š › › š › œ  › ž Ÿ   “ ¡ ” ¢  ›   ¤   • “  “  ¡ › ¥ –   Ÿ “ š  ¡ “ § ž ™ ¡ ¨ •  ¢ ª   ¢ • «
¬ ® ¯ ° ± ® ²
³ µ · ¸ º » ¼ ½ ¾ µ ½ ¿ º ¼ » À Á ¿ ¸ ¾ Ã ¿ Á » Å ¸ Ç Á ½ · º ¼ » È ¿ Å ¾ É
à » ¼ ¿ Å È » µ ¸ ¿ ¸ » ¼ · ¾ È » ¸ º ¾ ¼ ½ · à ¾ É Ã · Å ½ ¼ · À Ç · à ¾ Î
¿ Å Ï Ç ¿ ¸ ¾ Å Ã ¿ È » Ð ¿ ¼ ¿ µ È · ¾ À ¾ Å ¾ Ã » Å ¿ µ Ç µ ¾ ¿ Å ½ ¼ Ç È É
½ Ç ¼ ¾ Ã ¿ Ã · ¼ ¿ È ½ » ¼ · » È » ¸ º ¼ · ¸ · Ã » ¿ Å Á ¾ ¿ µ » ¼ ¸ ¿ Å » É
À ¼ ¿ È ¾ ¼ Ñ ¾ ¿ µ ½ · ¿ ¸ º » Ï Ç ¿ Å Ç º » µ ¿ Á ¾ È ¼ ¿ ¾ È · Ó µ Î ¿ Á
¿ µ Õ Ö » Ã ¿ ¸ ¿ µ Å ¾ × ¿ Å Ã ¿ È » Ð ¿ ¼ ¿ µ È · ¾ · µ µ ¿ È ¿ Å ¾ ¼ · » Å Ø
Ù µ ¿ Å ½ ¿ ¾ ¼ ½ Ö È Ç Á » Å ¿ ¿ Õ ¾ Á Ú ¾ µ Ã » Å ½ Û È µ · È ¾ Å Ã ¿ ¿ µ É
¼ Ç ½ ¾ ¸ · ¿ µ ½ » ¸ Ç Á ½ · Ã ¿ Å ½ · µ » Ü Á Á ¾ ¸ ¾ Ã ¾ Å Þ ß à á â ã ä å á æ
Î å ç è é ç ê ë ì ê ç á â í å à Ü Ï Ç ¿ ¼ ¿ Ã Ç È ¿ µ ¿ Á ½ ¼ ï ð È » Ã ¿ Á ¾
¼ ¿ Ã Î Á ¾ Å » À ¼ ¿ È ¾ ¼ Ñ ¾ Ï Ç ¿ Å Ç º » µ ¿ ¾ Á Ã · ¼ ¿ È ½ » ¼ · » Á ¾
È ¼ ¿ ¾ È · Ó µ Ã ¿ ¿ ñ È ¿ Å · Õ » Å ¸ ¿ µ Å ¾ × ¿ Å Ã ¿ È » Ð ¿ ¼ ¿ µ È · ¾ Ø
ò ó õ
² ö ÷ ø ù ° ú ú û ü ²
ý ¾ ½ ¿ µ Ã ¿ µ È · ¾ ¾ È ½ Ç ¾ Á ¿ µ ¸ Ç Á ½ · º ¼ » È ¿ Å ¾ Ã » ¼ ¿ Å Ã ¿
¸ ¿ ¸ » ¼ · ¾ È » ¸ º ¾ ¼ ½ · Ã ¾ ¿ Å È ¾ Á ¾ À Á ¿ Å Å » µ Á ¾ Å ¾ ¼ Ï Ç · É
½ ¿ È ½ Ç ¼ ¾ Å È È É
³   Ü Ï Ç ¿ Å ¿ À ¾ Å ¾ µ ¿ µ Ç µ ¾ ¼ ¿ Ã Ã ¿
· µ ½ ¿ ¼ È » µ ¿ ñ · Ó µ ¿ Å È ¾ Á ¾ À Á ¿ º Ç µ ½ » ¾ º Ç µ ½ »   Ü Ã » µ É
à ¿ Á ¾ ¸ ¿ ¸ » ¼ · ¾ º ¼ · µ È · º ¾ Á ¿ Å ½ ï  Ö Å · È ¾ ¸ ¿ µ ½ ¿ à · Å É
½ ¼ · À Ç · Ã ¾ º ¾ ¼ ¾ Ñ ¾ ¼ ¾ µ ½ · ¾ ¼ Ï Ç ¿ ¿ Á ¾ µ È Ð » Ã ¿ À ¾ µ Ã ¾
à ¿ ¸ ¿ ¸ » ¼ · ¾ ¿ Å È ¾ Á ¾ Ø  · µ ¿ ¸ À ¾ ¼ Ñ » Ü ¿ Å ½ » Å ¸ Ç Á ½ · É
º ¼ » È ¿ Å ¾ Ã » ¼ ¿ Å Å ¿ ½ · ¿ µ ¿ µ Ï Ç ¿ ¿ µ  ¼ ¿ µ ½ ¾ ¼ ¾ Á º ¼ » À Á ¿ É
¸ ¾ Ã ¿ Á ¾ Å » À ¼ ¿ È ¾ ¼ Ñ ¾ Ã ¿ ¸ ¿ ¸ » ¼ · ¾ Ï Ç ¿ · µ ½ ¼ » Ã Ç É
È ¿ Á ¾ ¿ Å ½ ¼ Ç È ½ Ç ¼ ¾ Ã ¿ Ã · ¼ ¿ È ½ » ¼ · » Ü µ ¿ È ¿ Å ¾ ¼ · ¾ º ¾ ¼ ¾
Ñ ¾ ¼ ¾ µ ½ · ¾ ¼ Á ¾ È » Ð ¿ ¼ ¿ µ È · ¾ Ã ¿ Á ¾ Å È ¾ È Ð ¿ Å Ø  · Ï Ç ¿ É
¼ ¿ ¸ » Å Ç µ Å · Å ½ ¿ ¸ ¾ ¿ Å È ¾ Á ¾ À Á ¿ Å ¿ ¼ ï µ ¿ È ¿ Å ¾ ¼ · ¾ Á ¾
· µ ½ ¼ » Ã Ç È È · Ó µ Ã ¿ Ã · ¼ ¿ È ½ » ¼ · » Å È » ¸ º ¼ · ¸ · Ã » Å Ü È » µ
Á » Å Ï Ç ¿ È » µ Å ¿ Ñ Ç · ¸ » Å ¼ ¿ Ã Ç È · ¼ ¿ Á ½ ¾ ¸ ¾  » Ã ¿ Á ¾
¿ Å ½ ¼ Ç È ½ Ç ¼ ¾ Ã ¿ Ã · ¼ ¿ È ½ » ¼ · » ¾ È » Å ½ ¾ Ã ¿ º ¿ ¼ Ã ¿ ¼ · µ É
 » ¼ ¸ ¾ È · Ó µ ¾ È ¿ ¼ È ¾ Ã ¿ Á » Å È » ¸ º ¾ ¼ ½ · Ã » ¼ ¿ Å Ã ¿ È ¾ Ã ¾
Á Ö µ ¿ ¾ Ã ¿ ¸ ¿ ¸ » ¼ · ¾ Ø Ù Å ½ ¾ º Û ¼ Ã · Ã ¾ Ã ¿ · µ  » ¼ ¸ ¾ É
È · Ó µ º ¼ » Õ » È ¾ ¼ ï Ç µ ¾ Å » À ¼ ¿ È ¾ ¼ Ñ ¾ ¿ µ ½ Û ¼ ¸ · µ » Å Ã ¿
½ · ¿ ¸ º » Ã ¿ ¿ × ¿ È Ç È · Ó µ Ü ½ ¾ µ ½ » ¿ µ ¿ Á Ã · ¼ ¿ È ½ » ¼ · »  ¾
Á ¾ Ð » ¼ ¾ Ã ¿ È ¼ ¿ ¾ ¼ Á » Å ¸ ¿ µ Å ¾ × ¿ Å Ã ¿ È » Ð ¿ ¼ ¿ µ È · ¾  Ü
 x v  k i  ’     n i g  k f p m f i s x k ~ r n g k x n x s r „ 
È » ¸ » ¿ µ Á ¾ ¼ ¿ Ã  Ï Ç ¿ ½ ¿ µ Ã ¼ ï Ï Ç ¿ Å » º » ¼ ½ ¾ ¼ ½ » Ã »
¿ Á ½ ¼ ï ð È » ¿ ñ ½ ¼ ¾  Ø Ù µ Á ¾ ð Ñ Ç ¼ ¾ ! º » Ã ¿ ¸ » Å Õ ¿ ¼ ¿ Á
¿  ¿ È ½ » Ï Ç ¿ ½ · ¿ µ ¿ Á ¾ Ç ½ · Á · ¾ È · Ó µ Ã ¿ Ã » Å È Ó Ã · Ñ » Å Ã ¿
È » ¸ º ¾ ¼ ½ · È · Ó µ È » ¸ º ¼ · ¸ · Ã » Å È » ¸ » è â $ å ç & á ç ê ê Î
è â $ å ç & á ç ê ê ( â á æ ) ß è á ç ê ê )  + Å » À ¼ ¿ ¿ Á ½ · ¿ ¸ º » Ã ¿
¿ × ¿ È Ç È · Ó µ Ø - » µ ¿ Á ð µ Ã ¿ ¼ ¿ Ã Ç È · ¼ Á ¾ º ¿ µ ¾ Á · ¾ È · Ó µ
º ¼ » Õ » È ¾ Ã ¾ º » ¼ ¿ Á Ç Å » Ã ¿ ¿ Å Ï Ç ¿ ¸ ¾ Å Ã ¿ Ã · ¼ ¿ È ½ » ¼ · »
È » ¸ º ¼ · ¸ · Ã » Å Ü Ð ¿ ¸ » Å Ã · Å ¿  ¾ Ã » ¿ · ¸ º Á ¿ ¸ ¿ µ ½ ¾ Ã »
à » Å ½ Û È µ · È ¾ Å Ã ¿ ¿ µ ¼ Ç ½ ¾ ¸ · ¿ µ ½ » ¸ Ç Á ½ · à ¿ Å ½ · µ » Ø ý ¾
º ¼ · ¸ ¿ ¼ ¾ ¿ Å ½ ï À ¾ Å ¾ Ã ¾ ¿ µ ¿ Á È » µ È ¿ º ½ » Ã ¿ È ¾ ¸ · É
µ » Ü Î Å ¿ È » µ » È ¿ È » ¸ » ¿ µ ¼ Ç ½ ¾ ¸ · ¿ µ ½ » Þ ß à á â ã ä å á æ
 0 Ø  Á ¾ » ½ ¼ ¾ ½ Û È µ · È ¾ Á ¾ Ð ¿ ¸ » Å Á Á ¾ ¸ ¾ Ã » ¿ µ ¼ Ç ½ ¾ É
¸ · ¿ µ ½ » å ç è é ç ê ë ì ê ç á â í å à Î ¿ Å Ç µ ¾ · Ã ¿ ¾ » ¼ · Ñ · µ ¾ Á
à ¿ ¿ Å ½ ¿ ½ ¼ ¾ À ¾ × » Ï Ç ¿ Å ¿ À ¾ Å ¾ ¿ µ ¿ Á È » µ È ¿ º ½ » à ¿
¿ µ ¼ Ç ½ ¾ ¸ · ¿ µ ½ » ¾ ¼ À Ó ¼ ¿ » Ø
1 ó 3
÷ 5 7 5 9 ø ÷ ® ; 5 ú û ø ² 5 ù ø
Ù Á ½ ¼ ¾ À ¾ × » ¼ ¿ Á ¾ È · » µ ¾ Ã » Á » Ã · Õ · Ã · ¸ » Å ¿ µ Ã » Å º ¾ ¼ É
½ ¿ Å Ü Á » ¼ ¿ Á ¾ ½ · Õ » ¾ Á » Å È Ó Ã · Ñ » Å Ã ¿ È » ¸ º ¾ ¼ ½ · È · Ó µ
È » ¸ º ¼ · ¸ · Ã » Å Ü Î Á » ¼ ¿ Á ¾ ½ · Õ » ¾ Á ¾ Å ½ Û È µ · È ¾ Å Ã ¿ ¿ µ É
È ¾ ¸ · µ ¾ ¸ · ¿ µ ½ » ¸ Ç Á ½ · Ã ¿ Å ½ · µ » Ø
= ? A ? D E F G H I J F L N I P R S T U G N G E V N I P R T G P G Y
F I J
Z ¾ ¼ ¾ ¼ ¿ Ã Ç È · ¼ ¿ Á ½ ¾ ¸ ¾  » Ã ¿ Á Ã · ¼ ¿ È ½ » ¼ · » Å ¿ Ç Å ¾
Ç µ ¾ ¼ ¿ º ¼ ¿ Å ¿ µ ½ ¾ È · Ó µ È » ¸ º ¼ · ¸ · Ã ¾ Ã ¿ Á » Å È » ¸ º ¾ ¼ É
                       !      
$ & ' )  + - + $ . & ) 1 ) '  3 . ) 6  . ' . +  : & ; +  >   @    B
    E     H                   
       E  K          !       !  B
          !   Q  K    K         
 S 
      T     U      W            
           1 W  !         W     !    B
      1 E       U     1 W     Q   
        Q  K     W            B
                 H      d          
 !  W       $ f g  . + )             1 E
                  !       i    Q 
 !  W                      i  E
   H    W                    
    !        m                    B
    U   U     i      i      U          B
!      U  
• 
6  ' )  . ) + +      U         !      U 
  E    !    1 W             i B
     ! @       !      U  W      B
   
• 
6  ' )  . ) + +  6 . :  g r . ) + +              
 T         r 6  ' )  . ) + +         
                       
            !  # $ !   %
&      i             !    (

• 
 ) g . ' ; 6 +  . & ' ) r u ) + &   ) + + 3

'  +  ; g f . 6 3
$ '  .  & g . 6 

               B
               i @          
   Q      !    K  1 !      !  @   !     
      E   i          !   !    
                 
• 
 ) g . ' ; 6 +  . & r '  '  & +  $ ' ; 6  &    ' . : 3

'  +  ; g f . 6  +  . 6  &  & g . 6 

   i  
             i            W 
  Q                          
>    !    # g f . 6 3  ' . :  *

% x '
y , z { | } ~ z {  €  €  y  ) ‚ € z €  € , € | }
 € * } ‚ }   { . / . ~ . | € }  | { ‚ }  z € ‚ { € ~
d   @                           
   !      Q                      
      1 W  !             : & ; +  B
                    i                 
 d   &        i       @        
     
         d  !               Q      B
                            1 E  
           !                   B
  
+  0  2 3 $    4  # $  % 7 $   , $ 7   !  # $ !   %
  H                          
           W    i          Q ‡    
       K                       B
     S        K    U             H  
 K         Q        W  W      i  B
                             
       !          @             B
      i    U   Q    i      Q     K    B
1      !   i     T      
/ / /
/ / /
/ / /
/ / /
1 1
1 1
1 1
1 1
2 2 2
2 2 2
2 2 2
3 3
3 3
3 3
Arboreo vertical
Area 1
Area 2
Area 3
Area 4
Home
4 4 4
4 4 4
4 4 4
4 4 4
5 5 5
5 5 5
5 5 5
5 5 5
Multi−path
< ˆ ‰ Š ‹ Œ 7  9 ˆ Ž Š Œ  ˆ ;  ‘ ’ “ Œ ” = ‹ ’ Œ ” =
S    T     (                W  H 
               !                
!             ; g f . 6 3 • ' . :  d         B
 
DH
E
DL
                  W   
  E   E     W                 !  B
 i       i  1                 
  i           !     W      >
DH1
E
DL1
?
E    !      H  >
DH2
E
DL2
?  ?      
                          !   
        !             K         1 E
  i           U    !          
S          !           U        B
    !             ' ) r u ) + & - + ) . 6 $ ' f  
!      i     T     A  d          
DH
E
DL
                
Y
  E   E  B
   W                 !   i    
d              !       
DE1
E
DE2
               W             B
         T   W         >      B
    U     !                Q m   1 E 
W        !    Q    !         i    @  B
                   >   !    K    B
    U           i                 K B
!    1 W  !           Q            
102 Redes y Comunicación
    
             
    "   &         + 
    - / 0 1 3 5 7 8 1 9 :
;
     = > ? @ B ? D > D > D G H I J I J L D M ? > L
D N
I M O J P P M Q ? I J H ? > I > > O M T J ?
u0 = (x0, y0)N U
L B J D M W B J D G
l(u0)X
Y      Z P > ? @ B ? D > L > O I J ? G I > L I J I J L D M ? > L
DH1 N DH2 N DL1 N DL2 X
^
     
   
`
X b
M c M I M O
D
J ?
DH d
P > ? D J ? M J ? I > H > L ? > I > L P > ? J D M W B J D G
l f
G
U
> O W B J
l(u0)g U DL d
H > L ? > I > L P > ?
l f
J ? > O W B J
l(u0)g X
i
X b
M c M I M O
DH
J ? I > L L B j P > ? @ B ? D > L
DH1 U DH2 k
DH1 = {(x, y) | x < x0}
DH2 = {(x, y) | x ≥ x0}
l
X m
j D J ? J O
DL1 U DL2
I J n > O
f
G J W B M c G H J ? D J G
DH1 U DH2 X
Z
X m
O I J ? G O H G L P B G D O > H M L D G L J ?
X N
L M T B M J ? I > B ? > O I J ? P O J P M J ? D J O J L p J P D > G H G I M L D G ? P M G G
u0 X q
M J r M L D J ? p B ? D > L P > ?
P > > O I J ? G I G
X
M T B G H
N
L J H J P P M > ? G O p O M
f
J O > G W B J H ? > I >
f t
L p O Q r M
f
> G H u H D M
f
> ? > I > I J H G P > H B
f
? G G ? D J O M > O
N
p G O G
P > ? D M ? B G O P > ? B ? > O I J ? H M ? J G H P > ? J H O J L D > I J I J L D M ? > L I J J L G P > H B
f
? G
X
v
X
= > ? L D O B M O H > L
f
J ? L G @ J L W B J P > ? D J ? T G ? H G L H M L D G L P >
f
> p G O D J I J H G P G j J P J O G
N U
J ? c M G O H > L G H ? > I > L M D B G I > J ? H G
p O M
f
J O G p > L M P M Q ? I J H G H M L D G
X

  

 {   
        
;        |   !        
    } ~  €  ‚ ƒ „ € … 
    
             
    "   &         + 
    8 † ‡ ˆ † ‰ Š ‹ ‰ † 1 3 Œ 8 0 :
;
     = > ? @ B ? D > D > D G H I J I J L D M ? > L
D N
I M O J P P M Q ? I J H ? > I > > O M T J ?
u0 = (x0, y0)X
Y      Z P > ? @ B ? D > L > O I J ? G I > L I J I J L D M ? > L
DH N DL N DE1 N DE2 X
^
     
   
`
X b
M c M I M O J H P > ? @ B ? D >
D
J ? D O J L L B j P > ? @ B ? D > L
DH N DL U DE
I J H G L M T B M J ? D J n > O
f
G
k
DH = {(x, y) | y > y0}
DL = {(x, y) | y < y0}
DE = {(x, y) | y = y0}
i
X b
M c M I M O
DE
J ? I > L L B j P > ? @ B ? D > L
DE1 U DE2 k
DE1 = {(x, y) | x < xe, ∀(xe, ye) ∈ DE}
DE2 = {(x, y) | x ≥ xe, ∀(xe, ye) ∈ DE}
l
X
= > ? L D O B M O J H
f
J ? L G @ J W B J P > ? D J ? T G
DH
P >
f
> p G O D J I J H G P G j J P J O G
N U
J ? c M G O H > p > O J H P G ? G H I J L G H M I G L B p J O M > O
X
Z
X
= > ? L D O B M O J H
f
J ? L G @ J W B J P > ? D J ? T G
DL
P >
f
> p G O D J I J H G P G j J P J O G
N U
J ? c M G O H > p > O J H P G ? G H I J L G H M I G M ? n J O M > O
X
v
X
= > ? L D O B M O J H
f
J ? L G @ J W B J P > ? D J ? T G
DE1
P >
f
> p G O D J I J H G P G j J P J O G
N U
J ? c M G O H > p > O J H P G ? G H I J L G H M I G M  W B M J O I >
X
Ž
X
= > ? L D O B M O J H
f
J ? L G @ J W B J P > ? D J ? T G
DE2
P >
f
> p G O D J I J H G P G j J P J O G
N U
J ? c M G O H > p > O J H P G ? G H I J L G H M I G I J O J P  >
X

     {   
        
;        |   !        
    „ ’ “ ” ’ • – ˜ • ’ €  ™ „  
    

^
     
         + 
    - / 0 1 3 5 7 8 1 9 :
;
     š J ? L G @ J P > ? B ? G H M L D G I J I J L D M ? > L > O I J ? G I G
DM = {d1, d2, . . . , dk}N U
B ? G I M O J P P M Q ? H > P G H
wX
^
     
   
`
X q
M
w = d1
J ? D > ? P J L
D

M
= DM − {d1}N
J ? c M
t
? I > L J P > p M G I J H
f
J ? L G @ J G
wX
q
M ? >
D

M = DM X
i
X q
M
D

M
= ∅
J ? D > ? P J L › ? I J D O G ? L
f
M L M Q ? I J H
f
J ? L G @ J
X
l
X q
J G
d
J H p O M
f
J O ? > I > I J
D

M
U w

= R(w, d)X
Z
X œ
H
f
J ? L G @ J J L J ? c M G I > G
w
P > ? H G H M L D G I J I J L D M ? > L
D

M
J ? L B P G j J P J O G
X

     {   
          
    } ~  €  ‚ ƒ „ € … 
    

^
     
         + 
    8 † ‡ ˆ † ‰ Š ‹ ‰ † 1 3 Œ 8 0 :
;
     š J ? L G @ J P > ? B ? G H M L D G I J I J L D M ? > L
DM = {d1, d2, . . . , dk}N U
B ? G I M O J P P M Q ? H > P G H
wX
^
     
   
`
X q
M
∃di ∈ DM tq w = di
J ? D > ? P J L
DM1 = DM − {di}N
J ? c M
t
? I > L J P > p M G I J H
f
J ? L G @ J G
wX
q
M ? >
DM1 = DM X
i
X ∀di ∈ DM1 tq y(di) = y(w) ∧ x(di) < x(w)
J ? D > ? P J L
DM1 = DM1− {di}N U DM2 = DM2+ {di}X
l
X ∀di ∈ DM1 tq y(di) = y(w) ∧ x(di) > x(w)
J ? D > ? P J L
DM1 = DM1− {di}N U DM3 = DM3+ {di}X
Z
X q
M
DMX = ∅
p G O G
X = 1, 2, 3N
J ? D > ? P J L › ? I J D O G ? L
f
M L M Q ? I J H
f
J ? L G @ J
DMX X
v
X œ
? c M G O J H
f
J ? L G @ J P > ? H G H M L D G
DM1
J ? L B P G j J P J O G p > O J H P G ? G H I J L G H M I G W B J L M T B J H G I M O J P P M Q ?
U
L J ? D M I > I J H
f
J ? L G @ J
DM X
Ž
X œ
? c M G O J H
f
J ? L G @ J P > ? H G H M L D G
DM2
J ? L B P G j J P J O G p > O J H P G ? G H I J L G H M I G M  W B M J O I >
X
Ÿ
X œ
? c M G O J H
f
J ? L G @ J P > ? H G H M L D G
DM3
J ? L B P G j J P J O G p > O J H P G ? G H I J L G H M I G I J O J P  >
X

      {   
          
    „ ’ “ ” ’ • – ˜ • ’ €  ™ „  
XVI Jornadas de Paralelismo, JP '2005 103
   
                        
      $
 
     
              -   /

    2   3 
            
   
      2           ;
   $ =    
 
 2  
@ 2       
 2       
  
 -    / B           2   3   E     
      $
=  @ 2 
           2            -
   2 
;

  
  
 2  
      N 
E  E          /
     

    
  
        

 
  
  
P  2    3      
 2  
                 ;
 
 

                         2    ;
  
    W      
        / B            
         2             2                

 2  
   N   2        /  2     2        
 2                 2         $       -   @ 2 
 
 2  
     @ 2    N  
2              ;
    W      
        / B    \  2
       
N 
     
    @ 2  2  
E  
 2  
 
     ;
   
 

                    ] ^ _ ` a b c d ` e /
B            
2         d f g h f i j k i f ` a m d _
  
 -      
 2  
         
E       ;
 
                 
      =    
@ 2 

 
N 
           2         -      
;
    
 2          / !    E  $ W  -
E @ 2        ;
 2 
  
  @ 2              @ 2   2      

          
  
                    =
 @ 2       
    @ 2        
E  
     
;
 2         / B               - 
         ;
  N              
  @ 2    
        ;
  $ =  @ 2  2         @ 2         
 W 
 ;

              
E  

         
N 
  
       $     
  @ 2             @ 2       ;
  
  N 
             
E  / B      
  ;
     3                 2    3         
 
  @ 2    
  $       \       -         
             
 2  
$   @ 2         2    ;
 
     W 
  
 = 2     = 
N          
 
2         / B    \  2
         N 
 
   
     E           /
 r 
s t u
v # v u s w x y z x # % u  # t # y
B     2    
        
      

        
 {        2           =  2  N   2    3  W     
2   N 
  3            &  ' (  ) @ 2      2 = 
N 
     @ 2        
   
   / &  -
     N 
;
  3    &  '   W  
   
       \        
     3     2      
   

@ 2           
    {        2           =      

 N   2 
;
   / B         \            W          \    
• 
a f i m ` j f a j   
 
2             W  ;

      2           $ 
  
           ;
    @ 2                     2        
@ 2            2         2  
 E
  
  \       
 2   
     
     + \  2

, - / !       2    3 
 
   
          ;
      
       
    - 
  
 2  
/
•

j ^ ` i f  2     2               
 2  

     
 - 
E   {                   ;
    $    2 =        N  
    2       
W          W  P , / !       2    3         ;
      
    3         2             
=  
   N            
             ;
      2    / B            
2        
d f g h f i j k i f ` a m d _ $       -   @ 2  W  =  @ 2 

     
          
N 
           
      $   N            2              /
• 
. ` d   . ` a m d .  
  -    
             
  
  2            
                
       
  2              W   P , $ @ 2 
    
          N  

 
  
 2  

=    
   
         e j ] i /
 r  
# %  # v u ‚ w  z x y  % ƒ # t s y
  1     5   7 5  9        

 5

 
„    
    2   
@ 2      2
   ; < „ ' !   

           W 
     
 !
$      @ 2    
   W      
E                     
  ;
  3    -
             @ 2       2   
  /
B              
!
= k # _ a  j $ % j ] c d f ` a  j $
 '
b
m _ ^ . a k j =  j  a ( m d  j / „        P , 
 N   
E
2         3     
   
         e j ] i @ 2 
 -    
E                            ;

  $                  
   
  / B      
       i . ` d  j  i  a f i m ` j f a j   
E    

 
N   
  * = m d m e i  $ e d f i    f a k d ` i /      ;
                            
  =
               3         W  P , +     2
 
  
  2
 - $ N           \  
          P ,
   2  
      
     2                 
 †  2       ( ? )
• +
d _ _ j . - b ` j b -   
  2     2          
   @ 2               2   
        
104 Redes y Comunicación

                    ! "  " %      ( 
"  %   %    "       "  !   " 1 3 5  " 7 5 

  ! " 5  "   7 % 5  7  "     "  !   "       " A
B     "      %        "    F 5  B   7 " H 
     I  B "   (  "               L M N 
• +
 O O   N M N M
   % 5     " % "      "   
5  " %      (        5  "   7     5  "     A
        "       V " B  B    " % "  "    " 
 "  !   " "  %        "    
• +
 O O   N     O    Y  [   7  %    5    %  
5  "    7     7     5  " " 5  "  !   "   B  A
B    "   B % "     " 1 7            %       A
 "    5       7   B % "        7        A
        "  V B   7 " H  7     "    "   (  "
    7   7   B % "        7  b   %   "  3 5 
  "  
(  " %      (   d  " 
3 5  f " F "     A
g        7   7 B   7 " H  7           B    A
   " 

1 %    V     I  "  "  %        "    7 5
       (    %   %    "    
• +
 O O      O    Y  [   M N M
   7  B   "  "
  7  "    7     "    "   (  1 %    "   B V 7  
               V 3 5       j "     "    
B  B    " "      %        "    
                   !  " #
k "  "  5 "   (      7   7 5   "   7 f " 7      "  
" A
 " 7  B 5  "    5     H 5      g    f B " 
7  
5  " B V 3 5   " B 5    %     7 "        " 7  "  "  A
   ! 7    " 7 3 5  7  B 5  7   "     "  " g  " %  &  
B     7   g     "  7 (   B  7   "   B  7   7   A
7 5   "   7  g       7 % "  "     F        1
3 5     7     " B  7   %   7    "    7       H 5  A
     "    g    f B " 
7  & "  "     7   7 5   " A
  7 % "  " 5     H 5      g    f B " 
7 B " F   1
  (  )  & "  "  g       "   7    "    7 "     A
     7  7   5   5  " 7             1 7  f "  %  "  
%     7  7 3 5  B " 7  q O O M  r 1 s   
, t
N N F s   
,
t
N N .  t L  q s t
N N   & "  "  "  " 5      7   7  7 A
3 5  B " 7 1 7  f "   g         7 5   "   7 % "  "  " 7
 v     " 7      5  " B      q   Y   t 1 M q O t  w r  t L
F 
s [
N  N
t  Y  O 

        
k  7   7 5   "   7 7   "  5 "    7     7 % 5    7  
 7  " 

               
   
!
     !   $ %    ' !  %
( # %
)
&
! ' !
* +
, 
*
! ' ) + - . / 1 ) + 3 1 ) -

         
0  
 4 1 5
       5

&
!
*
! 7    !  8 7  !   !  : 
;
- <
=
>  '
? !  :  :
(
A ;
1 3 + ) = + . 1 @ B D .
E
&
!
*
! 7 
B C F H
E J
'    ! >  D  ! E ! $    %   > 
E
&
 
*
$   !    % > 
C
     '
? !  :  :
C
A ;
1 3 + ) = L M - N
E
&
!
*
! 7 
J ( C F H
E J
'    ! >  D  ! - O D 8 ! '
E
&
 
*
$   !    % > 
( J
     '
L
; Q S
M N
'  O
*
 7 > ! 
&
 
*
$   !    '  !
*

*
 %  !
; T
     '
#
% !    7 >  %  !  !  
*

*
 %  ! -
U
%  >         :  %  7   !   !  :  E
Q S V
E        7 '  ' >  7   !
S
  U  7   ! 
?       %   >  %  
( T
     '
&
 
*
$  '   %  !   X 7 
*
 7 ' ! Y  '
   :  %  7   !
A
E
U
% 
*
 %
*
 7 ' ! Y     :  %  7   ! -      '   %
[
E
S
 O U   7 >  '
*
 7 ' ! Y  '
C
     '   %
[
!
     !   < U '
( # %
)
J
7  :    < U ' W <
=
>  '

         Y  
&
 $    O 8 ! E !   !
!
     !   1 @ B + ) 1
C J T
E
%
)
J
7  :   < ! 7 !    ! 7 ! 
B C
<  > '
!
     !    ! 7 ! 
J T T
E
%
)
[
\
*
 %    ! 7 !   '
(
&
!
*
! 7    \ 3 + W <
=
>  '
&
!
*
! 7  
*
 7 ' ! Y  '  7 ! >  '
( ;
<
=
>  '
J
7  :    ]  U >  %  7 >  % 7    < U '
;
- <  > '
]  > ! %   ! % <  > % ! Y  -      '   %  U >  %
0 5 "    %  & "  V B     7 g V 7    7    7  7   B " 
•
k  7    B %  7 B     7     7 "    7 % "  "  "   A
7   5   (     "  " 5       7   %  7    "    7
   "  "  f  k 2 1   7 j   7 "   7            7
 " 7  7  7   7    B %  7 7    I      b   5 7  " A
B     "   7  "    7    "  f      %  , w t w
, 1     O    Y  [       O    Y  [   M N M
  
_
5   "   b   5    7   7  "    7   M N M
 
   7  " 7  7  "  ! 7    " 7 1 F " 3 5    %    5   
    !    B   7 " H  7     f       "      A
j y    %  
•
k " 7 "   "      7 %    5    " 7        B % 
   H   5   (  I  "     " 7 " %    "      7 
` a c a d a g i j k l m l m o p r l p t u v m u w x w k v m o l {
|
p x p i r p m r l u v m o p
|
w k k v m o p ƒ …
 %     7  %    5     %   5   "       "  f  k 2
  %    B  7         4  " 7  7   %   B    5 j " 
 7  V      B %  3 5  % " 7 "  " %      (     "   
  7   3 5  " g "     "       %        "    f " 7  "
3 5     j " "      L M N F      7 " 1 F   f  B  7
XVI Jornadas de Paralelismo, JP '2005 105

  

               

    #  
  
   
    
   
  
  
' ' ) * ) , . / 0 1 * 3 . , 1 7 9  : ; ' / 0 1 * 3 . , 1 ? @ @ 9  B 1 D
1 ' F H 1 3 ) D ) ' ) 3 1 / 0 J 0 K L 1 L ' ) J . ' ) , 1 ' , 0 M 1 J / . M 0 .
N ) D / ) F H 1 1 D 3 M . J 1 D ) , ) : ; ' , 1 @ 7 9 ? @ U W  1 D 1 '
F H 1 L 1 J 1 D 0 / ) 1 ' , 0 M 1 J / . M 0 . 3 ) M ) J M 1 ) M / . , . D ' . D
* 1 L D ) \ 1 D , 1 J . N 1 M 1 L J 0 ) : ; ' / 0 1 * 3 . , 1 9  ]  B 1 D
1 ' F H 1 / M ) L D J H M M 1 , 1 D , 1 F H 1 D 1 1 L c d ) 1 ' f ' / 0 g
* . * 1 L D ) \ 1 , 1 J . N 1 M 1 L J 0 ) N ) D / ) F H 1 D 1 M 1 J 0 i 1
' ) f ' / 0 * ) J . L / 1 D / ) J 0 K L :  . M f ' / 0 * . l 1 ' / 0 1 * 3 .
m U  @ 9 n "  9 B 1 D 1 ' / 0 1 * 3 . F H 1 ' ) 3 1 / 0 J 0 K L 3 ) D )
1 L ' . D i H D 1 D s J ) J N 1 D :
 ) M ) ' . D  ) ' ' . D , 1 U  ] ? n U  ? @ U W  / 1 L 1 * . D 1 L
' ) v w H M )  1 ' , 1 D w ' . D 1 , 1 / 0 1 * 3 . D , 1 ' ) D , 0 g
 1 M 1 L / 1 D  ) D 1 D :  ) M ) H L 1 D F H 1 * ) , 1 , 0 M 1 J / . M 0 .
x n n m ? y l ' . D / 0 1 * 3 . D D 1 * ) L / 0 1 L 1 L J . L D / ) L / 1 D
J . L ' ) D / M 1 D / z J L 0 J ) D , 1 1 L c d . , 1 * 1 L D ) \ 1 D , 1
J . N 1 M 1 L J 0 ) : ; D / . D 1 , 1 i 1 ) F H 1 1 ' L f * 1 M . , 1
L . , . D F H 1 J . * 3 ) M / 1 L H L ) ' d L 1 ) 1 D * H s 3 1 F H 1 g
 . l 3 . M ' . F H 1 1 ' H D . , 1 H L 0 J ) D / . * H ' / 0 , 1 D / 0 L .
c ) M 0 ) M { 3 . J . ' . D M 1 D H ' / ) , . D :
0 L . D v \ ) * . D D K ' . 1 L ' ) D i ) M M ) D J . M M 1 D g
3 . L , 0 1 L / 1 D ) x  U @ ?  ~ l c 1 * . D J . * . ' ) H / 0 ' 0  ) g
J 0 K L , 1 H L J K , 0 w . , 1 J . * 3 ) M / 0 J 0 K L  U  ? 7  ~ 7 9 9
 U ~ €  x  ~ 7 9 9  , 1 w M ) , ) M { 1 ' / 0 1 * 3 . / . / ) ' M 1 D g
3 1 J / . ) x n n m ? y D . i M 1 H L
70 %
:  . M D H 3 ) M g
/ 1 l  U  ? 7  ~ 7 9 9 , 1 w M ) , ) M { 1 ' / 0 1 * 3 . / . / ) ' N ) D g
/ ) 1 L H L
225 %
M 1 D 3 1 J / . ) x n n m ? y 1 L 1 ' J ) D .
, 1    
   : 0 ) L ) ' 0  ) * . D , 1 / ) ' ' ) , ) * 1 L / 1 ' )
J ) H D ) 3 . M ' ) F H 1 D 1 3 M . , H J 1 1 D / ) , 1 w M ) , ) J 0 K L l
c 1 * . D F H 1 ' )  ) D 1 1 L ' ) F H 1 D 1 3 M . , H J 1 H L * ) g
s . M ) H * 1 L / . , 1 / 0 1 * 3 . 1 D 1 L ' ) , 1 J M 1 ) J 0 K L
, 1 ' . D * 1 L D ) \ 1 D : ; D / . D 1 , 1 i 1 ) ' 0 * 3 . M /
) L / 1
0 L J M 1 * 1 L / . 1 L 1 ' L f * 1 M . , 1 * 1 L D ) \ 1 D , 1 J . g
N 1 M 1 L J 0 ) F H 1 0 * 3 ' 0 J ) 1 ' H D . , 1 H L , 0 M 1 J / . M 0 .
J . * 3 M 0 * 0 , . : 0 ) N . M ) ) * 3 ' 0 ) * . D L H 1 D / M . D N . g
M 0  . L / 1 D N ) D / ) ' ) D i ) M M ) D J . M M 1 D 3 . L , 0 1 L / 1 D ) ' ) D
/ z J L 0 J ) D * H ' / 0 , 1 D / 0 L . l c 1 * . D J . * . 1 ' / 0 1 * 3 .
, 1 J M 1 ) J 0 K L D 1 * ) L / 0 1 L 1 3 M { J / 0 J ) * 1 L / 1 J . L D g
/ ) L / 1 3 ) M ) / . , . D ' . D J K , 0 w . D , 1 J . * 3 ) M / 0 J 0 K L :
; L 1 D / 1 ) D 3 1 J / . D 1 J . L D 0 w H 1 H L ) * 1 \ . M ) 0 * g
3 . M / ) L / 1 M 1 D 3 1 J / . ) x  U @ ?  ~ : … )  ) D 1 F H 1 * { D
M 1 3 1 M J H / 1 1 L 1 ' / 0 1 * 3 . / . / ) ' 1 D 1 ' / 0 1 * 3 . , 1
1 L c d . : ; L 1 D / 1 J ) D . ' ) D , . D / z J L 0 J ) D * H ' / 0 , 1 D g
/ 0 L . F H 1 N 1 * . D 0 * 3 ' 1 * 1 L / ) , . D 1 J . * 3 . M / ) M { L
3 1 . M F H 1 H L 0 J ) D / : ; D / . D 1 3 H 1 , 1 1 ‡ 3 ' 0 J ) M 3 . M 1 '
N 1 J N . , 1 L . 1 L J . L / M ) M D 1 D . i M 1 J ) M w ) , ) ' ) M 1 , l
3 . M ' . F H 1 ) J 1 3 / ) M { D 0 L 3 M . i ' 1 * ) D / . , . 1 ' / M { g
v J . F H 1 ' 1 0 L / M . , H  J ) * . D :  . J . L D 0 , 1 M 1 * . D 1 '
/ 0 1 * 3 . F H 1 / ) M , ) L ' ) D J . L / 1 D / ) J 0 . L 1 D 1 L c . ' c 1 M
) ' L . , . € B m 9 l s ) F H 1 D 1 M { L H L 0 J ) D / 1 L / . , . D ' . D
J ) D . D s ) ' L . 1 D / ) M ' ) M 1 , D ) / H M ) , ) l L . 0 L
H 0 M { L
D . i M 1 1 ' / 0 1 * 3 . , 1 1 L c d . :  . L 1 D / ) 3 M 1 * 0 D ) l ' )
, 0  1 M 1 L J 0 ) , 1 / 0 1 * 3 . 1 L / M 1 ' ) D / M 1 D / z J L 0 J ) D D 1
, 1 i 1  J ) D 0 D 0 1 * 3 M 1  ) ' / 0 1 * 3 . F H 1 / ) M , ) 1 L ' ' 1 g
w ) M 1 ' * 1 L D ) \ 1 , 1 J . N 1 M 1 L J 0 ) ) ' L . , . * { D ) ' 1 g
\ ) , . , 1 ' . M 0 w 1 L :  ' ) * 0 D * ) , 0 D / ) L J 0 ) l 3 ) M 1 J 1
' K w 0 J . F H 1 ' ) / z J L 0 J ) H L 0 J ) D / D 1 ) * { D 1 v J 0 1 L / 1
F H 1 1 ' 1 L M H / ) * 0 1 L / . m x n ~ U ˆ y ? ~ € s ) F H 1 1 ' * 1 L g
D ) \ 1 / 1 L , M { F H 1 N ) J 1 M ) ' w H L . D M . , 1 . D l 3 ) D ) L , .
3 . M . / M . D , 1 D / 0 L . D 0 L / 1 M * 1 , 0 . D ) L / 1 D , 1 ' ' 1 w ) M
) ' L . , . * { D ) ' 1 \ ) , . :  ) M ) 1 ' 1 L M H / ) * 0 1 L / . ? 7 ˆ
 W 7 9 B ] 9 7 ~ U @ ? n 1 c 0 / ) M 1 * . D , ) M M . , 1 . D l 3 1 M . D 1
D 0 w H 1 1 * 3 1 . M ) L , . M 1 D 3 1 J / . ) ' 1 L c d . H L 0 J ) D / l s )
F H 1 1 D / 1 ) ' w . M 0 / * . / 1 L , M { H L M 1 / ) M , . , 1 i 0 , . )
' ) , H 3 ' 0 J ) J 0 K L , 1 ' . D * 1 L D ) \ 1 D 1 L ' . D L . , . D 0 L g
/ 1 M * 1 , 0 . D : ; L J H ) L / . ) ' . D / 0 1 * 3 . D , 1 ) J J 1 D .
s * 0 D J 1 ' { L 1 . l L . 3 ) M 1 J 1 F H 1 D 1 c 1 ) L 0 L
H 0 , . D
3 . M ' ) / z J L 0 J ) , 1 1 L M H * 0 1 L / . H / 0 ' 0  ) , ) : ? 0 L ) ' g
* 1 L / 1 l ) ' D H * ) M ' . D / 0 1 * 3 . D , 1 / . , ) D ' ) D  ) D 1 D
c 1 * . D J . * . J . L D 1 w H 0 * . D * 1 \ . M ) M l 1 L 1 D 3 1 J 0 ) '
J . L 1 ' 1 L M H / ) * 0 1 L / . ? 7  W 7 9 B ] 9 7 ~ U @ ? n J . L 1 ' F H 1
J . L D 1 w H 0 * . D N ) D / ) H L
20 %
3 ) M ) 
   :
 ) M ) ' . D  ) ' ' . D , 1 U  ] ? n U  ? @ U W   m 9 m B 7 U ?
3 . , 1 * . D c 1 M 1 L ' ) v w H M )  J . * . D 1 , 1 D w ' . g
D ) L ' . D / 0 1 * 3 . D 3 ) M ) ' ) D , 0  1 M 1 L / 1 D  ) D 1 D : 1
3 H 1 , 1 . i D 1 M c ) M J . * . 3 ) M )    
   ' ) w M { v J )
/ 0 1 L 1 H L ) ' d L 1 ) * H s D 0 * 0 ' ) M ) ' ) F H 1 . i / H c 0 g
* . D 3 ) M ) ' . D  ) ' ' . D , 1 U  ] ? n U  ? @ U W  : ; L J ) * i 0 .
3 ) M ) 
   1 ' / 0 1 * 3 . , 1 1 L c d . ) H * 1 L / ) , M { D g
106 Redes y Comunicación

  


               

    #  
  
   
    
 
   
' ( * + - / 0 ' / + 3 + 5 - / 0 ' + 7 3 + * : - ; 7 / = ( ? 0 A / 3 * ? C
A ( D : A / * : - ; + 7 ' ( * ( ? 0 A / 3 A ( 7 / * ' : 7 ( : H 3 : J 5 / 0 :
: * 5 7 7 L + A /  : 7 - + ' + 0 - + 7 * + A + * : 0 3 : =  + 3 3 : = A /
R  S T U R  T V R X  Y Z = ' / + 5 - / 0 ' : A / = - / = 5 7 + A : / 0 / 3
' ( / - ; : A / / 0 ^ L : = / ; 7 : A 5 * / ; : 7 5 0 + * : 0 D / = ' ( ? 0
3 : * + 3 ( + A + + 3 + / 0 ' 7 + A + A / 3 0 : A : b c d e f ; 7 : C
A 5 * ( A + ; : 7 3 + D 7 + 0 + 5 / 0 * ( + A / + = / 0 ' ( - ( / 0 ' : =
5 0 ( * + = ' ; 7 : ^ : * + A : = ; : 7 3 + = ( 0 ^ + 3 ( A + * ( : 0 / = Y  /
3 + = D 7 k l * + = ' + - m ( n 0 = / / q ' 7 + / 5 0 ( - ; : 7 ' + 0 ' /
( 0 * 7 / - / 0 ' : / 0 / 3 ' ( / - ; : A / + * * / = : + 3 A ( 7 / * ' : C
7 ( : H J 5 / = / ; 7 : A 5 * / * : - : * : 0 = / * 5 / 0 * ( + A ( 7 / * C
' + A / 3 + 5 - / 0 ' : / 0 / 3 ' ( / - ; : A / / 0 ^ L : H f + J 5 /
+ 3 + 5 - / 0 ' + 7 / 3 ' ( / - ; : A / / 0 ^ L : = / + * 5 - 5 3 + 7 k 0
- k = ; / ' ( * ( : 0 / = / 0 3 + * : 3 + A / 3 A ( 7 / * ' : 7 ( : 7 /  / 7 / 0 C
' / = + 3 + - ( = - + 3 L 0 / + H J 5 / ' / 0 A 7 k 0 J 5 / / = ; / 7 + 7
+ J 5 / ' / 7 - ( 0 / 3 + ' 7 + 0 = + * * ( ? 0 + * ' 5 + 3 Y Z = ' : ; 7 : C
A 5 * / J 5 / / 3 ' ( / - ; : A / + * * / = : = / + ; 7 : q ( - / + 3
' ( / - ; : A / / 0 ^ L : Y Z = ' : = 7 / = 5 3 ' + A : = J 5 / * : 0 ^ ( / 7 C
' / 0 / 0 A / = ; 7 / * ( + m 3 / 3 + D + 0 + 0 * ( + / 0 3 + * 7 / + * ( ? 0
A / 3 : = - / 0 = + z / = = : 0 3 ( D / 7 + - / 0 ' / 0 / D + ' ( ^ : = ; + 7 +
3 + = A : = ' n * 0 ( * 0 + = - 5 3 ' ( A / = ' ( 0 : Y
{ : =  + 3 3 : = , | } c | , 0 : ' / 0 A 7 k 0  + = / A / / 0 ^ L : f +
J 5 / 3 + 7 / = ; 5 / = ' + = / / 0 ^ ( + 7 k A ( 7 / * ' + - / 0 ' / A / = A /
/ 3 0 : A : J 5 / ' ( / 0 / 3 + 3 L 0 / + A / - / - : 7 ( + / 0 / = ' + A :
; 7 ( ^ + A : + 3 0 : A : ; / ' ( * ( : 0 + 7 ( : Y Z 0 3 + l D 5 7 +  = /
; 5 / A / : m = / 7 ^ + 7 * : - : 3 : = ' ( / - ; : = ; + 7 +    
f
  
 = : 0 - 5 f A (  / 7 / 0 ' / = Y + 7 + / 3 ; 7 ( - / C
7 : A / / 3 3 : = ' / 0 / - : = J 5 / / 3 ' ( / - ; : A / + * * / = : = /
- + 0 ' ( / 0 / - 5 f / 3 / ^ + A : H A / m ( A : + 3 D / 0 / 7 + 3 ( + A :

    
               

    #  
  
   
         
+ 5 - / 0 ' : / 0 / 3 ' ( / - ; : A / / 0 ^ L : J 5 / ^ ( - : = / 0
3 : =  + 3 3 : = A / R  S T U R  T V R X   d e d c € R T Y  / 0 5 / ^ :
/ = ' /  + * ' : 7 ; / 7 z 5 A ( * + + 3 + = ' n * 0 ( * + = - 5 3 ' ( A / = ' ( C
0 : Y + 7 +
  
 = / ; 5 / A / + ; 7 / * ( + 7 * : - : 3 : =
' ( / - ; : = : m ' / 0 ( A : = * : 0   U U d T ‚ f „ R  T €  } € e e
 R } b   „ } € e e  = : 0 ; 7 k * ' ( * + - / 0 ' / ( A n 0 ' ( * : = H A / C
m ( A : + J 5 / ; : 7 5 0 3 + A : 0 : + 5 - / 0 ' + / 3 0 … - / 7 :
A / * : - ; + 7 ' ( A : 7 / = H f ; : 7 : ' 7 : / 3 ' ( / - ; : A / + * C
* / = : = / - + 0 ' ( / 0 / * : 0 = ' + 0 ' / Y Z 0 / 3 * + = : A / 5 0
* ? A ( D : A / * : - ; + 7 ' ( * ( ? 0 „ R  T €  } € e e H ; : A / - : =
^ / 7 * : - : ; + 7 +   R V T  } / 3 ' ( / - ; : A / * 7 / + * ( ? 0
+ 5 - / 0 ' + = ( D 0 ( l * + ' ( ^ + - / 0 ' / H * : = + J 5 / / ^ ( ' + - : =
* : 0 3 + = ' n * 0 ( * + = - 5 3 ' ( A / = ' ( 0 : Y Z 0 * : 0 = / * 5 / 0 * ( +
* : 0 = / D 5 ( - : = 5 0 ( - ; : 7 ' + 0 ' / + 5 - / 0 ' : A / 7 / 0 A ( C
- ( / 0 ' : ; + 7 + / = ' / ' ( ; : A /  + 3 3 : = Y
          ! ! $ &  ( & + , . $ & &
&     
 / D … 0 3 : = 7 / = 5 3 ' + A : = / q ; 5 / = ' : = / 0 3 + l D 5 7 +
  ; : A / - : = A / * ( 7 J 5 / / 3 / 0 7 5 ' + - ( / 0 ' : T € „ X |
€ e c S e € } R V T U = / * : - ; : 7 ' + - / z : 7 J 5 / / 3 d  U } R |
‚ T } b H / 0 / = ; / * ( + 3 * : 0 5 0 * ? A ( D : A / * : - ; + 7 ' ( C
* ( ? 0 „ R  T €  } € e e H A : 0 A / / 3 0 … - / 7 : A / A / = ' ( 0 : =
; : 7 - / 0 = + z / - 5 3 ' ( A / = ' ( 0 : / = - k = / 3 / ^ + A : Y
Z 0 / 3 * + = : A /     H + 3 5 = + 7 5 0 + ' n * 0 ( * +
A / / 0 7 5 ' + - ( / 0 ' : - 5 3 ' ( A / = ' ( 0 : = / ; 7 : A 5 * / 5 0
+ 5 - / 0 ' : / 0 / 3 ' ( / - ; : 0 / * / = + 7 ( : ; + 7 + 3 3 / ^ + 7 +
* + m : 3 + = ; / ' ( * ( : 0 / = A / R  S T U R  T V R X   d e d c € R T
f A / , | } c | , A / m ( A : + 5 0 ( 0 * 7 / - / 0 ' : A / 3 ' ( / - ; :
XVI Jornadas de Paralelismo, JP '2005 107

  


           |    

 
" $ & & " ' ) +  ) . ' 0 " . 3 " " 4 6 " ' ) . " 4 $ 3 : < ) " 4 ) '
 $ 4 4 ) ' " B  C E G E " ' 6 " I 0 " ) J K 4 $ N $ O $ O & : $
" O 4 $ ' 6 " 3 : & : ) O " ' " B  C S T B  S U B W  6 " . Y : 3 " I 0 "
" 4 3 : " Y 6 ) \ O $ 4 " " _ " & 0 & : a O Y " _ ) . " 4 " < " Y " O 3 "
$ 4 0 ' $ . " O & $ Y : O $ Y : " O 3 ) S e f W e G g C G e h B U S T +
i $ $ 6 4 : & $ & : a O
  
  " ' 4 $ I 0 " Y " _ ) . " '
. " ' 0 4 3 $ ) ' O ) ' p $ $ ) + q 4 3 : " Y 6 ) \ O $ 4 " " _ " s
& 0 & : a O 6 $ . $ 0 O : . " & 3 ) . : ) f B  S e h e G G p $ Y " _ ) s
. $ ) " O 0 O
15 %
$ 4 0 ' $ . 0 O " O . 0 3 $ Y : " O 3 ) S e f W x
e G g C G e h B U S T . " ' 6 " & 3 ) $ 4 ) ' . " ' 0 4 3 $ ) ' ) y 3 " O : ) '
& ) O 0 O : & $ ' 3 + q ' 3 ) ' " " y " $ I 0 " " 4 6 " ' ) . " 4 $ s
3 : < ) " 4 $ & . " $ & : a O " 4 ) ' Y " O ' $ _ " ' " ' Y 0 & p )
Y $ K ) . I 0 " " 4 " 4 " O < } ) J 6 ) . 4 ) I 0 " 4 $ N $ O $ O & : $
" ' Y 0 & p ) Y $ K ) . I 0 " 4 $ 6 ~ . : $ +  " Y  ' 6 $ s
. $ 4 $ ' 3 . $ O '  " . " O & : $ ' " , x h g x , J p $ y .  0 O N . $ O
O ‚ Y " . ) " Y " O ' $ _ " ' : O O " & " ' $ . : ) ' J 6 . ) < ) & $ O )
0 O $ Y " _ ) . $ " O " 4 3 : " Y 6 ) " & . " $ & : a O $ 4 0 ' $ .
3 ~ & O : & $ ' Y 0 4 3 : " ' 3 : O ) +
„ 
… † ‡  ˆ ‰ Š … † ‹ ‰  Ž     … ‰  ˆ  ˆ Ž … ‰
q O " ' 3 " $ . 3 } & 0 4 ) ' " p $ O 6 . " ' " O 3 $ ) K " < $ 4 0 $ )
) ' 3 ~ & O : & $ ' " " O & $ Y : O $ Y : " O 3 ) Y 0 4 3 : " ' 3 : O ) J
6 $ . $ Y : O : Y :  $ . " 4 & ) ' 3 ) ' ) y . " " 4 . " O : Y : " O 3 )
" 4 Y 0 4 3 : 6 . ) & " ' $ ) . 6 . ) 0 & : ) 6 ) . " 4 0 ' ) "
" ' I 0 " Y $ ' " : . " & 3 ) . : ) & ) Y 6 . : Y : ) ' J K $ ' } Y " s
_ ) . $ . 4 $ " ' & $ 4 $ y : 4 : $ " 4 ) ' & & s     + q ' 3 $
" ' & $ 4 $ y : 4 : $ ' " 4 ) N . $ N . $ & : $ ' $ 4 $ Y : O : Y :  $ s
& : a O " 4 3 : " Y 6 ) " & . " $ & : a O " 4 ) ' Y " O ' $ _ " ' "
& ) p " . " O & : $ J K $ 4 $ . " 0 & & : a O " 4 $ ' ) y . " & $ . N $
" 4 $ . " + q ' 3 $ $ . I 0 : 3 " & 3 0 . $ 6 " . Y : 3 : .  : ' " $ .
Y 0 4 3 : 6 . ) & " ' $ ) . " ' & & s     & ) O 0 O O ‚ Y " . )
" O ) ) ' y $ ' 3 $ O 3 " Y $ K ) . I 0 " 4 ) ' $ & 3 0 $ 4 " ' + i ) '
: . " & 3 ) . : ) ' & ) Y 6 . : Y : ) ' ' ) 4 0 & : ) O $ O " 4 6 . ) y 4 " s
Y $ " 4 $ ' ) y . " & $ . N $ " Y " Y ) . : $ I 0 " : Y 6 4 : & $
3 " O " . 0 O ' : ' 3 " Y $ & ) O Y : 4 " ' " 6 . ) & " ' $ ) . " ' J
6 " . ) : O 3 . ) 0 & " O 0 O $ : Y 6 ) . 3 $ O 3 " " N . $ $ & : a O
" O " 4 3 : " Y 6 ) " " _ " & 0 & : a O + i $ 0 3 : 4 :  $ & : a O "
3 ~ & O : & $ ' " " O & $ Y : O $ Y : " O 3 ) Y 0 4 3 : " ' 3 : O ) 6 ) s
. } $ & ) O ' " N 0 : . $ 6 . ) “ : Y $ . " 4 3 : " Y 6 ) " " _ " & 0 s
& : a O " 0 O ' : ' 3 " Y $
& ) O : . " & 3 ) . : ) & ) Y 6 . : Y : )
$ 4 " 0 O ' : ' 3 " Y $ & ) O : . " & 3 ) . : )  ” T T E S • +
 ) Y ) 3 . $ y $ _ )  0 3 0 . ) J . " ' 0 4 3 $ " N . $ O : O 3 " . ~ '
: Y 6 4 " Y " O 3 $ . 3 ~ & O : & $ ' " " O . 0 3 $ Y : " O 3 ) Y 0 4 3 : s
" ' 3 : O ) 6 $ . $ 4 $ ' & ) O 3 " ' 3 $ & : ) O " ' $ 4 ) ' Y " O ' $ _ " '
" & ) p " . " O & : $ J K $ ' } & ) O ' " N 0 : . 0 O $ Y $ K ) . 4 : y " s
. $ & : a O " 4 $ & $ . N $ " 3 . $ y $ _ ) " 4 $ . " +  $ Y s
y : ~ O ' " . } $ Y 0 K : O 3 " . " ' $ O 3 " 6 . ) y $ . 3 ~ & O : & $ ' "
" O & $ Y : O $ Y : " O 3 ) Y 0 4 3 : " ' 3 : O ) $ $ 6 3 $ 3 : < ) J I 0 "
' " $ & ) 6 4 $ . } $ O Y " _ ) . $ 4 $ ' & ) O : & : ) O " ' : O  Y : s
& $ ' " 4 $ . " +
— ‹  ‹ Ž ‹ † ‡ Š  ‰
! #  $ O 0 " 4 q +  & $ & : ) J +  ) O   4 "  J +  +
 $ . & } $ J +  0 $ 3 ) +  O  . & p : 3 " & 3 0 . "  ) .
: N p s  " .  ) . Y $ O & " ' & $ 4 $ y 4 " ' p $ . " s
 " Y ) . K  0 4 3 : 6 . ) & " ' ' ) . ' q “ 6 4 ) 3 : O N

O s & p : 6  O 3 " N . $ 3 : ) O +
   
 e S  ( S U h B g  (
g   S e S T T G T S  

B ( h e B f ” h G 

( h G E ( J  ) 4 +
! * J  ) +  J  0 N + +  
+
+ #  $ O 0 " 4 q +  & $ & : ) J +  ) O   4 "  J +  +  $ . s
& } $ J +  0 $ 3 ) +    ) s i " < " 4  : . " & 3 ) . K  . s
& p : 3 " & 3 0 . "  ) . : N p 4 K ' & $ 4 $ y 4 " & & s    
 0 4 3 : 6 . ) & " ' ' ) . ' +
   
 e S  ( S U h B g  ( g 
 S e S T T G T S  

B ( h e B f ” h G 

( h G E ( J  ) 4 + !  J
 ) + ! J $ O +   * +
. # +  0 $ 3 ) J ' J  $ 4 Y $ O & p : 4 : J i +  +  : +  O s
3 " . & ) O O " & 3 : ) O  " 3  ) .  ' J $ O q O N : O " " . : O N
 6 6 . ) $ & p +
   

g E • ” h G e

g U B G h 

 U  
!    +

#  + + 0 N p " ' J  + ' +  $ : J  +  $ O N $ O $ 3 p $ O J

$ O ' +  +  < " +  '    ' : Y 0 4 $ 3 : O N ' p $ . " s
 " Y ) . K  0 3 : 6 . ) & " ' ' ) . '  : 3 p  i   . ) & " ' s
' ) . ' +
   

g E • ” h G e J < ) 4 + . * J O ) + + J 6 6
 s

 J " y + +   + +
* # + i : O J  + ! +  & ! : O 4 " K J $ O i +  + i : +
 " $ 4 ) &  s . " "  0 4 3 : & $ ' 3 # ) . Y p ) 4 "  ) 0 s
3 : O N : O +  s  " ' p  0 4 3 : & ) Y 6 0 3 " . ' +  e g U 

 h 
g    g   S e S T T G T  e g U G ( ( B 

J 6 6 +    s
! !
s    s ! !  J " y + !   ! +
 #  4 " _ $ O . )
. )  & ) i a 6 "  + q ' 3 0 : ) K " < $ s
4 0 $ & : a O " 4 " O & $ Y : O $ Y : " O 3 )  0 4 3 : & $ ' 3 " O
& & s     ' & ) O  : . " & 3 ) . : ) '  ) Y 6 . : Y : ) ' +
 e g G U h g    G U S e e G e S G  T S   B C G e ( B  S 
 G  ” e U B S  ( ” T B g ) + + . 
108 Redes y Comunicación
Simulación de redes de interconexión utilizando tráfico real
F. J. Ridruejo Pérez, J. Miguel-Alonso1
Universidad del País Vasco UPV/EHU
Departamento de Arquitectura y Tecnología de Computadores
Apdo. 649, 20080 San Sebastián
{j.miguel, franciscojavier.ridruejo}@ehu.es
1
Este trabajo ha sido posible gracias a la financiación del Ministerio de Educación y Ciencia (TIN2004-07440-C02-02)
y de la Diputación Foral de Gipuzkoa (OF-846/2004).
Resumen
La simulación de redes de interconexión para
sistemas paralelos y distribuidos requiere de
mecanismos para la generación de tráfico. Este
tráfico puede ser sintético, extraído de trazas, u
obtenido a partir de aplicaciones paralelas en
ejecución. En este trabajo describimos cómo, en el
contexto de TrGen (el módulo de generación de
tráfico de INSEE) estamos usando un sistema de
simulación conducida por la ejecución basado en
SIMICS para obtener tráfico real y alimentar con
él simuladores de redes de interconexión.
1. Introducción
En el diseño de un sistema paralelo, el sub-sistema
de comunicación entre procesadores es un
elemento crítico. Existe toda una línea de
investigación en el área de redes de interconexión.
Muchos trabajos en esta área utilizan como
elemento clave la simulación. Podemos
encontrarnos, como software comercial o gratuito,
multitud de simuladores de redes. Todos ellos
tienen algún mecanismo para la generación de
tráfico durante la simulación. Los patrones de
tráfico empleados tienen una influencia
trascendental en los resultados obtenidos. Lo ideal
es que se usen tráficos reales, generados por las
aplicaciones que van a ejecutarse en el sistema
paralelo.
Hay diferentes maneras de generar el tráfico
que alimenta a los simuladores. Ordenándolos de
peor a mejor en cuanto a la fidelidad del tráfico
generado (con respecto a las aplicaciones reales),
tenemos:
• Patrones de tráfico sintéticos, obtenidos
aplicando distintas distribuciones estadísticas.
Ejemplos de ello son el uniforme, la matriz
transpuesta, el hot-spot (punto caliente) o el
hot-region (región caliente).
• Tráfico basado en trazas, que es obtenido
mediante la generación de trazas durante la
ejecución de las aplicaciones paralelas en un
sistema real—normalmente, uno distinto al
que se está estudiando.
• Simulación conducida por la ejecución, donde
no sólo se simula la red de interconexión y el
tráfico que la recorre, sino también los nodos
conectados a ella. De esta manera se ejecuta la
aplicación real en los nodos simulados que se
comunican utilizando la red de interconexión
simulada.
Como en otros muchos contextos, la fidelidad
está reñida con la velocidad. Así, muchas veces se
usan, en las primeras fases de evaluación de una
propuesta de diseño, los patrones sintéticos, para
refinar la propuesta y no continuar si no es
prometedora. La generación de trazas es más
compleja, porque pueden ser de gran tamaño y,
además, se necesitan muchas: tantas como
aplicaciones objetivo. La simulación conducida
por ejecución sólo nos la podemos plantear
cuando tenemos suficientes recursos, en forma de
máquinas y tiempo, porque el grado de detalle de
simulación exigido hace que sea muy costosa
computacionalmente.
Nuestro grupo lleva unos años desarrollando
INSEE [6], un entorno de evaluación de redes de
interconexión, cuyos elementos principales son
FSIN (un simulador funcional de redes) y TrGen
[5] (una colección de módulos de generación de
tráfico). Este artículo se centra en la parte de
TrGen encargada del tráfico real, conducido por la
ejecución. Se ha realizado utilizando SIMICS [2]
como elemento de base para la simulación de los
nodos de cómputo. La estructura modular de
SIMICS nos ha permitido añadir elementos para
extraer/insertar mensajes, que son procesados por
un simulador de redes.
En la próxima sección describimos
someramente INSEE, para poner este trabajo en
contexto. La sección 3 contiene el grueso de este
trabajo: los diseños realizados sobre SIMICS para
integrarlos en nuestro entorno de simulación. En
la sección 4 recogemos algunas conclusiones
sobre el trabajo realizado.
2. INSEE
INSEE (Interconnection Network Simulation and
Evaluation Environment) está organizado como
un conjunto de módulos, muchos de los cuales se
pueden utilizar como aplicaciones independientes.
FSIN (Functional Simulator of Interconnection
Networks) y TrGen (Traffic Generator) forman su
núcleo.
En la Figura 1 se puede ver representado el
diseño de INSEE. Los elementos sombreados en
gris forman parte de este entorno y han sido
desarrollados por nuestro grupo. Los demás son
módulos externos pero pueden interactuar con él
usando su API. SICOSYS [4] ha sido desarrollado
independientemente, pero puede considerarse que
forma parte de INSEE. En la parte de la derecha
se encuentran los diferentes simuladores de redes
de interconexión y a la izquierda están
representadas las distintas fuentes de tráfico.
2.1. FSIN
FSIN es un simulador funcional que sirve para
asistir en el diseño de redes de interconexión y
para la ayuda en la toma de decisiones en las
primeras fases de este diseño.
Se trata de un simulador muy flexible ya que
se pueden controlar multitud de parámetros.
Además, es muy rápido, porque no simula los
detalles hardware, consumiendo muy poca
memoria. Esto permite simular redes de gran
tamaño (miles de nodos) con un equipo de
sobremesa. El grupo de investigación ya contaba
con un simulador de redes de interconexión,
SICOSYS, pero éste detalla los elementos de la
red a un nivel próximo a su implementación
hardware, lo que lo hace dos órdenes de magnitud
más lento y pesado en memoria. En cambio ofrece
una información sobre tiempos mucho más
detallada que FSIN.
FSIN simula encaminadores como el
mostrado en la Figura 2. Algunos de los
parámetros que se pueden cambiar son: tamaños
de colas y búferes, número de dimensiones,
número de canales virtuales por enlace físico,
enlaces uni- o bi-direccionales, tamaño del
paquete en phits, topología de la red, tamaño de la
misma, estrategia de gestión, de petición y política
de asignación de los canales virtuales, etc.
Figura 1. Diseño de INSEE. Una API común permite la conexión de diferentes simuladores con las fuentes de tráfico
posibles.
110 Redes y Comunicación
Cross-
bar
X-
Y+
Y-
X-
Y+
Y-
Local
reception
X+ E
X+ A1
X+ A2
X+ E
X+ A1
X+ A2
Injection buffer
Injection queue
Figura 2. Modelo de encaminador simulado por FSIN.
2.2. TrGen
TrGen es una herramienta de generación de tráfico
que, por medio de una API común permite probar
los diseños de propuestas de redes de
interconexión con diferentes fuentes de tráfico,
como son tráfico sintético, tráfico tomado a partir
de trazas reales y tráfico real sacado de una
simulación conducida por la ejecución.
Tráfico sintético
TrGen permite la especificación de muchos tipos
de tráfico sintético diferentes que pueden ser
válidos para representar (siempre de forma
aproximada) el intercambio de mensajes generado
en la ejecución de aplicaciones reales.
El tipo de tráfico sintético se caracteriza por
tres tipos de distribuciones: temporal, espacial y
tamaño del paquete.
La distribución temporal determina el
intervalo entre generaciones de paquetes, y sus
correlaciones. Entre sus valores posibles están las
distribuciones Bernouilli, ráfagas constantes,
Markov.
La distribución espacial determina los nodos
destino de los paquetes, y sus valores posibles son
las distribuciones uniforme, zipf, zona caliente,
punto caliente, y varias de tipo constante como
transpuesta, mariposa, barajado perfecto, o
inversa.
La distribución de tamaño del paquete
determina el tamaño de los paquetes que son
enviados y sus posibles valores son las
distribuciones constante, uniforme y polinomial.
Tráfico basado en trazas
El tráfico sintético proporciona una buena
orientación sobre el potencial de una propuesta de
diseño. Pero las medidas de rendimiento obtenidas
pueden no ser del todo ciertas, ya que en las
aplicaciones reales los intercambios de mensajes
se hacen en momentos determinados y
normalmente siguen una relación de causalidad,
esto es, una aplicación muchas veces espera la
llegada de un mensaje para a su vez mandar otro
de respuesta.
TrGen incorpora la posibilidad de utilizar
trazas tomadas de tráfico real de aplicaciones
paralelas como fuente de tráfico. Para ello se han
realizado unas ligeras modificaciones a MPICH
[1], una implementación de MPI [3], para poder
aumentar el grado de detalle de generación de
trazas. Además, se ha implementado un pre-
procesador que adapta las trazas a un formato
propio de TrGen.
Los cambios realizados a MPICH consisten en
hacer visibles como operaciones punto a punto las
operaciones colectivas MPI. Sin esta
modificación, MPICH guarda como una única
traza las operaciones colectivas, aunque
internamente las implementa como una serie de
operaciones punto a punto.
En el pre-procesamiento realizado a las trazas
obtenidas de MPICH se elimina toda la
información relativa a tiempos de los eventos,
manteniendo, sin embargo, la ordenación temporal
de los mismos, para conservar la causalidad. Se
hace esto porque las marcas de tiempo de las
trazas dependen en gran parte de la velocidad de
proceso de los nodos y de la velocidad de la red de
interconexión que los conectaba en la máquina
real usada para la obtención de las trazas. De esta
manera cuando hacemos una simulación basada
en trazas sometemos a la red a la máxima presión,
convirtiendo la red en el cuello de botella de la
ejecución, para saber cuál es su potencial de
rendimiento.
XVI Jornadas de Paralelismo, JP '2005 111
Tráfico real
Por último, TrGen permite la simulación con
tráfico real, generado por aplicaciones en
ejecución (en un entorno simulado). Explicamos
esto con detalle en la próxima sección.
3. Simulación conducida por la ejecución
Como acabamos de adelantar, la tercera fuente de
tráfico posible con TrGen es tráfico real generado
y consumido por aplicaciones reales. Para ello se
utilizan simuladores de sistemas completos que
simulan computadores en los que se ejecutan las
aplicaciones paralelas de interés que generan el
tráfico que se inyectará en el simulador de redes
de interconexión.
La simulación es pues tan realista como
detallada es la descripción de cada componente de
la simulación, y el precio a pagar por realizar una
simulación conducida por la ejecución es una
enorme pérdida de rendimiento con respecto de un
sistema real, debido a la simulación tanto de la red
que interconecta los computadores como de los
propios computadores que ejecutan las
aplicaciones paralelas.
En este momento la simulación de los nodos
de cómputo se realiza utilizando el producto
SIMICS de Virtutech [2]. Es un simulador que
permite la simulación de una amplia variedad de
arquitecturas hardware sobre un PC de sobremesa,
por ejemplo, permite simular una máquina Sparc
de 4 procesadores con el sistema operativo Solaris
(guest) sobre un PC Intel con el sistema operativo
Linux (host).
Actualmente usamos SIMICS para simular los
nodos de cómputo (guest) sobre máquinas PC
Intel con Linux de sistema operativo. Los nodos
de cómputo simulados son sistemas x86 con
64MB de memoria y Linux Red Hat 7.3 como
sistema operativo. Cada uno de estos nodos de
cómputo ejecuta la aplicación paralela de interés y
genera mensajes que son enviados al resto de los
nodos de cómputo usando TrGen como interfaz de
comunicación con el simulador de redes de
interconexión elegido, en nuestro caso FSIN.
Podemos tener varios hosts simulando cada
uno varios nodos de cómputo, guests, para así
construir una red tan grande como nos permitan
nuestros recursos, eso sí teniendo como limitación
el número de licencias de SIMICS de que
dispongamos, requiriendo cada host de una.
SIMICS también incluye un mecanismo que
actúa como una red Ethernet simulada que sirve
para conectar y además sincronizar a todas las
instancias de los nodos de cómputo, denominado
SIMICS Central. En nuestra configuración, sólo
utilizamos Central para sincronizar entre sí los
nodos de cómputo, ejecutando la simulación de
una manera determinista, ya que nuestros nodos
de cómputo se comunican a través de la red de
interconexión simulada, FSIN, mediante la API de
TrGen.
De esta manera, los mensajes generados por
un nodo de cómputo (guest) son interceptados y
enviados a TrGen que a su vez los inyecta en
FSIN. Asimismo, cuando un mensaje que circula
por la red de interconexión llega a su destino, es
inyectado mediante TrGen en el nodo de cómputo
correspondiente. Este intercambio de mensajes
puede verse en la Figura 3.
SIMICS Central
Synchronization
Guest
Guest
TrGen
M
essage
sent
M
e
ssa
g
e
se
n
t
M
essage
arrival
M
essa
ge
a
rriva
l
Network
simulator
API
.
.
.
Host computer(s)
S
y
n
c
S
y
nc
Figura 3. Interacciones entre los elementos
involucrados en la simulación conducida
por la ejecución.
3.1. Diseño de la arquitectura
Durante el desarrollo de este trabajo se han
realizado dos implementaciones distintas para
conectar el simulador de sistema completo
SIMICS con una red de interconexión vía TrGen.
Implementación basada en driver y módulo
SIMICS hardware
Esta versión está compuesta fundamentalmente
por dos componentes desarrollados en su totalidad
por el grupo: un módulo SIMICS que realiza las
funciones de un adaptador de red PCI, y un driver
para instalar en el núcleo de Linux que sirva como
interfaz entre el sistema operativo del nodo de
112 Redes y Comunicación
cómputo simulado y el módulo de hardware
desarrollado.
SIMICS permite extender su funcionalidad
mediante la implementación de módulos software
adicionales que se incorporan al simulador y que
pueden realizar cualquier función, como por
ejemplo, implementar la funcionalidad de una
tarjeta de red PCI, que es nuestro caso.
Un nodo de cómputo ve este módulo como un
adaptador de red PCI, al que se le instala un driver
creado específicamente para él.
A las aplicaciones paralelas que se ejecutan en
el nodo de cómputo se les indica que intercambien
sus mensajes a través de la interfaz de red creada
por nosotros y que se identifica en el sistema
operativo como si de una tarjeta de red PCI se
tratase. Dichos mensajes a inyectar en la red de
conexión son recibidos por el driver de nuestra
tarjeta de red, el cual escribe en los registros de
nuestro adaptador de red, y que se encarga de
sacarlos al exterior del simulador mediante una
conexión TCP/IP e interactuar con TrGen para
que éste inyecte los paquetes en el simulador de
redes de interconexión.
Cuando un paquete de la red de interconexión
llega a un nodo, es TrGen quien se comunica por
TCP/IP con nuestro módulo hardware de SIMICS,
quien provoca una interrupción hardware
anunciando la llegada de un nuevo paquete, la
cual es atendida por el driver de dicha interfaz de
red, que a su vez se encarga de hacerlo llegar al
sistema operativo y éste a la aplicación paralela.
Toda esta comunicación puede verse en la Figura
4.
Por otra parte los nodos de cómputo se
sincronizan entre sí como ya hemos comentado
mediante el uso del módulo de SIMICS, Central,
realizando así una ejecución determinista.
Esta implementación es válida para simular
redes de interconexión conectadas con los nodos
de cómputo por medio de adaptadores de red
diferentes de Ethernet, ya que somos nosotros los
que decidimos la implementación hardware del
adaptador, y podemos hacer que se identifique en
el kernel como un dispositivo de red no Ethernet,
algo que no ha sido implementado. Por ejemplo,
también sería posible la implementación hardware
de un módulo SIMICS análogo al existente pero
que se comportase como un adaptador de red tipo
Myrinet. En este caso habría que modificar
también el driver para que se identificase en el
kernel como un dispositivo de ese tipo.
Implementación basada en llamadas a rutinas
del usuario (callbacks)
En las versiones recientes de SIMICS se han
implementado una serie de rutinas en la API de
desarrollo que permiten el establecimiento de
llamadas a rutinas definidas por el usuario ante un
evento (callback). En particular, estos eventos
pueden ser de transmisión o recepción de paquetes
asociados a un adaptador de red.
Host (actual hardware)
SIMICS
Guest
Parallel application
process
User space
Driver for the PCI network
adapter
Kernel space
Packet sent through
network interface
SIMICS
synchronization
SIMICS module
simulating PCI
network adapter
Hardware write
Synchronization
LAN
SIMICS
Central
synchronizat
ion host
TrGen Network
simulator
API TrGen
Figura 4. Estructura del intercambio de mensajes, desde su creación en una aplicación paralela (ejecutándose en un
nodo de cómputo simulado) hasta su llegada al computador que ejecuta el simulador de redes de
interconexión.
XVI Jornadas de Paralelismo, JP '2005 113
Con el uso de estos callbacks se simplifica
mucho la creación del prototipo de simulación
conducida por la ejecución, ya que se elimina la
creación del módulo SIMICS que implementa el
adaptador de red PCI, y su consiguiente driver.
Otra novedad en SIMICS es la posibilidad de
manipular las interfaces de red, inyectando o
eliminado paquetes de la misma.
En esta implementación la aplicación paralela
ejecutada en los nodos de cómputo se comunica
utilizando un adaptador de red de tipo Ethernet
propio de SIMICS. Nosotros nos encargamos de
crear un módulo de propósito general para
SIMICS, porque no implementa ningún
dispositivo hardware. En este módulo instalamos
callbacks asociados al envío de paquetes por el
adaptador de red que SIMICS nos proporciona.
Cuando una aplicación envíe un paquete,
SIMICS se encargará de ejecutar el callback que
hemos instalado, avisándonos de que tal envío se
produce. Es entonces cuando utilizando las nuevas
funcionalidades de SIMICS, en cuanto a
dispositivos de red se refiere: le “quitamos” el
paquete a la interfaz de red, lo sacamos fuera del
entorno de simulación de SIMICS y se lo
mandamos por TCP/IP a TrGen, que se encargará,
al igual que antes de inyectarlo en nuestro
simulador de redes de interconexión.
De manera análoga, cuando un paquete de la
red de interconexión llega a su destino, TrGen se
comunica con nuestro módulo SIMICS avisándole
de la entrega del paquete. Entonces aprovechamos
la funcionalidad de SIMICS para inyectar el
paquete en la interfaz de red. Después de esto,
SIMICS hará llegar al driver el paquete, y éste a
su vez se lo transmitirá al sistema operativo y
finalmente el paquete llegará a la aplicación
paralela.
También es necesario implementar un módulo
SIMICS de propósito general que se ejecutará
dentro del proceso Central, y que será el
encargado de instalar otro callback, esta vez para
que cada cierto tiempo, predefinido, al que
llamamos “paso” (de sincronización), mande un
mensaje con el timestamp de la ejecución al
proceso encargado de simular la red de
interconexión, y se pare esperando a que dicho
proceso le responda, permitiendo así la
continuación de la simulación. De esta manera la
simulación avanza de manera determinista, paso a
paso, siendo la duración de este paso configurable
desde el módulo SIMICS de los nodos de
cómputo, como se comentará en el siguiente
apartado.
Esta versión tiene, frente a la basada en la
implementación de módulos hardware, la ventaja
de que es más sencilla, porque se aprovechan las
nuevas funcionalidades de SIMICS y toda la
gestión de las comunicaciones es más simple,
siendo SIMICS el que se encarga de hacernos
llegar el paquete.
3.2. Esquema de comunicaciones
Los nodos de cómputo basados en SIMICS se
comunican entre sí siguiendo el diagrama que
puede observarse en la Figura 5. Por una parte se
mantienen sincronizados entre sí conectándose al
módulo de SIMICS Central. Como ya se ha
comentado, Central sirve de infraestructura de red
para comunicar los nodos de cómputo,
(funcionalidad que no usamos) y de medio de
sincronización entre los mismos.
Por otro lado, los nodos de cómputo envían
sus paquetes fuera del entorno SIMICS, como se
ha explicado en el apartado anterior, o bien a
TrGen que los inyectará en el simulador de redes
de interconexión, o a una aplicación de pruebas
llamada Switch que actúa como un conmutador
enviando los paquetes que le llegan de un nodo de
cómputo a su destinatario. Esta aplicación está
dotada de la capacidad de simular un retardo en
las comunicaciones que denominamos retardo de
interconexión, controlado por un parámetro
definido por el usuario.
Figura 5. Comunicación establecida entre los distintos
componentes del prototipo.
Como se ha comentado en el punto anterior, el
módulo implementado dentro de Central, manda
un mensaje al proceso Switch a cada paso, e
interrumpe después su ejecución—lo que resulta
114 Redes y Comunicación
en una interrupción de la simulación, ya que los
nodos de cómputo están sincronizados mediante
Central.
Durante la ejecución normal entre dos
mensajes de timestamp (un paso), los nodos de
cómputo realizan sus tareas habituales, enviando
sus mensajes al proceso Switch que los almacena
hasta la llegada de un nuevo timestamp. La
duración del paso la define el usuario.
El mensaje con el timestamp que llega al
proceso Switch, le indica a éste que es el momento
de realizar un envío de los mensajes que guarda
encolados, hacia los nodos de cómputo de destino.
Entonces el Switch se comunica con los módulos
SIMICS que implementan la recepción y envío de
comunicaciones (en los nodos) y les manda los
mensajes que tiene pendientes; eso sí,
indicándoles que no deben ser entregados hasta
que pase un tiempo indicado como parámetro del
proceso Switch, que emula el retardo de la red de
interconexión.
Una vez la cola de mensajes pendientes de
entrega en el Switch está vacía, éste manda el
mensaje de Go Ahead a nuestro módulo SIMICS
ubicado en el proceso Central, indicándole que
puede continuar con la simulación durante un
nuevo paso.
La ejecución de un paso en SIMICS supone,
entre otras cosas, que los mensajes almacenados
en las colas de los nodos sean inyectados en las
interfaces de red de esos nodos en los momentos
indicados por los eventos programados.
Todo este mecanismo puede ser visto
gráficamente en la Figura 6.
3.3. Resultados
Se han realizado pruebas de funcionamiento del
prototipo de simulación conducida por la
ejecución. Las pruebas han sido satisfactorias
debido a que el sistema se ha comportado como se
esperaba, no se pierde ningún mensaje de los
nodos de cómputo.
Las pruebas tipo han sido realizadas en un
único SIMICS host, ya que no se disponía más
que de una licencia de este simulador. En una
misma máquina se han simulado 4 nodos de
cómputo basados en Intel x86 con 64 MB de
RAM y Red Hat Linux instalado. Estos nodos se
conectan a la red por medio de una interfaz de red
PCI Ethernet DEC 21143 de 100Mbs,
proporcionada por SIMICS. Dichos nodos se
comunican entre sí mediante el proceso Switch y
se sincronizan utilizando Central.
Con esta configuración, se han calculado los
siguientes valores como apropiados. Un ciclo
SIMICS son 50 ns, pudiendo ser configurable, ya
que este valor viene dado por la velocidad de reloj
que se le indica al simulador en su configuración y
que es de 20MHz por defecto. Se ha calculado
que, debido al retardo introducido por la atención
del sistema operativo a las interrupciones, y a que
la interfaz de red de estas pruebas es una Ethernet,
el tiempo mínimo entre envíos de paquetes es de
unos 2200 ciclos, o sea, unos 110 µs. Con estos
valores se ha configurado la latencia de
sincronizaciones entre los nodos y Central para
que sea de 50 µs, y el paso sea de 2000 ciclos, o
100 µs.
Figura 6. Diagrama de flujo de un intercambio de mensajes realizado entre dos nodos de cómputo.
XVI Jornadas de Paralelismo, JP '2005 115
De esta manera, los paquetes enviados por los
nodos llegarán en el siguiente paso a sus destinos
respectivos y se les indicará que sean inyectados
en el sistema operativo una vez transcurrido el
retardo de interconexión.
Se ha realizado un sencillo experimento,
consistente en ejecutar una aplicación MPI (cpi,
cálculo distribuido del valor de pi) en las 4
máquinas simuladas. La interconexión se produce
mediante los adaptadores Ethernet y nuestro
Switch. Variando el retardo de interconexión se
han obtenido los datos recogidos en la Figura 7,
en la que se puede observar que el tiempo de
ejecución de programa paralelo es directamente
proporcional al retardo de la red.
4. Conclusiones y trabajo futuro
En este trabajo hemos presentado las líneas
generales de diseño e implementación de un
sistema de simulación de redes de interconexión
con fuentes de tráfico reales. Las ventajas de esta
aproximación son evidentes, porque eliminan las
dudas sobre la fidelidad de las fuentes de tráfico
empleadas en la evaluación de una red. Los
inconvenientes también quedan a la vista: el
enorme coste asociado, que a efectos prácticos
impide la simulación de redes de gran tamaño.
El sistema está en fase de pruebas; aún no se
han hecho experimentos con simulaciones reales.
Esta es, precisamente, la línea de trabajo actual.
La experiencia que se gane al integrar el sistema
con simuladores con FSIN conllevará, sin duda,
mejorar su diseño y aumentar su funcionalidad.
0,00
0,02
0,04
0,06
0,08
0,10
0,12
0 100 200 300 400 500 600 700 800 900 1000
Retardo de interconexión (en pasos)
Tiempo
de
ejecución
(seg.)
Figura 7. Tiempos de ejecución de cpi para distintos
valores de retardo de interconexión.
Referencias
[1] W. Gropp, E. Lusk, N. Doss, A. Skjellum
(1996). A high-performance, portable
implementation of the MPI message passing
interface standard, in Parallel Computing, vol.
22, no. 6.
[2] Peter S. Magnusson, Magnus Christensson,
Jesper Eskilson, Daniel Forsgren, Gustav
Hållberg, Johan Högberg, Fredrik Larsson,
Andreas Moestedt, Bengt Werner, (2002).
Simics: A Full System Simulation Platform,
IEEE Computer, February.
[3] Message Passing Interface Forum. MPI: A
Message-Passing Interface Standard.
Available at http://www-
unix.mcs.anl.gov/mpi/standard.html.
[4] V. Puente, J.A. Gregorio, R.Beivide (2002).
SICOSYS: An Integrated Framework for
studying Interconnection Network in
Multiprocessor Systems, Proceedings of the
IEEE 10th Euromicro Workshop on Parallel
and Distributed Processing. Gran Canaria,
Spain.
[5] F.J. Ridruejo, A. Gonzalez, J. Miguel-Alonso.
"TrGen: a Traffic Generation System for
Interconnection Network Simulators". 1st. Int.
Workshop on Performance Evaluation of
Networks for Parallel, Cluster and Grid
Computing Systems (PEN-PCGCS'05) (Olso,
Norway, June 14, 2005).
[6] F.J. Ridruejo, J. Miguel-Alonso. "INSEE: an
Interconnection Network Simulation and
Evaluation Environment". Lecture Notes in
Computer Science. (2005), to appear.
116 Redes y Comunicación
Modelo de AS orientado al desarrollo de mecanismos de gestión
Antonio Robles, Eva M. García, Aurelio Bermúdez, Rafael Casado, Francisco J. Quiles
Departamento de Informática, Instituto de Investigación en Informática
Universidad de Castilla – La Mancha
02071 Albacete
{antonio.robles, aurelio.bermudez, rafael.casado, francisco.quiles}@uclm.es; evam.garcia1@alu.uclm.es
Resumen
Advanced Switching (AS) define una arquitectura
de red conmutada que soporta una alta
disponibilidad, a través de capacidades como la
adición y supresión de dispositivos en caliente, la
existencia de rutas redundantes y la recuperación
ante fallos en la topología de interconexión. Al
tratarse de un estándar en desarrollo, todavía no
existen en el mercado dispositivos compatibles
con AS. En este artículo presentamos un modelo
de esta arquitectura, en el cual se hace especial
hincapié en los aspectos propios de la gestión de
la red, como son el proceso de inicialización, el
descubrimiento de la topología, o la configuración
de los dispositivos.
1. Introducción
Las especificaciones de Advanced Switching han
sido desarrolladas por el ASI-SIG (Advanced
Switching Interconnect - Special Interest Group)
[1, 2]. A diferencia de otras tecnologías
emergentes, como InfiniBand [5] o Quadrics [8],
diseñadas “desde cero”, AS puede considerarse el
último paso en la evolución natural del bus PCI
tradicional. En concreto, AS hereda gran parte de
las características de los niveles físico y de enlace
de la tecnología PCI Express, ampliamente
implantada en el mercado actual. No obstante,
ofrece un espacio de aplicación mayor, que
incluye, entre otros, multiprocesamiento o
comunicaciones peer-to-peer.
Nuestro interés se centra en la disponibilidad
en AS. Una red AS necesita un gestor de red (FM,
fabric manager), que básicamente se encarga de
configurar y monitorizar los dispositivos de la
misma. Nos planteamos el diseño del
comportamiento del FM, en otras palabras, el
diseño del mecanismo de gestión para AS.
Para poder llevar a cabo una evaluación
exhaustiva de nuestras futuras propuestas, es
necesario disponer de una herramienta que refleje
fielmente todas las etapas en el mecanismo de
gestión de la red, desde el momento mismo en el
que se inicializan los dispositivos. Pensemos, por
ejemplo, en la ocurrencia de un fallo en alguno de
los dispositivos de la red. Un modelo realista
debería tener en cuenta el tiempo necesario para
descubrir la existencia del fallo, rehacer el
conjunto de rutas empleadas por los paquetes de
aplicación y distribuirlas a los elementos activos.
En este artículo se describe el estado actual de
dicha herramienta. El resto del trabajo se organiza
de la siguiente manera. En primer lugar, la sección
2 muestra la forma en la que hemos modelado
algunos aspectos de los dispositivos AS. A
continuación, la sección 3 describe los elementos
de gestión de AS que han sido incorporados a
nuestro modelo. La sección 4 detalla las tareas de
gestión que nuestro modelo deberá incluir.
Finalmente, se aportan algunas conclusiones y
trabajo futuro.
2. Modelo de dispositivos
Nuestro simulador ha sido desarrollado con la
herramienta de modelado y simulación OPNET
Modeler [7], e incluye un modelo de dispositivo
final (endpoint) y de conmutador (switch) AS. La
Figura 1 muestra el crossbar y dos de los 16
puertos del conmutador.
A la entrada de cada puerto, un selector deriva
los paquetes de control de flujo (DLLPs, data link
layer packet) a una unidad específica. El resto de
paquetes (TLPs, transaction layer packet) son
enviados al buffer asociado al canal virtual (VC,
virtual channel) que corresponda. El VC se
calcula en base al campo Traffic Class del paquete
y a unas tablas fijas de mapeo. Se han modelado
los tres tipos de VCs definidos en AS: BVC
(bypass capable unicast VC), OVC (ordered-only
unicast VC) y MVC (multicast VC).
Los paquetes unicast se encaminan al alcanzar
la cabecera del buffer de entrada. Esta operación
se realiza localmente empleando la información
incluida en la cabecera del paquete (como se verá
más tarde). Por su parte, los paquetes multicast
requieren la consulta de una tabla de
encaminamiento específica, almacenada en el
conmutador y establecida por el FM.
La unidad de arbitraje del crossbar gestiona el
cruce de paquetes desde los buffers de entrada a
los buffers de salida, teniendo en cuenta el espacio
disponible y la utilización exclusiva de los canales
internos.
La unidad de control de flujo (DLLP queue)
procesa DLLPs para habilitar/deshabilitar la
transmisión de TLPs por los canales de salida.
Además, periódicamente esta unidad transmite
DLLPs por el enlace, para actualizar en el vecino
el crédito disponible.
Por último, la unidad de arbitraje del canal de
salida decide cuál de los TLPs situados en los
buffers de salida (junto con DLLPs inyectados por
la unidad de control de flujo) será transmitido por
el enlace. Para ello, deberá tener en cuenta el
crédito disponible en los buffers de entrada del
vecino, que es notificado por la unidad de control
de flujo.
El resto de la sección describe con mayor
detalle ciertos aspectos relativos a la gestión de
los puertos que han sido incluidos en nuestro
modelo de AS.
2.1. Comportamiento de los puertos
La Figura 2 muestra los posibles estados de un
puerto. Una vez activado el dispositivo, comienza
la fase de inicialización de sus puertos, en la que
cada uno de ellos intenta sincronizarse con un
supuesto dispositivo conectado al otro extremo del
enlace. Para ello, el puerto parte del estado
DL_Inactive y, cada cierto tiempo, cambia a
DL_Init, enviando DLLPs a través del enlace. Si
no se obtiene una respuesta, el puerto vuelve al
estado DL_Inactive.
En caso de recibir una respuesta del puerto
vecino, comienza la fase de negociación del
número de canales virtuales que utilizarán en la
comunicación. Este proceso se detalla en la
sección siguiente.
Al finalizar la negociación, el puerto pasa a
estado DL_Protected. En este estado, además de
DLLPs, se permite la transmisión de paquetes de
gestión de red, utilizados para elegir el FM (PI-
0:0) y para descubrir y configurar los dispositivos
(PI-4).
Finalmente, cuando los dispositivos de la red
estén configurados, el FM ordenará al puerto
(mediante un paquete de gestión) el paso al estado
DL_Active. En este estado, el puerto está
completamente operativo, permitiendo la
transmisión de todo tipo de paquetes.
2.2. Proceso de negociación
La negociación entre los dispositivos conectados
al enlace se realiza por medio de paquetes de
Figura 1. Modelo de conmutador AS en OPNET
DL_Init
DL_Inactive DL_Active
DL_Protected
Reset
DL_Init
DL_Inactive DL_Active
DL_Protected
Reset
Figura 2. Comportamiento de un puerto
118 Redes y Comunicación
control de flujo (DLLPs) de tipo InitFC1 e
InitFC2, y se divide en dos fases. La primera fase
negocia el número de BVCs activos, mientras que
la segunda determina los OVCs y MVCs activos.
Se debe tener en cuenta que la negociación no se
realiza a nivel de canal virtual, sino a nivel de VC
Index. La Tabla 1 muestra la equivalencia entre
ambos valores.
VC Index Número de VC Tipo
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
BVCs
8 8 y 9
9 10 y 11
10 12 y 13
11 14 y 15
OVCs
12 16 y 17
13 18 y 19
MVCs
Tabla 1. Relación entre VC Index y número de VC
Al principio de cada una de las fases se
ejecuta lo que se denomina secuencia de
inicialización de canal virtual, compuesta por dos
estados. En el primer estado (FC_INIT1), el
dispositivo envía un DLLP InitFC1, comunicando
los créditos de los buffers asociados al VC Index
correspondiente, y espera una respuesta del
vecino, vía DLLP InitFC1 o InitFC2 de dicho VC
Index. Si transcurrido un tiempo no recibe
respuesta, reenviará el DLLP. Este proceso se
realiza hasta 8 veces y si el dispositivo no obtiene
respuesta el puerto pasará a estado DL_Inactive.
Cuando el dispositivo recibe la respuesta
almacena los créditos comunicados por su vecino
y pasa al segundo estado en la secuencia de
inicialización (FC_INIT 2). Ahora, el dispositivo
envía un DLLP InitFC2, que sólo difiere del
InitFC1 en el código que indica que es InitFC2. El
proceso de reenvío es exactamente igual que en el
primer estado sólo que la respuesta esperada
vendrá en forma de DLLP InitFC1 del siguiente
VC Index al que está tratando o de DLLP InitFC2
del VC Index tratado. A diferencia del primer
estado, cuando obtiene la respuesta no guarda los
valores de los créditos comunicados. Simplemente
sigue con el proceso de negociación en la fase en
que se encuentre.
En la primera fase (negociación de BVCs), si
un dispositivo recibe un DLLP InitFC1 o InitFC2
de su vecino indicando que el número de créditos
de los buffers asociados al canal es 0, indica que
ese canal virtual está inactivo en el vecino. A
partir de ese momento todos los DLLPs que reciba
en la primera fase deberán informar que el número
de créditos de los buffers asociados a los
sucesivos canales virtuales es 0, y por tanto,
dichos canales están inactivos. Si después de
recibir un 0 el dispositivo recibe un DLLP
indicando un crédito distinto de 0, se producirá un
error y el estado del puerto pasará a ser
DL_Inactive.
Análogamente, en la segunda fase (OVCs y
MVCs), cuando uno de los campos asociados a un
buffer de un DLLP InitFC1 o InitFC2 contiene un
valor 0, el dispositivo entiende que el canal del
dispositivo vecino al que se refiere está inactivo y
los sucesivos también.
Al final de las dos fases se habrá negociado el
número de canales virtuales que utilizarán los
vecinos en la comunicación. Este número
corresponde al máximo de canales virtuales de
cada tipo comunes. La diferencia entre las dos
fases es que al final de la segunda fase se realiza
una transformación de BVCs en OVCs. Esta
transformación se realiza tomando el número
común de los BVCs sobrantes en un dispositivo y
los OVCs sobrantes en el otro, y sólo se podrá
llevar a cabo si el número de créditos de la cola
ordered asociada al BVC es mayor o igual que el
número de créditos de la cola única asociada al
OVC.
2.3. Modelo de la unidad de control de flujo
La unidad de control de flujo (DLLP_queue) es la
encargada de modelar el mecanismo que
acabamos de describir, es decir, chequear el
estado del enlace para comenzar su inicialización,
además de comunicar al resto de unidades en los
puertos de entrada y salida cualquier cambio que
se produzca en el estado del puerto.
La Figura 3 muestra la máquina de estados
empleada para definir el comportamiento de la
unidad de control de flujo en OPNET. A
continuación se detallan cada uno de los estados:
x init: estado inicial de la máquina.
XVI Jornadas de Paralelismo, JP '2005 119
x idle: estado de reposo.
x link_check: como ya se ha descrito, cada
cierto tiempo (TIMEOUT1) se procede al
chequeo del enlace. Si el puerto está en estado
DL_Inactive, pasa a DL_Init y comienza la
inicialización de la unidad de control de flujo.
x incoming_DLLP: ha llegado un DLLP al
puerto. Dependiendo de su tipo (InitFC1,
InitFC2 o Update), guarda los datos
comunicados, activa los flags que indican el
tipo de paquete que ha llegado o actualiza los
créditos disponibles en el vecino según
corresponda.
x buffer_notif: la unidad de control de flujo
recibe una notificación del buffer de entrada
indicando una variación en su ocupación.
x fc_update: la unidad de control de flujo envía
un DLLP Update cada cierto tiempo
(TIMEOUT2), con objeto de comunicar al
vecino el crédito disponible en los buffers
asociados a los canales virtuales.
2.4. Encaminamiento unicast
AS emplea encaminamiento fuente. El dispositivo
final establece el valor de ciertos campos en el
paquete para definir el camino que éste debe
seguir para alcanzar su destino. El dispositivo
final puede obtener esta información, por ejemplo,
a partir de una tabla de encaminamiento local. La
Figura 4 muestra la cabecera de un paquete
unicast.
Cuando el paquete alcanza la cabecera de un
buffer de entrada en un conmutador, éste calcula
el puerto de salida, basándose en los campos Turn
Pool, Turn Pointer, Direction y en el puerto de
entrada empleado por el paquete. Si la dirección
del paquete es hacia delante (Direction = 0), la
fórmula utilizada para calcular el puerto de salida
será (1). Si por el contrario el paquete viaja hacia
atrás (Direction = 1), se utilizará la fórmula (2).
puerto_salida = (puerto_entrada +
valor_turno + 1) módulo n_puertos
(1)
puerto_salida = (puerto_entrada í
valor_turno í 1) módulo n_puertos
(2)
El valor n_puertos es el número de puertos del
conmutador. El valor_turno se extrae del Turn
Pool teniendo en cuenta el Turn Pointer y el
número de bits del conmutador; si un conmutador
tiene 2n
puertos, n es el número de bits del
conmutador. La extracción del valor_turno, el
valor del Turn Pointer en el nodo origen y en el
final, y el nuevo Turn Pointer modificado por el
conmutador, variarán según se trate de
encaminamiento hacia delante (forward) o hacia
atrás (backward).
x Direction = 0: El Turn Pointer indica la
posición dentro del Turn Pool del bit más
significativo del valor_turno. El número de
bits a extraer viene dado por el número de bits
del conmutador. El valor del Turn Pointer en
el origen del paquete es la suma de los bits de
todos los conmutadores que debe atravesar el
paquete, y en el final es 0. El nuevo Turn
Pointer se halla restando el número de bits del
conmutador al antiguo Turn Pointer.
x Direction = 1: El Turn Pointer indica la
posición dentro del Turn Pool del bit menos
significativo del valor_turno. De idéntica
forma que en encaminamiento hacia delante,
el número de bits a extraer es el número de
bits del conmutador. El valor del Turn Pointer
en el origen del paquete es 0, y en el final es la
suma de los bits de todos los conmutadores
que debe atravesar el paquete. El nuevo Turn
Pointer se halla sumando el número de bits
del conmutador al antiguo Turn Pointer.
Figura 3. Unidad de control de flujo
1
1
PI
PI
6
6
P
P
7
7
P
P
C
C
R
R
C
C
8
8
9
9
1
1
0
0
2
2
Turn Pool
Turn Pool
D
D
Traffic
Traffic
Class
Class
O
O
O
O
T
T
S
S
Credits
Credits
Required
Required
F
F
E
E
C
C
N
N
Turn Pointer
Turn Pointer
Header CRC
Header CRC
0
0
3
3
4
4
5
5
1
1
1
1
1
1
2
2
1
1
3
3
1
1
4
4
1
1
5
5
1
1
6
6
1
1
7
7
1
1
8
8
1
1
9
9
2
2
0
0
2
2
1
1
2
2
2
2
2
2
3
3
2
2
4
4
2
2
5
5
2
2
6
6
2
2
7
7
2
2
8
8
2
2
9
9
3
3
0
0
3
3
1
1
1
1
PI
PI
6
6
P
P
7
7
P
P
C
C
R
R
C
C
8
8
9
9
1
1
0
0
2
2
Turn Pool
Turn Pool
D
D
Traffic
Traffic
Class
Class
O
O
O
O
T
T
S
S
Credits
Credits
Required
Required
F
F
E
E
C
C
N
N
Turn Pointer
Turn Pointer
Header CRC
Header CRC
0
0
3
3
4
4
5
5
1
1
1
1
1
1
2
2
1
1
3
3
1
1
4
4
1
1
5
5
1
1
6
6
1
1
7
7
1
1
8
8
1
1
9
9
2
2
0
0
2
2
1
1
2
2
2
2
2
2
3
3
2
2
4
4
2
2
5
5
2
2
6
6
2
2
7
7
2
2
8
8
2
2
9
9
3
3
0
0
3
3
1
1
Figura 4. Cabecera de un paquete unicast
120 Redes y Comunicación
El campo Turn Pool no cambia dentro de un
conmutador, solamente sufre modificación el
valor del campo Turn Pointer. La Figura 5
muestra un ejemplo de encaminamiento hacia
delante. En cada conmutador intermedio, se
muestra la variación en el Turn Pointer y los bits
empleados para obtener el puerto de salida
(valor_turno).
3. Modelo de la capa de gestión
La gestión de una red AS tiene como objetivos
principales el descubrimiento, la configuración y
la activación de los dispositivos pertenecientes a
la red. Para garantizar una alta disponibilidad,
dicha gestión también cubre el restablecimiento de
rutas ante cambios topológicos, sin necesidad de
una intervención externa.
3.1. Entidades de gestión
El gestor de red (FM, fabric manager) es el
encargado de ejecutar las tareas de supervisión y
mantenimiento de la red. Se trata de una entidad
software alojada en uno de los dispositivos finales
(ver Figura 6) y conocida por el resto de
dispositivos de la red.
Existe otra entidad dedicada a la gestión de la
información local (que en nuestro modelo
denominamos device manager) presente en todos
los dispositivos (véanse Figuras 6 y 7). Su tarea es
aplicar las acciones requeridas por el FM,
Figura 5. Ejemplo de encaminamiento unicast
Figura 6. Ubicación del FM y del gestor en el dispositivo final
XVI Jornadas de Paralelismo, JP '2005 121
mediante el uso de paquetes de gestión. Para ello,
el device manager manipula la información
existente en cada dispositivo, que es almacenada
en forma de estructuras de datos (capability
structures) descritas posteriormente.
El proceso de elección del gestor de red está
completamente definido en la especificación de
AS. Para este fin, se realiza una exploración que
genera un árbol de expansión (ST, spanning tree)
a partir de cada dispositivo candidato a ser gestor
de red. Estos dispositivos crearán un paquete de
tipo broadcast (PI-0:0) que se propagará a toda la
red. Estos paquetes son utilizados para negociar la
propiedad de la red o una parte de la misma. La
arquitectura AS soporta un máximo de 16 STs,
aunque sólo es obligatorio implementar los
árboles ST0 y ST1, cuyos propietarios son el FM
primario y secundario respectivamente. El FM
secundario se activaría en caso de caída del
principal.
La gestión de la red puede realizarse forma
centralizada, distribuida e híbrida [9]. En un
modelo centralizado, existirá una única entidad
responsable de ejecutar todas las operaciones
relacionadas con la gestión de la red. Por contra,
en un modelo distribuido se pueden encontrar
varios propietarios que gestionen la red AS, cada
uno de los cuales controla una porción de la
misma. Las responsabilidades de éstos están
definidas por las políticas de la red, y pueden no
tener constancia de algunas conexiones activas.
Además, puede existir un gestor de red de alto
nivel que coordine los anteriores. Una gestión
híbrida pretendería aunar las ventajas de los
esquemas centralizado y distribuido.
3.2. Capability structures
Cada dispositivo dispone de varias estructuras de
datos (capability structures), usadas para
almacenar sus características e información de
control. Desde el punto de vista de la gestión de la
red, las estructuras más interesantes son baseline y
spanning tree. Su organización y funcionalidad
están completamente detalladas en la
especificación de AS. Dichas estructuras están
incorporadas en nuestro modelo y se describen a
continuación.
La estructura baseline device es implementada
en todos los dispositivos de la red, conteniendo
información de control y de estado. En líneas
generales, dicha estructura está compuesta por
registros con información relativa a su
identificación, tipo de dispositivo, máximo
tamaño de paquete permitido y configurado en
cada tipo de canal virtual, identificador de
dispositivo (EUI, Extended Unique Identifier),
número de puertos, etc. Además, para cada puerto
activo en el dispositivo se implementan registros
con información relativa a la velocidad y ancho de
banda máximo y negociado del enlace, y su estado
actual.
La estructura spanning tree también se
implementa en todos los dispositivos, y contiene
información sobre cada uno de los STs a los que
pertenece el dispositivo. En concreto, en cada
entrada de esta tabla se almacena la forma de
interaccionar con el propietario del ST cuando sea
necesario. Un ejemplo de esta necesidad es la
notificación de eventos, que se verá más tarde.
3.3. Paquetes PI-4
Los paquetes PI-4 (Protocol Interface 4) se
utilizan para la configuración y el control de los
dispositivos. Con este tipo de paquetes, el FM
puede consultar o modificar las estructuras de
datos de los dispositivos. Son capaces de transferir
datos de distintos tamaños, desde un byte hasta
bloques de ocho palabras de 32 bits.
La especificación de AS define
completamente los paquetes (PI-4). Sin embargo,
la forma su forma de uso no está detallada. Todos
los dispositivos de la red deben ser capaces de
recibir peticiones de datos PI-4 y responder a
ellas. La generación de paquetes PI-4 es opcional
en los dispositivos finales, y en los conmutadores
no está permitida.
Las operaciones realizadas con paquetes PI-4
incorporadas en nuestro modelo son read request,
Figura 7. Ubicación del gestor en el conmutador
122 Redes y Comunicación
write request, read completion with data y read
completion with error.
4. Tareas de gestión
Nuestro modelo no implementa en la actualidad
las tareas de gestión. A continuación se describen
brevemente en qué consisten exactamente estas
actividades.
4.1. Proceso de descubrimiento
Una vez elegido, la primera tarea del FM primario
consiste en iniciar un proceso de descubrimiento
de la red, durante el cual identificará todos los
dispositivos existentes en la misma. En concreto,
el FM debe enviar paquetes PI-4 con el tipo de
operación read request, para obtener información
topológica de cada dispositivo (identificador de
dispositivo, número de puertos activos,…). Cada
device manager responde a estos mensajes con
paquetes PI-4 de tipo read completion with data.
La implementación concreta del proceso de
exploración de la topología no está detallada en la
especificación de AS, y dependerá en gran medida
del modelo de FM empleado (centralizado,
distribuido o híbrido).
Para que el FM pueda albergar la información
topológica de cada dispositivo de la red, se ha
implementado la clase Fabric_Topology, que
contiene una lista de nodos gestionada de manera
dinámica. Cada nodo de la lista es una estructura
de datos que contiene el EUI, tipo de dispositivo,
propietario actual, máximo tamaño de paquete
permitido y activo para cada tipo de canal virtual,
etc. Esta estructura también contiene una lista
dinámica en la que, para cada puerto activo, existe
una estructura con cierta información sobre el
dispositivo con el que se comunica (identificador,
número de puerto, parámetros del enlace que los
conecta,…).
Los métodos implementados en esta clase
serán utilizados para manejar de forma más
sencilla la información topológica de la red
durante el descubrimiento y la configuración de
los dispositivos. A esta clase se le ha dotado de
funcionalidad para añadir o eliminar nodos,
obtener información sobre un nodo determinado,
comprobar si existe un enlace entre dos
dispositivos de la red, obtener información sobre
un puerto concreto en un nodo, etc.
4.2. Proceso de rutado
En nuestro modelo, una vez finalizado el proceso
de descubrimiento, el FM deberá obtener las rutas
que emplearán los paquetes para alcanzar su
destino dentro de la red.
Es deseable que el conjunto de rutas obtenido
sea libre de bloqueo [4]. En este caso, al tratarse
de encaminamiento fuente, no es posible el uso de
algoritmos de encaminamiento adaptativos.
Por último, debemos tener en cuenta que las
prestaciones del mecanismo de gestión completo
dependerán en gran medida del tiempo de
cómputo de las nuevas rutas. Por muy eficaz que
sea, un algoritmo de encaminamiento lento no es
en absoluto deseable.
4.3. Configuración de dispositivos
La configuración (y posterior activación) de los
dispositivos de la red es también misión del FM
primario. De nuevo, para esta tarea se emplearán
paquetes PI-4, en este caso de tipo write request.
Nuestro interés se centrará en la distribución
de las rutas a los dispositivos finales (para el
encaminamiento unicast). Recordemos que son
ellos los que deben inicializar los campos de la
cabecera del paquete que determinan el camino a
seguir.
El mecanismo de distribución de rutas
también debe ser libre de bloqueo. En este
sentido, puede optarse por emplear un proceso de
reconfiguración estática tradicional [10], o bien
adaptar a este nuevo entorno alguna de las
propuestas existentes para la reconfiguración
dinámica de la red. En [3, 6] pueden encontrarse
algunos ejemplos.
4.4. Detección de cambios topológicos
Una vez configurada y activada la red, el FM
deberá pasar a monitorizar su estado, actualizando
las rutas en el caso de que ocurra algún evento que
altere su topología.
Con objeto de detectar cambios en la
condiciones de la red mediante la notificación de
eventos, se implementarán los paquetes PI-5
(Protocol Interface 5). Su misión principal es la
de informar sobre condiciones de excepción
sucedidas en algún punto de la red, por ejemplo,
XVI Jornadas de Paralelismo, JP '2005 123
interrupciones, notificaciones de estado o errores
de cualquier tipo.
Existen dos tipos de eventos utilizados por
este protocolo. El primero genera eventos basados
en estado hacia un destino fijo, generalmente el
FM o un supervisor. El segundo tipo de eventos se
basa en informar al dispositivo fuente de un
paquete sobre la condición de excepción sufrida
(encaminamiento backward).
5. Conclusiones
Advanced Switching se perfila como el nuevo
estándar de interconexión de dispositivos que
sustituirá al bus PCI clásico, siendo aplicable
también en entornos como las redes SAN o los
clusters de estaciones de trabajo.
El modelo presentado en este trabajo está
enfocado a la evaluación de mecanismos de
gestión para esta nueva tecnología, si bien
también podría servir para evaluar otros aspectos
clave de esta arquitectura.
6. Agradecimientos
Este trabajo ha sido financiado por el proyecto
TIC2003-08154-C06-02 del Ministerio de Ciencia
y Tecnología.
Referencias
[1] ASI Special Interest Group. http://www.asi-
sig.org
[2] ASI Special Interest Group. Advanced
Switching Core Architecture Specification
Revision 1.0. December 2003.
[3] Bermúdez, A., Casado, R., Quiles, F. J.
Distributing InfiniBand forwarding tables. In
Proceedings of the EuroPar 2004 Conference.
Springer, August 2004.
[4] Duato, J., Yalamanchili, S., Ni, L.
Interconnection networks: an engineering
approach. Morgan Kaufmann Publishers.
August 2002.
[5] InfiniBand Architecture Specification Release
1.1. InfiniBand Trade Association. November
2002. http://www.infinibandta.org
[6] Lysne, O., et al. Simple deadlock-free
dynamic network reconfiguration. In
Proceedings if the International Conference on
High Performance Computing. December
2004.
[7] OPNET Modeler Documentation. OPNET
Technologies, Inc. http://www.opnet.com/
[8] Petrini, F., et al. The Quadrics network: high-
performance clustering technology. IEEE
Micro. January 2002.
[9] Rooholamini, M. Advanced Switching: a new
take on PCI Express. October 2004.
http://www.asi-sig.org/press/Articles/
[10] Schroeder, M. D., et al. Autonet: A high-
speed, self-configuring local area network us-
ing point-to-point links. IEEE Journal on
Selected Areas in Communications, vol.9, no.
8. October 1991.
124 Redes y Comunicación
Gaussian Interconnection Networks
R. Beivide, C. Martínez, E. Vallejo C. Izu
Universidad de Cantabria The University of Adelaide
Avenida de los Castros s/n Dept. Of Computer Science
39005 Santander. Spain. Adelaide, SA 5005. Australia
mon, carmenmf, enrique@atc.unican.es cruz@cs.adelaide.edu.au
Abstract: This paper explores dense Gaus-
sian Networks, which are interconnection net-
works based on dense Circulant graphs of de-
gree four. Gaussian networks exhibit better
distance related characteristics than equiva-
lent topologies such as Tori. We will show
that the Gaussian integers, or the set of com-
plex numbers with integer coefficients, consti-
tute the appropriate mathematical model to
deal with these Circulant graphs. Labeling
the nodes in a Circulant graph by means of
Gaussian integers provides a network in which
nodes are identified by their integer coordi-
nates in the plane. By using this new label-
ing we address two important issues: unicast
packet routing and optimal broadcast routing.
1 Introduction
Nowadays, interconnection networks have an
increasing impact on multiple parallel com-
puting systems. In the on-chip arena, net-
works are used in the design of systems on
chip, cluster microprocessors and on-chip mul-
tiprocessors. Input/output devices begin to be
connected to other computer subsystems by
means of switched networks. Clusters of com-
puters, cc-NUMA multiprocessors and mas-
sively parallel processors rely on the effective-
ness of their interconnection mechanisms. In
addition, switch fabrics for local, metropoli-
tan and wide area networks are beginning to
be designed around multistage and direct in-
terconnection networks.
Graph theory constitutes a powerful tool
for modeling networks, processors being rep-
resented as graph nodes and communication
links as the edges connecting them. Three
basic graph parameters are diameter, average
distance and connectivity. Diameter and aver-
age distance should be low to minimize com-
munication delays and connectivity should be
as high as possible for robustness. In partic-
ular, Circulant graphs have been extensively
studied for decades due to their optimal fault-
tolerance capabilities. The term Circulant
comes from the nature of its adjacency ma-
trix; a matrix is Circulant if all its rows are
periodic rotations of the first one.
The Illiac IV, probably the most popular
and innovative parallel computer of its time,
used a degree four Circulant graph of 64 nodes.
Hundreds of parallel machines using differ-
ent networks have been designed in the last
decades. Meshes, Tori and Hypercubes were
among the most popular. Nowadays, hy-
percube architectures have declined in favor
of lower degree topologies such as Tori and
Meshes that are being used in the design of
most recent high-end supercomputers [1], [6].
We consider in this research a subfamily of
degree four Circulant graphs. The members
of this subfamily are dense graphs, which are
the graphs containing the maximum number
of nodes for a given diameter. Hence, they
have minimal diameter among all Circulants
of degree four. We will show how the Gaus-
sian integers, or the subset of the complex
numbers with both real and imaginary integer
parts, constitutes the appropriate mathemati-
cal model to deal with these Circulant graphs.
For this reason, we denote these graphs as
Gaussian networks. Gaussian networks can be
successfully applied to the design and model-
ing of parallel systems as they exhibit remark-
able topological improvements over other de-
gree four graphs such as Tori. For the same
number of nodes and links the diameter of a
Gaussian network is only about 1
√
2
the di-
ameter of its Torus counterpart. Its richer
connectivity together with this lower diame-
ter make Gaussian networks topologically su-
perior to Tori for either individual or collective
communications, as we will show in this paper.
In addition, in [13] the problem of the optimal
resource placement in Gaussian networks was
solved.
The rest of the paper is organized as fol-
lows. Section 2 describes some previous work
and Gaussian networks. Section 3 presents an
optimal routing algorithm for unicast traffic.
Section 4 describes an optimal mechanism to
implement collective communications in such
networks. Finally, Section 5 concludes the pa-
per summarizing our main achievements.
2 Gaussian Networks
Next, we describe relevant previous work on
which this research is based. Secondly, we in-
troduce Gaussian networks describing a sub-
stantial part of their mathematical founda-
tions.
2.1 Previous Work on Circulants of De-
gree Four
We define a Circulant graph with N vertices
and jumps {j1, j2, . . . , jm} as an undirected
graph in which each vertex n, 0 ≤ n ≤ N − 1,
is adjacent to all the vertices n ± ji mod N,
with 1 ≤ i ≤ m. We denote this graph
as CN (j1, j2, . . . , jm). Rings and complete
graphs of any size are particular cases of Cir-
culants.
The vertex-symmetry of Circulants allows
their analysis starting from any vertex (node
zero unless any other is stated), which simpli-
fies their study. As the degree of a CN (j1, j2)
graph is four, there can be, at most, 4d dif-
ferent nodes at distance d from node 0. Thus,
for a given diameter k the maximum number
of nodes of a CN (j1, j2) graph is:
N = 2k2
+ 2k + 1 = k2
+ (k + 1)2
(1)
We call a graph containing such a maximum
number of nodes a dense Circulant graph. Dif-
ferent authors have shown that CN (k, k + 1)
graphs with N = 2k2
+ 2k + 1 are dense de-
gree four Circulants [3], [4]. CN (k, k+1) dense
graphs have minimum diameter among all the
degree four Circulants, so we say they are op-
timal. To obtain implementable lay-outs, Cir-
culants of degree four can be transformed in
mesh-like interconnection networks as consid-
ered in [2], [7], [8]. From Equation (1) it can be
inferred that the diameter, k, of a CN (k, k+1)
graph is k =
√
2N−1−1
2
= 


N
2
.
2.2 Gaussian Networks
Now, we describe how dense Circulants can be
viewed as bi-dimensional meshes with wrap-
around links in which nodes are labeled by
means of their integer coordinates in the plane.
To this aim we employ a subset of the Gaus-
sian integers for labeling the network nodes.
The Gaussian integers Z[i] is the subset of
the complex numbers with integer real and
imaginary parts, that is, Z[i] := {x+yi| x, y ∈
Z}. Z[i] is a Euclidean domain and the norm is
defined as N(x+yi) = x2
+y2
. Then, for every
α, π ∈ Z[i] with π = 0 there exist q, r ∈ Z[i]
such that α = qπ +r with N(r) < N(π). This
means that there exists a Euclidean division
algorithm in Z[i] in a similar way as for inte-
gers. Then, we can define the modulo opera-
tion over the Z[i] set. Given 0 = π ∈ Z[i], we
consider the finite set of the Gaussian integers
modulo π, or Z[i]π := {α mod π | α ∈ Z[i]}.
For any α ∈ Z[i] and π = k + (k + 1)i, the
unique representant with smallest norm of its
class in Z[i]π or α mod π, can be computed as
α mod π = α − [ απ∗
k2+(k+1)2 ]π. The operation
[c + di] denotes rounding in Gaussian integers
and is defined by [c + di] = [c] + [d]i with [c]
denoting rounding to the closest integer. Be-
sides, π∗
is the conjugate of π.
126 Redes y Comunicación
Now, we define a new family of dense Cir-
culant graphs by using these Gaussian integer
subsets in a very natural way.
Definition 1 Given π = k + (k + 1)i ∈ Z[i]
we define the graph Gπ = (V, E) where:
i) V = Z[i]π is the node set, and
ii) E = {(α, β) ∈ V × V | (β − α) ≡
±1, ±i mod π} is the edge set.
We call Gπ the dense Gaussian network gen-
erated by π.
Theorem 2 Let k be a positive integer and
N = k2
+ (k + 1)2
. We have that CN (k, k +
1) and Gk+(k+1)i are isomorphic graphs. The
graph isomorphism is
Φ : ZN −→ Z[i]k+(k+1)i
j −→ x + yi mod π
where j ≡ kx + (k + 1)y mod N.
Figure 1 shows a G3+4i which is isomorphic
to C25(3, 4). We have maintained the original
labeling of its nodes to see the effect of the
previous isomorphism. Nevertheless, it can be
seen that node zero (0,0) is located in the cen-
ter of the network and the remaining nodes
are labeled by Gaussian integers according to
their integer coordinates in the complex plane.
Hence, nodes in a dense Gaussian network will
be labeled by all the possible (x, y) integer
pairs such that |x| + |y| ≤ k. Observe the
presence of wrap-around links for maintaining
the graph connectivity.
As a consequence of the previous graph iso-
morphism, we have that the distance between
nodes α and β in Gπ is D(α, β) = min{|x| +
|y| | β − α ≡ x + yi mod π}.
3 Unicast Routing
There are many applications over Gaus-
sian networks that can benefit from a two-
dimensional labeling of the nodes. We con-
sider in this Section the unicast packet rout-
ing.
Optimal routing algorithms have been pro-
posed for Circulant graphs in [2], [8]. All of
them consider graphs whose nodes are labeled
by integers and implement the Euclidean di-
vision algorithm which has a high computa-
tional cost. In order to obtain an algorithm
just based on integer sums and comparisons,
we will consider the routing problem in terms
of Gaussian integers.
To send a packet from α to β we need to ob-
tain γ = (β − α) mod π with |Re(γ)|+|Im(γ)|
minimum. Once γ is obtained, Re(γ) repre-
sents the number of links that the packet must
traverse along the real axis (X) and Im(γ) the
number of links along the imaginary axis (Y ).
Then, the network interface will produce a
packet header containing two fields, ∆Re and
∆Im, which indicate the hops to be taken in
each axis; their signs indicate directions E/W
and N/S. Routers will process the header in-
formation in the same way as in a Torus, decre-
menting the corresponding field header before
sending the packet to the selected neighbor.
A packet with ∆Re = 0 and ∆Im = 0, will
have reached its destination and will be deliv-
ered. This reasoning describes a mechanism
for obtaining routing records which makes use
of integer divisions. Square brackets in the al-
gorithm mean rounding operations.
Now, we present a new algorithm in terms of
the nodes’ integer coordinates which is based
just on sums and comparisons. Such an al-
gorithm comes from the fact that the mini-
mal path between two nodes, α = x + yi and
β = x
+ y
i, always results in one of nine pos-
sibilities. Figure 2 illustrates the routing al-
gorithm. Given π = k + (k + 1)i, and γ =
β −α = x
−x+(y
−y)i, the vector γ is either
inside the region 0 or in any of the other eight
neighbor regions labeled in the Figure from 1
to 8. Each of these eight diamond regions cor-
responds to the following transformations of π:
π×(±1), π×(±i), π×(±1±i). Then, if vector
γ is inside region 0, the routing record will be
∆Re := x
− x, ∆Im := y
− y. Otherwise,
the minimal path should jump through one or
more wrap-around links. Then, we have to
compute eight more tentative routing records
by adding to (∆Re, ∆Im) each one of the vec-
tors resulting from the previous transforma-
tions of π. Note that just one of the nine vec-
XVI Jornadas de Paralelismo, JP '2005 127
tors will have |∆Re|+|∆Im| ≤ k, which per-
mits to select the correct one. The Algorithm
6 describes this simple routing mechanism.
Such a routing can be easily implemented
in hardware. A parallel implementation using
nine adders and nine comparators will pro-
vide the fastest solution. Figure 3 presents
an sketch of such a routing record generator
circuit. Cheaper alternatives can also be im-
plemented. Anyway, this routing reduces the
complexity of previous mechanisms by avoid-
ing integer divisions and it also provides an
scalable implementation.
4 Collective Communications
In this Section we present an optimal broad-
cast routing for Gaussian networks. Effi-
cient implementation of collective communi-
cations for parallel computing is a research
topic that has received increasing attention
in recent years. Broadcast communications
are employed in many parallel applications
such as matrix multiplication, LU factoriza-
tion, Householder transformations and other
basic linear algebra algorithms. Moreover,
important architectural issues such as main-
taining cache coherency and supporting bar-
rier synchronization in multiprocessors may
depend on the ability of the network to per-
form broadcasting communication [12].
Based on a known proof of the Pythagorean
Theorem, we now present an optimal one-to-
all broadcast algorithm, which is extremely
simple and symmetrical for every packet and
every node. Hence, it can be easily imple-
mented in hardware. This algorithm exploits
the optimal nature of Gaussian networks for
embedding trees in them.
As equation (1) tells us, dense Gaussian net-
works have a number of nodes which is the sum
of two consecutive squares. Hence, in our case,
a and b are respectively k + 1 and k, and con-
sequently, (k + 1 − k)2
= 1. This suggests to
us that, once an arbitrary node is fixed, the
rest of the network nodes should be divided
into four different subsets having k(k+1)
2
nodes
each. This corresponds to the area of a right-
angled triangle of consecutive integer legs k
and k + 1. We can identify in Figure 4 a uni-
tary central square ((k +1−k)2
= 1) in which
node (0,0) is located and four "discrete" right-
angled triangles with identical legs of size k.
We denote this special triangle as a k-triangle.
It is easy to see that the area of a k-triangle
equals the area of a right-angled triangle with
legs of length k and k + 1. This geometric
analysis allows us to present a Gaussian net-
work of diameter k as a central node plus four
k-triangular quadrants. The number of nodes
of each quadrant corresponds to the sum of
the first k integers or the Triangular number
of order k.
We will refer to Figure 4 to describe our
one-to-all broadcast algorithm. In this Figure,
node 0 has four different neighbors: (1), (-1),
(i) and (-i). Each of these nodes is located on
the right angle of a different k-triangular quad-
rant: node 1 belongs to quadrant SE, node i
belongs to NE, node -1 belongs to NW and
node −i belongs to SW. From each one of these
nodes located at distance 1 from node 0 we
can visit d different nodes at distance d, with
1 < d ≤ k.
We assume a router model with full-duplex
links and all-port capability. Routers will sup-
port both unicast and broadcast routing, with
the first header bit in every packet (B/U) indi-
cating the class of routing service. In the case
of broadcast routing, the second field in the
packet header, denoted as distance, will be set
to the network diameter, k, when the broad-
cast communication starts. Before each new
hop, every router will decrement this field and
when distance reaches zero, the broadcast will
have finished. The third and last field in the
packet header, denoted as NSEW, has four
bits to indicate to the router the output ports
to which the packet will be forwarded. The re-
sulting header is quite compact: log2 k plus 5
bits, nearly the same bits as needed for record-
ing routing records for unicast traffic.
Any node starting a broadcast injects a
packet to its local router with B/U = 1,
distance = k and NSEW = 1111. Every node
receiving a packet with B/U = 1, will perform
the one-to-all routing algorithm described in
Figure 4.
128 Redes y Comunicación
The broadcast occurs in k steps as Figure
4 reflects. In each step d, the 4d nodes at
distance d from the source are reached with
no contention. In the first step, the source
node broadcasts in four directions, reaching
the right angle of each k-triangle. In each k-
triangle, the row (or column) reached by node
(0,0) will continue to broadcast in both dimen-
sions, while the other nodes will only propa-
gate the packet along their column (or row).
For example, nodes i and 2i on the NE trian-
gle broadcast to the North and East and node
1+i only to the East, so that node 1+2i does
not receive a duplicate. Note that the utiliza-
tion of the network links is balanced, as in each
step d, there are d packets traveling in each of
the network quadrants. This means it is possi-
ble to make a balanced use of the N, S, E and
W network links when all nodes broadcast at
once.
By using broadcast bitmasks at each out-
put port, set to the values shown in the first
step of our algorithm, i.e. North output has
a B_mask = 1010, a simple hardware imple-
mentation is obtained in which the broadcast
packet is sent to the outputs whose bit is set in
the header field NSEW, and then each output
port will update that header field by doing a
logical AND operation with its own B_mask.
As there are no duplicates, this algorithm
uses N − 1 = 2k2
+ 2k links which is the op-
timal number for a one-to-all operation. Be-
sides, this algorithm is universal for every node
and ends in time proportional to the diameter
k, which is

N
2
. A similar broadcast in a
Torus needs
√
N steps. In addition, a hard-
ware implementation of our one-to-all broad-
cast is much simpler than equivalent optimal
mechanisms for Torus networks [18].
Unicast and broadcast routing algorithms
for Gaussian networks and Tori have been im-
plemented in a functional network simulator
using Adaptive Bubble routing [15] for avoid-
ing packet deadlock. Simulation results always
reported the gains dictated by the different
topological characteristics of both networks.
5 Conclusions
This paper has explored dense Gaussian net-
works, which improve the diameter of their
Tori counterparts by a factor
1
√
2
. Distances
in Hypercubes, Tori and Meshes can be seen
as Hamming, Lee and Manhattan metrics, re-
spectively. These metrics permit us to deal
with coordinates when analyzing and exploit-
ing such networks. In the same way, we have
proposed a new distance over the Gaussian in-
tegers as the appropriate metric to analyze and
exploit dense Circulant networks. This ap-
proach clearly spreads the application range
of such networks.
We have considered the problems of uni-
cast and broadcast routing as well as the per-
fect placement of resources to illustrate the
application of this new metric based on inte-
ger coordinates. In addition, simple and effi-
cient adaptive routing and deadlock-avoidance
mechanisms similar to those used in Tori
can be easily adapted to Gaussian networks.
Hence, the topological advantages of Gaussian
networks can translate in performance gains
when considering real implementations.
Other applications, such as the embedding
of commonly used communication topologies
in parallel algorithms, can also be successfully
solved by using the Gaussian integers. Meshes,
Rings of different sizes, Trees and Hamiltonian
circuits, among others, can be optimally em-
bedded in Gaussian networks, as will be pre-
sented in a forthcoming paper.
Acknowledgment
C. Martinez is supported by the Spanish Min-
istry of Education under grant FP-2001-2482.
R. Beivide is supported by the Spanish Sci-
ence and Education Ministry under contract
TIN2004-07440-C01-01 and by the HiPEAC
European Network of Excellence. J. Gutierrez
is partially supported by the Spanish Ministry
of Science and Technology under grant project
MTM2004-07086. E. Vallejo is supported by
the Spanish Ministry of Education under grant
AP-2004-6907.
XVI Jornadas de Paralelismo, JP '2005 129
References
[1] N.R. Adiga et al. "An overview of the
BlueGene/L Supercomputer". Supercom-
puting 2002 Technical Papers, November
2002.
[2] R. Beivide, E. Herrada, J.L. Balcázar and
A. Arruabarrena. "Optimal Distance Net-
works of Low Degree for Parallel Comput-
ers". IEEE Transactions on Computers,
Vol. C-40, No. 10, pp. 1109-1124, 1991.
[3] J.-C. Bermond, G. Illiades and C. Peyrat.
"An optimization problem in distributed
loop computer networks". 3rd Inter-
antional Conference on Combinatorials
Mathematics. New York Academy of Sci-
ences, pp. 1-13, 1985.
[4] F. T. Boesch and J. Wang. "Reliable cir-
culant networks with minimum transmis-
sion delay". IEEE Transactions on Cir-
cuit and Systems. Vol. 32, pp. 1286-1291,
1985.
[5] B. Bose, B. Broeg, Y. Known and
Y. Ashir. "Lee Distance and Topologi-
cal Properties of k-ary n-cubes". IEEE
Transactions on Computers, Vol. 44, No.
8, pp. 1021-1030, 1995.
[6] B. Camp, J. Tomkins "The Red Storm
Computer Architecture and its Imple-
mentation". Conference on High-Speed
Computing. April 21 -24, 2003.
[7] Z. Cvetanovic. "Performance Analysis of
the Alpha 21364-based HP GS1280 Mul-
tiprocessor". Proceedings of the 30th An-
nual International Symposium on Com-
puter Architecture. pp. 218-228, 2003.
[8] M.A. Fiol, J.L. Yebra, I. Alegre and M.
Valero. "A Discrete Optimization Prob-
lem in Local Networks and Data Align-
ment". IEEE Transactions on Computers,
Vol. 36, No. 6, pp. 702-713, 1987.
[9] G. H. Hardy and E. M. Wright. "An In-
troduction to the Theory of Numbers".
Oxford 1979, 5th Ed.
[10] K. Huber. "Codes Over Gaussian Inte-
gers". IEEE Transactions on Information
Theory, vol. 40, no. 1, pp. 207-216, Jan-
uary 1994.
[11] C. M. Lau and G. Chen. "Optimal Lay-
outs of Midimew Networks". IEEE Trans-
actions on Parallel and Distributed Sys-
tems, Vol. 7, No. 9, pp. 954-961, 1996.
[12] M. M. K. Martin, M. D. Hill, and D.
A. Wood. "Token Coherence: Decoupling
Performance and Correctness". 30th An-
nual International Symposium on Com-
puter Architecture (ISCA-30), pp. 182-
193, 2003.
[13] C. Martínez, R. Beivide, J. Gutierrez
and E. Gabidulin. "On the Perfect t-
Dominating Set Problem in Circulant
Graphs and Codes over Gaussian In-
tegers". Accepted for presentation at
ISIT’05, Australia.
[14] V. Puente, C. Izu, J.A. Gregorio, R. Bei-
vide, J.M. Prellezo and F. Vallejo. "Re-
arranging Links to Improve the Perfor-
mance of Parallel Computers: The Case
of Midimew Networks". Proc. of Inter-
national Conference on Supercomputing.
ICS’2000. pp. 44-53. 2000.
[15] V. Puente, J.A. Gregorio, F. Vallejo and
R. Beivide. "Immunet: A Cheap and
Robust Fault-Tolerant Packet Routing
Mechanism". 31th Annual International
Symposium on Computer Architecture
(ISCA-31), pp. 198-209, 2004.
[16] C. Sequin. "Doubly Twisted Torus Net-
works for VLSI Processor Arrays". Pro-
ceedings of the 8th Annual International
Symposium on Computer Architecture,
pp. 471-480, 1981.
[17] C.K. Wong and D. Coppersmith. "A
Combinatorial Problem Related to Multi-
module Memory Organizations". Journal
of the ACM, Vol. 21, No. 3, pp. 392-402,
1974.
130 Redes y Comunicación
[18] Y. Yang and J. Wang. "Efficient All-to-
All Broadcast in All-Port Mesh and Torus
Networks ". The Fifth International Sym-
posium on High Performance Computer
Architecture. 1999 Orlando, Florida.
6 Algorithms and Figures
∆x := x
− x; ∆y := y
− y;
DO IN PARALLEL:

∆x0 := ∆x − 0;
∆y0 := ∆y − 0;

∆x1 := ∆x − k;
∆y1 := ∆y − (k + 1);

∆x2 := ∆x + 1;
∆y2 := ∆y − (2k + 1);

∆x3 := ∆x + (k + 1);
∆y3 := ∆y − k;

∆x4 := ∆x + (2k + 1);
∆y4 := ∆y + 1;

∆x5 := ∆x + k;
∆y5 := ∆y + (k + 1);

∆x6 := ∆x − 1;
∆y6 := ∆y + (2k + 1);

∆x7 := ∆x − (k + 1);
∆y7 := ∆y + k;

∆x8 := ∆x − (2k + 1);
∆y8 := ∆y − 1;
END DO IN PARALLEL
∆Re := xi



 |∆xi| + |∆yi| < k;
∆Im := yi



 |∆xi| + |∆yi| < k;
Algorithm 1: Unicast Routing Algorithm
in Terms of Sums and Comparisons.
if distance = k then
distance := distance − 1;
Send packet to N with
NSEW = 1010 (NE Triangle);
Send packet to W with
NSEW = 1001 (NW Triangle);
Send packet to S with
NSEW = 0101 (SW Triangle);
Send packet to E with
NSEW = 0110 (SE Triangle);
end
if distance = 0 then
CONSUME packet;
end
if 0 < distance < k then
CONSUME packet;
distance := distance − 1;
- Incoming packets with
NSEW = 1010: Forward to N;
Forward to E with NSEW = 0010;
- Incoming packets with
NSEW = 1001: Forward to W;
Forward to N with NSEW = 1000;
- Incoming packets with
NSEW = 0101: Forward to S;
Forward to W with NSEW = 0001;
- Incoming packets with
NSEW = 0110: Forward to E;
Forward to S with NSEW = 0100;
- Incoming packets with
NSEW = 1000 (0100, 0010, 0001):
Forward to N (S,E,W);
end
Algorithm 2: One-to-All Routing Algo-
rithm.
XVI Jornadas de Paralelismo, JP '2005 131
Figure 1: Gaussian network for k = 3.
Figure 2: Unicast Routing Algorithm.
Figure 3: Routing Record Generator.
Figure 4: One-to-all Broadcast Algorithm.
132 Redes y Comunicación
Hierarchical Topologies for Large-scale Two-level Networks
Carmen Martínez, Enrique Vallejo, Miquel Moretó,
Ramon Beivide Mateo Valero
Dept. Electrónica y Computadores Dept. Arquitectura de Computadors
Universidad de Cantabria Universitat Politècnica de Catalunya
Avenida de los Castros s/n Campus Nord
39005 Santander 08034 Barcelona
carmenmf, enrique, mon@atc.unican.es mmoreto, mateo@ac.upc.edu
Abstract
We present in this paper some of the topolog-
ical properties of an interesting class of Cir-
culant graphs whose nodes are labeled by a
subset of the Gaussian integers. Such graphs
andtheproblemswesolveonthemhavedirect
applications to the design of interconnection
networksand,inaddition,theycanbeconsid-
ered in the design of perfect error-correcting
codes for two-dimensional signal spaces.
1 Introduction
In a recent paper, we have solved the perfect
t-dominating set problem in Gaussian graphs,
an interesting class of degree four Circulant
graphs, whose vertices are labeled by means
of a subset of the Gaussian integers [6]. The
Gaussian integers are those complex numbers
having both integer real and imaginary parts.
In this paper, we analyze the properties
of super-graphs and hierarchical graphs of
Gaussian graphs. In particular, we study
the distance properties of these graphs and
provide optimal routing algorithms for them.
Such graphs and the distance-related prob-
lemswesolveonthemhavedirectapplications
to the design of perfect error-correcting codes
for two-dimensional signal spaces and, in
addition, they can be suitable for the design
of interconnection networks.
We consider in this work four classes of
graphs. The rst class, denoted as dense
Gaussian graphs, are generated by the
Gaussian integer t + (t + 1)i, being t any pos-
itive integer. Dense Gaussian graphs contain
the maximum number of vertices for a given
diameter t. The second class, are Gaussian
graphs generated by Gaussian integers of the
form (t + (t + 1)i)2
. The third class, denoted
asSuper-Gaussiangraphs,aresuper-graphsof
the two preceding graphs. Finally, we present
the Hierarchical Gaussian graphs which is a
two levels hierarchical structure built up with
dense Gaussian graphs.
Hierarchical Gaussian graphs can be con-
sidered as good candidates for implementing
parallel systems based on chip multiproces-
sors (M-CMPs). As presented in [7], in such
systemstwointerconnectionlevelsareneeded,
one for on-chip communications and another
joining dierent chips.
Thepaperisorganizedasfollows. InSection
2 we give some previous work about Gaussian
networks. Section 3 introduces new topolo-
gies based on Gaussian networks which are
super-graphs of Gaussians with a perfect t-
dominating set. Section 4 describes 2-level hi-
erarchical dense Gaussian networks. Finally,
Section 5 illustrates routing in all these topolo-
gies and Section 6 highlights some dierences
between the graphs we have talked about in
previous Sections. Section 7 is devoted to sum-
marize the main achievements of our research.
2 Related Work
Let Z[i] = {x+yi | x, y ∈ Z} be the Euclidean
ring of the Gaussian integers, where Z denotes
the ring of the integers. We denote as N(x +
yi) = x2
+ y2
the norm of x + yi ∈ Z[i]. If
0 = π = a + bi ∈ Z[i], we consider Z[i]π the
ring of the classes of Z[i] modulo the ideal (π).
This is clearly a nite set and in [6] it is proved
that if gcd(a, b) = 1, then Z[i]π and ZN are
isomorphic rings, where N = a2
+ b2
. Next,
we enumerate some denitions and previous
results about Gaussian graphs.
Denition 1 (From [6]) Let π = a + bi ∈
Z[i] such that gcd(a, b) = 1. We dene the
Gaussian Graph generated by π, Gπ =
(V, E), as follows:
• V = Z[i]π is the vertex set.
• E = {(α, β) ∈ V × V | β − α ≡ ±1, ±i
(mod π)} is the edges set.
These graphs are regular graphs of degree
four. Moreover, in [6] it is proved that these
graphs are isomorphic to a subfamily of Cir-
culant graphs [2] of degree four whose number
of vertices can be written as the sum of two
squares. The Gaussian graph with maximum
number of vertices for a given diameter t > 0
is generated by t + (t + 1)i. We call them as
dense Gaussian graphs.
Denition 2 Let π = a + bi ∈ Z[i] such that
gcd(a, b) = 1. Given t ≤ b, a vertex α is
said to t-dominate a vertex β if β ∈ Bt(α),
where Bt(α) = {γ ∈ Z[i]π | d(γ, α) ≤ t} is
the ball of radii t centered in α embedded in
Gπ. Then, a vertex subset S is called a per-
fect t-dominating set if every vertex of Gπ
is t-dominated by a unique vertex in S.
Theorem 3 (From [6]) Let π = a + bi and t
be a positive integer. If β = t+(t+1)i divides
π, then S = (β) is a perfect t-dominating set
in Gπ, where (β) denotes the additive group
generated by β in Gπ.
Note that if π = (t + (t + 1)i)2
, the group
generated by t + (t + 1)i is a t-error correcting
code of length 1 over Z[i]π.
Corollary 4 (From [4]) Let 0 < a < b be
positive integers such that gcd(a, b) = 1 and
π = a + bi. Then,
• If a2
+ b2
is odd, the diameter of Gπ is
b − 1.
• If a2
+ b2
is even, the diameter of Gπ is
b.
3 Super-Gaussian Graphs
Let t be a positive integer. We consider for the
rest of the paper β = t + (t + 1)i and π = β2
.
Obviously, Gπ has a perfect t-dominating set
which is the additive group S = (β). Next,
we dene a super-graph of this graph, in the
following way:
Denition 5 Given t a positive integer, let
β = t + (t + 1)i and π = β2
. We dene the
Super-Gaussian Graph Gπ = (V, E) of Gπ
as follows:
• V = Z[i]π.
• E = {(α1, α2) ∈ V × V | d(α1, α2) = 1 or
α1, α2 ∈ S and d(α1, α2) = 2t + 1},
where d is the graph distance in Gπ and S =
(β) is its perfect t-dominating set.
Note that Gπ has N2
vertices and 2N2
+2N
edges, where N = N(β) = t2
+(t+1)2
. It is not
a regular graph but it contains two underlying
degree four circulant graphs. Obviously, one
of them is the Gaussian graph generated by
π, since Gπ is a subgraph of Gπ. The other
subgraph of Gπ, which we denote as G
π, has S
as its vertex set and two vertices are adjacent if
they are adjacent in Gπ but not in Gπ. Note
that G
π is regular of degree four since S is
perfect. Then, we have:
134 Redes y Comunicación
Theorem 6 With the notation above, the
graphs G
π and Gβ are isomorphic.
Proof. Since S = (β) ⊂ Z[i]π with β = t +
(t + 1)i consider:
φ : Z[i]β −→ S ⊂ Z[i]π
α −→ β · α (mod π)
which is a graph isomorphism.

Hence, Gβ is a subgraph of Gπ. Since
the two subgraphs of Gπ have disjoint edge
sets, we will say that an edge is base if
it is an edge of Gπ and express if it is
an edge of G
π. Adding express edges to
Gπ forces the loss of the vertex-symmetry
of the graph. However, this graph has
signicative advantages. Note that the di-
ameter of the graph Gπ is 2t(t + 1) − 1 as
(t + (t + 1)i)2
= −(2t + 1) + 2t(t + 1)i, by
Corollary 4. Nevertheless, the diameter of Gπ
is just 3t.
4 Hierarchical Gaussian Graphs
Currently, the increasing number of tran-
sistors per chip is facilitating the design
of Chip Multiprocessors (CMPs) as they
provide high performance and cost-eective
computing for many scientic and commercial
workloads. By combining multiple CMPs
higher performance can be achieved. Such
is the case of Piranha [1] and IBM Power4
[8]. Hence, it is necessary exploring new
networks whose topological properties match
the new requirements imposed by this emerg-
ing architectures. We explore in this section
Hierarchical Gaussian Graphs as possible
candidates for implementing such two-level
interconnection networks.
Denition 7 Given t a positive integer let
β = t + (t + 1)i. We dene the 2-Level Hi-
erarchical Gaussian Graph HGβ = (V, E)
of Gβ as follows:
• V = Z[i]β × Z[i]β
• E = {((α1,1, α1,2), (α1,1, α2,2)) ∈ V ×
V | α1,2 = α2,2 and d(α1,1, α2,1) = 1, or
α1,1 = α2,1 = 0 and d(α1,2, α2,2) = 1},
where d is the graph distance in Gβ.
Figure 1: HG1+2i
An intuitive visualization of how to build
this graph is to take N dense Gaussian graphs
of N vertices and join their centers following
the adjacency pattern of a dense Gaussian
graph of N vertices. An illustrative simple
example with β = 1 + 2i can be seen in
Figure 1. Thus, we have that HGβ has
N2
= N(β)2
vertices and 2N2
+ 2N edges,
where N = t2
+ (t + 1)2
. Also, it is clear
that the diameter of this structure is also
3t. This is neither a regular graph, as we
have vertices of degree four and eight, nor a
vertex-symmetric graph.
Despite these facts, HGβ has N + 1
subgraphs isomorphic to Gβ. The rst N sub-
graphs correspond to the N dense Gaussian
graphs in the lower level of hierarchy. Their
corresponding edges are denoted base edges
for similarity with the Super-Gaussian graph.
The last subgraph is the dense Gaussian
graph in the higher level of hierarchy and
its edges are denoted express for the same
reason than before.
XVI Jornadas de Paralelismo, JP '2005 135
5 Routing in Gaussian Graphs,
Super-Gaussian Graphs and Hier-
archical Gaussian Graphs
Many optimal algorithms for nding mini-
mum paths have been proposed for Circulant
graphs; see, for example, [3], [5]. Such algo-
rithms consider graphs whose vertices are la-
beledbyintegersandimplementtheEuclidean
division algorithm which has a high computa-
tional cost. If we consider routing in terms of
Gaussian integers, that is, in the isomorphic
Gaussian graph, we can propose a new algo-
rithm just based on integer sums and compar-
isons, as the following Lemma shows:
Lemma 8 Let t be a positive integer and β =
t+(t+1)i ∈ Z[i]. Let α = x+yi and α
= x
+
y
i be such that |x| + |y| ≤ t and |x
| + |y
| ≤ t.
If r ≡ α
− α (mod β) is such that |Re(r)| +
|Im(r)| minimum, then r = (α
−α)+γπ with
γ ∈ {0, ±1, ±i, ±(1 + i), ±(1 − i)}.
Proof. Let r = (α
− α) + γπ, that is,
r+α−α
= γπ. Letsconsiderγ = u+vi,where
u, v ∈ Z. Now, γπ = (u + vi)(t + (t + 1)i) =
((u − v)t − v) + ((u + v)t + u)i. We take
absolute values on both sides of the equality
and get:
|(u − v)t − v| + |(u + v)t + u| = |Re(γπ)| +
|Im(γπ)| = |Re(r+α−α
)|+|Im(r+α−α
)| ≤
3t
If u = 0, we have |vt| + |v(t + 1)| = |v|(2t +
1) ≤ 3t, which forces |v| ≤ 1. For v = 0,
we also obtain |u| ≤ 1. If u > 0 and v > 0,
|u + v|t < |(u + v)t + u| ≤ 3t forces |u| + |v| =
|u + v| < 3. If u > 0 and v < 0, |u − v|t <
|(u − v)t − v| ≤ 3t, which induces |u| + |v| =
|u−v| < 3. For the cases u < 0, we can use an
analogous reasoning and get|u|+|v| < 3, with
|u| > 0, |v| > 0. These conditions are clearly
equivalent to the desired result.

If we want to travel from α to α
, we have
to obtain X + Y i ≡ (α
− α) (mod π) with
|X| + |Y | minimum. This Lemma implies that
we only need to compare the graph weight
of, at most, nine Gaussian integers to nd
the pair. We denote the obtained result as
(X, Y ) := routing_record(α, α
, t). Note
that X + Y i gives us all the minimum paths
from α to α
in the dense Gaussian graph of
diameter t.
Now, we give the idea of the routing algo-
rithm for the Super-Gaussian graph Gπ. Let
α, α
be two vertices of Gπ given by their ex-
pression with minimum graph weight. Firstly,
we have to compute integers q, r, q
, r
such
that α = qβ + r, N(r) < N(β) and α
=
q
β + r
, N(r
) < N(β). Then, (x, y) :=
routing_record(q, q
, t) gives us the way of
reachingthedominatingvertexofα
,q
β,from
thedominatingvertexofα, whichisqβ, inGβ
using the express edges. The remainders r, r
give us the way of reaching α, α
from their
dominating vertices qβ, q
β, respectively, by
using the base edges. If a path in Gπ were
shorter than the previous one, we would select
it. The complete Algorithm is as follows:
Data: α = x + yi: Source vertex;
α
= x
+ y
i: Destination vertex;
β = t + (t + 1)i: graph generator
Result: (x1, y1, x2, y2, x3, y3) such that:
(x1, y1) base edges; (x2, y2) express edges;
(x3, y3) base edges
Begin
COMPUTE q, r, q
, r
such that
{α = qβ + r, N(r) < N(β)}
and {α
= q
β + r
, N(r
) < N(β)} ;
(x1, y1) = (Re(−r), Im(−r));
(x2, y2) = routing_record(q, q
, t);
(x3, y3) = (Re(r
), Im(r
)) ;
COMPUTE q
, r
such that
{α − α
= q
β2
+ r
, N(r
) < N(β)2
} ;
If ((|Re(r
)| + |Im(r
)| ≤
P3
j=1(|xj| + |yj|))
Then
(x1, y1) = (Re(r
), Im(r
));
(x2, y2) = (x3, y3) = (0, 0) ;
End
Algorithm 1: Routing Algorithm for Gπ.
Example 1 Let β = 3 + 4i and consider
the graph Gβ in Figure 2 with 625 vertices.
136 Redes y Comunicación
Most of base wrap-around and express edges
are omitted for simplicity. Now, consider α =
1 + 12i and α
= 5 − 5i. It is clear that
α = (2+i)β+(−1+i) andα
= (−i)β+(1−2i).
The remainders −1 + i and 1 − 2i give us the
path through base edges to reach the centers
of their corresponding balls. Then, (1, 2) is
the routing record for vertices 2 + i and −i
in G3+4i, which gives us the path through ex-
press edges for reaching the dominating vertex
of α
from the dominating vertex of α. The
total length of the path is 8, while only using
the base edges we obtain the path −3 + 7i of
length 10.
Figure 2: Routing in Super-Gaussian Graph
G(3+4i)2 .
Now, we give an idea of the routing in
Hierarchical Gaussian Graphs. Although
it is not a vertex-symmetric graph, we can
use the symmetry of our graph to obtain
all the possible shortest paths from a source
vertex s = (α1, α2) to a destination vertex
d = (α
1, α
2). The idea of the algorithm is
that if both vertices are in the same dense
Gaussian graph then we can follow a direct
routing. In other cases, the routing consists in
going to the center of the corresponding dense
Gaussian graph, then go up in the higher level
of hierarchy and attain the destination dense
Gaussian graph. Now, we just have to go
to the destination vertex following the edges
in the dense Gaussian graph. The complete
algorithm is as follows:
Data: s = (α1, α2): Source vertex;
d = (α
1, α
2): Destination vertex;
β = t + (t + 1)i: graph generator.
Result: (x1, y1, x2, y2, x3, y3) such that:
(x1, y1) base edges; (x2, y2) express edges;
(x3, y3) base edges.
Begin
If (α2 = α
2)
Then
(x1, y1) = routing_record(α1, α
1, t);
(x2, y2) = (x3, y3) = (0, 0);
Else
(x1, y1) := routing_record(α1, 0, t);
// edges to reach the center
// of the dense Gaussian Graph
(x2, y2) := routing_record(α2, α
2, t);
// edges in the higher level
// of hierarchy
(x3, y3) := routing_record(0, α
1, t);
// edges to attain d
End
Algorithm 2: Routing Algorithm for HGβ.
Example 2 Let β = 3 + 4i and consider the
graph HGβ in Figure 3 with 625 vertices.
Most of base wrap-around and express edges
are omitted for the sake of clarity. Now, con-
sider α = (1 + i, 1 + 2i) and α
= (−i, −1 + i).
As α2 = α
2 we have to follow the path−1−i to
reach the center of the dense Gaussian graph
of α. Then, as (−1 + i) − (1 + 2i) = −2 − i we
have to follow this path to nd the destination
dense Gaussian graph. Finally −i is the way
to attain α
. The total length of the path is 6.
6 Comparative between Super-
Gaussian Graphs and Hierarchi-
cal Gaussian Graph
We have previously seen that given a gaussian
integer β = t + (t + 1)i that generates Gβ and
HGβ, both graphs have the same number
XVI Jornadas de Paralelismo, JP '2005 137
Figure 3: Routing in Hierarchical Gaussian Net-
work HG3+4i.
of vertices, edges and diameter. Moreover,
we have the same number of vertices with
degree 4 and 8. Despite these two graphs
look so similar, there are some dierences
to highlight concerning their connectivity.
The Super-Gaussian Graphs have both
edge-connectivity and vertex-connectivity of
4, while the Hierarchical Gaussian Graph
has also an edge-connectivity of 4, but a
vertex-connectivity of 1. This is because
if a vertex of the dense gaussian network
in the higher level of hierarchy falls then it
disconnects the dense gaussian network that is
under this vertex from the rest of the network.
Concerning the average distance, as the
routing algorithm is very similar, we obtain
practically the same performance. We have
simulated both topologies for t ∈ {1, . . . , 10}
and get practically the same result. More-
over, using the symmetry of the Hierarchical
Gaussian Network we obtain a formula for the
average distance. We introduce rst some de-
nitions.
Denition 9 The average distance in a dense
Gaussian Graph of diameter t is d = 2t+1
3
.
The average distance to the center of a dense
Gaussian Graph is δ = N−1
N
d, where N =
2t2
+ 2t + 1.
Lemma 10 Given t a positive integer. Let
β = t+(t+1)i. The average distance in HGβ
can be computed as 3N−1
N+1
d, where d is the av-
erage distance in a dense Gaussian Graph and
N = 2t2
+ 2t + 1.
Proof. When we want to travel from a source
vertex α we have N2
− 1 possible destination
vertices. Some of them, N −1, are in the same
dense Gaussian graph, so they are in average
at distance d. The others are in a dierent
dense gaussian graph, so we have to reach the
center of the ball, at average distance δ as the
source vertex may be the center. Then we have
to go to the other ball which is at average dis-
tance d. Finally we attain the destination ver-
tex in the dense Gaussian graph which is at
average distance δ. This reasoning allows us
to compute the average distance in HGβ:
¯
d =
N − 1
N2 − 1
d +
N(N − 1)
N2 − 1
(d + 2δ)
=
d + Nd + 2(N − 1)d
N + 1
=
3N − 1
N + 1
d


7 Conclusions
We have considered four dierent graphs asso-
ciated to the Gaussian integer β = t+(t+1)i:
the dense Gaussian Gβ, the Gaussian Gβ2 ,
the Super-Gaussian Gβ2 and the Hierarchical
Gaussian HGβ graphs. We have solved the
minimal routing problem in dense Gaussian,
in Super-Gaussian graphs and in Hierarchi-
cal Gaussian graphs. Our routing algorithm
for dense Gaussian graphs uses just integer
additions and comparisons, providing a sim-
pler solution than previous published algo-
rithms. Moreover, based on the previous rout-
ing, we also provide an ecient routing al-
gorithm for Super-Gaussians and Hierarchical
138 Redes y Comunicación
Gaussian graphs. The graphs considered in
this work and the problems solved on them
have dierent applications to Coding Theory
and Interconnection networks.
Acknowledgment
C. Martinez is supported by the Spanish
Science and Education Ministry under grant
FP-2001-2482. E. Vallejo is supported by
the Spanish Science and Education Min-
istry under grant AP-2004-6907. Miquel
Moretó is supported by the Spanish Sci-
ence and Education Ministry under grant
BECA-COLABORACION curso 2004/2005.
R. Beivide is supported by the Spanish
Science and Education Ministry under con-
tract TIN-2004-07440-C01-01 and by the
HiPEAC European Network of Excellence.
Finally, M. Valero is supported by the Span-
ish Science and Education Ministry under
contract TIN-2004-07739-C02-01, by the
HiPEAC European Network of Excellence
and by the Barcelona Supercomputing Center.
References
[1] L.A. Barroso et al. "Piranha: A Scalable
Architecture Based on Single-Chip Multi-
processing". 27th ISCA, pp. 282-293. June
2000.
[2] J.-C. Bermond, F. Comellas, D.F. Hsu.
"Distributed Loop Computer Networks: A
Survey". Journal of Parallel and Distrib-
uted Computing, Vol. 24, pp. 2-10, 1995.
[3] J.-Y. Cai, G. Havas, B. Mans, A. Nerurkar,
J.-P.Seifert, I.Shparlinski."OnRoutingin
Circulant Graphs". Cocoon'99, Japan.
[4] E. Gabidulin, C. Martínez, R. Beivide and
J. Gutierrez. "On the Weight Distribution
of Gaussian Graphs with an Application
to Coding Theory". Accepted for presen-
tation at ISCTA'05, UK.
[5] D. Gómez, J. Gutierrez, A. Ibeas, C.
Martínez, R. Beivide. "On Finding a
Shortest Path in Circulant Graphs with
Two Jumps". Accepted for presentation at
Cocoon'05, China.
[6] C. Martínez, R. Beivide, J. Gutierrez
and E. Gabidulin. "On the Perfect t-
Dominating Set Problem in Circulant
Graphs and Codes over Gaussian Inte-
gers". Accepted for presentation at IEEE
International Symposyum on Information
Theory, 2005, Australia.
[7] M.R. Marty, J.D. Bingham, M.D. Hill,
A.J. Hu, M. Martin and d: Wood. "Im-
proving Multiple-CMP Systems using To-
ken Coherence". 11th HPCA, 2005.
[8] J.M. Tendler et al. "Power4 System Mi-
croarchitecture". IBM Journal of Research
and Development, 46(1), 2002.
XVI Jornadas de Paralelismo, JP '2005 139
Segment-Based Routing: Un Nuevo Algoritmo de Encaminamiento Agnóstico a
la Topología *
A. Mejía, J. Flich, J. Duato
Departamento de Informática de Sistemas y Computadores
Universidad Politécnica de Valencia
P.O.B. 22012, 46022 - Valencia, SPAIN
E-mail: {andres,jflich,jduato}@gap.upv.es
Phone: +34 963877007; FAX: +34 963877579
Resumen
En este artículo proponemos un algoritmo de
encaminamiento genérico aplicable a cualquier
topología y que no requiere del uso de canales vir-
tuales. El algoritmo, denominado Segment-Based
Routing (SR), divide la topología en segmentos, de
manera que permite colocar una restricción bidirec-
cional de encaminamiento en cada segmento, inde-
pendientemente de la posición dentro del segmen-
to y de la posición relativa de las demás restriccio-
nes. Esto nos ofrece una mayor flexibilidad en la
ubicación de restricciones que la ofrecida por an-
teriores propuestas. Resultados preliminares mues-
tran como el algoritmo SR es capaz de mejorar las
prestaciones del algoritmo FX para la mayoría de
los casos evaluados.
1. Introducción
Durante los últimos años los clusters de computa-
dores se han convertido en una alternativa a los
computadores de altas prestaciones y sistemas de
servidores. En los clusters, las redes de interconex-
ión como Myrinet [2], Quadrics[5] e InfiniBand[4]
ofrecen una baja latencia y un elevado ancho de
banda que permiten obtener una buena relación
coste / prestaciones.
Estas redes usan encaminamiento determinista.
Uno de los principales beneficios del encamina-
*
Este trabajo ha sido fi nanciado por la CICYT con el proyecto
TIC2003-08154-C06.
miento determinista es que se preserva el orden de
llegada de los paquetes (aunque se hace un uso poco
eficiente de los recursos de la red). Sin embargo, en
el encaminamiento adaptativo, los paquetes pueden
utilizar varios caminos (una vez han sido inyecta-
dos) dependiendo de las condiciones de tráfico, evi-
tando así zonas congestionadas en la red.
Con el fin de evitar bloqueo en una red con enca-
minamiento determinista, el grafo de dependencias
de canales debe ser acíclico. Para lograr esto, los al-
goritmos imponen restricciones de encaminamiento
entre diversos canales. Una restricción está defini-
da por un conmutador y un par de puertos (uno de
entrada y otro de salida) de ese conmutador, de tal
manera que al existir una restricción ningún paquete
puede utilizar el puerto de salida seguido del puerto
de entrada del conmutador.
Además, en las redes de interconexión es común
el uso de canales virtuales para otros propósitos
diferentes del encaminamiento (principalmente ca-
lidad de servicio - QoS). Cabe indicar que Myrinet
no implementa canales virtuales y que InfiniBand
los reserva principalmente para QoS.
Otro aspecto a tener en cuenta en dichas redes es
la tolerancia a fallos. De echo, la mayoría de técni-
cas propuestas para multicomputadores no pueden
ser aplicadas a dichas redes ya que asumen el uso
de encaminamiento adaptativo. Ahora bien, una for-
ma de tolerar fallos es el uso de algoritmos de en-
caminamiento genéricos. Estos algoritmos pueden
ser aplicados a cualquier topología. Los algoritmos
de encaminamiento genéricos propuestos en la li-
teratura son el up*/down* [13], lturn [3], smart-
routing [8], LASH [10], TOR [14], LASH-TOR [9],
DL [6], multiple virtual networks [7], y el FX [11].
De todos estos, solamente up*/down*, lturn, smart-
routing y FX pueden ser aplicados a redes con en-
caminamiento determinista y sin canales virtuales.
Colocar restricciones de encaminamiento en la
red debe realizarse de forma cuidadosa pues debe
garantizarse que la red sea libre de bloqueo y al
mismo tiempo mantenga la conectividad entre to-
dos los nodos. Para lograr esto, algoritmos como
el up*/down*, lturn y FX establecen algunas re-
glas pre-establecidas1
. Estas reglas indicarán donde
se romperán los ciclos. Puesto que los enlaces uti-
lizados en la red son bidireccionales, los ciclos
deben ser cortados en ambas direcciones. Para esto,
up*/down* impone restricciones en el mismo lugar
para ambas direcciones. A su vez, FX presenta una
novedosa propuesta que rompe los ciclos en dife-
rente lugar en cada dirección (restricciones unidi-
reccionales). En [11] se muestra como este hecho
permite obtener mayores prestaciones.
Como ejemplo ilustrativo, la Figura 1.a nos pre-
senta una malla 3 × 4 a la que le fallan dos de sus
enlaces. En primer lugar, el algoritmo up*/down*
selecciona un conmutador como raíz. A partir de
éste, se computa un árbol en amplitud (BFS) y los
enlaces son etiquetados como up o down. Las res-
tricciones de encaminamiento son las transiciones
down → up. Por lo tanto, una vez se selecciona la
raiz del árbol las restricciones de encaminamien-
to estarán ya ubicadas (cuatro restricciones bidirec-
cionales para este ejemplo). Puesto que existen 12
conmutadores, solamente son posibles 12 combina-
ciones de restricciones de encaminamiento, y para
cada combinación, la posición relativa de cada res-
tricción es fija.
El algoritmo FX tambien sufre de este hecho.
Construye un árbol DFS para etiquetar los conmuta-
dores y usa las etiquetas para colocar restricciones
unidireccionales. Por lo tanto, una vez se determi-
na el árbol DFS, la posición de las restricciones de
encaminamiento es fija.
Ahora, dividamos la misma topología en cuatro
segmentos tal como se muestra en la Figura 1.b.
1
Smart-routing tiene un procedimiento diferente para estable-
cer las restricciones de encaminamiento. En concreto, realiza un
proceso iterativo de cálculo de rutas y evalúa que la red sea libre
de bloqueo hasta que se encuentra el mejor conjunto de rutas. Por
lo tanto tiene un elevado coste computacional.
Con dicho particionado y colocando una restricción
bidireccional en cada segmento se puede garantizar
que el algoritmo de encaminamiento empleado es li-
bre de bloqueo y mantiene la conectividad entre to-
dos los nodos. En efecto, podemos observar como
la anterior combinación de restricciones obtenida
por up*/down* es una de las 48 posibles soluciones.
Incluso, nótese que la posición de las restricciones
bidireccionales de cada segmento es independiente
de la posición de las demás. Este hecho nos permite
una mayor flexibilidad a la hora de ubicar las res-
tricciones de encaminamiento. Por ejemplo, la se-
lección final puede realizarse siguiendo criterios de
optimización de ancho de banda o latencia.
En este artículo proponemos un nuevo algoritmo
de encaminamiento, denominado Segment-based
Routing (SR) que intentará explotar la flexibilidad
que nos proporciona el particionado de la red en
segmentos para encaminar de forma determinista y
sin utilizar canales virtuales. Para ello, SR realizará
un particionado de la red de tal forma que, garan-
tice que ubicando una restricción en cada segmento
se obtenga un encaminamiento libre de bloqueo y
se mantenga la conectividad entre todos los nodos.
El resto del artículo está organizado como sigue,
la Sección 2 describe el algoritmo SR, más adelante,
en la Sección 3, las prestaciones del SR son com-
paradas con las del FX y up*/down* y, finalmente,
en la sección 4 se presentarán algunas conclusiones
y el trabajo futuro.
2. Segment-based Routing
La Figura 2 muestra el algoritmo para calcular
los segmentos de red2
. A lo largo del proceso, el
algoritmo marca los conmutadores y enlaces con las
siguientes etiquetas:
• visited . Inicialmente los conmutadores y en-
laces están en estado not visited. Un conmu-
tador o enlace se convierte en visited cuando
pertenece a un segmento de red ya formado.
• tvisited. Durante el proceso de cálculo de un
segmento de red, un conmutador o enlace
puede cambiar al estado tvisited. Solamente
conmutadores y enlaces no etiquetados como
visited pueden ser etiquetados como tvisited.
2
El algoritmo asume que ningún paquete entrará y saldrá de un
conmutador a travez del mismo enlace.
142 Redes y Comunicación
ROOT
bidireccionales
restricciones
(a)
 
 
1
2
3
4
6
5
A
B
C
D
E
F
G
H
I
J
K
L
4
3 2
7
8
10
12
14
13
11
9
1
15
(b)
 
 
 
 
6
5
A
B
C
D
E
F
G
H
I
J
K
L
4
3 2
7
8
10
12
14
13
11
9
1
15
1
2
3
4
(c)
Figura 1: Posible conjunto de restricciones. (a) establecidas por up*/down*, (b) diferentes alternativas, y (c) una de las
posibles combinaciones.
• starting. Un conmutador es etiquetado como
starting si es el primero escogido para calcular
los segmentos de red en una subred.
• terminal. Un conmutador es marcado como
terminal si a través de él ningún segmeto es
encontrado en al menos uno de sus enlaces.
Adicionalmente, el algoritmo agrupará los con-
mutadores y enlaces de la red dentro de subredes.
Una subred estará formada por un grupo de con-
mutadores y enlaces que estarán conectados al resto
de la red (otras subredes) mediante un único en-
lace. Todos los componentes de un segmento de red
pertenecerán a la misma subred. El uso de subredes
se utiliza para ttasar algunos casos especiales que
serán descritos más adelante.
El procedimiento compute_segments (Figura 2)
busca los segmentos de la red. Para esto, un con-
mutador es elegido aleatoriamente para ser el con-
mutador starting del primer segmento dentro de la
primera subred3
. El conmutador elegido es etique-
tado como starting y visited, y añadido a la primera
subred. A partir de este conmutador el procedimien-
to busca todos los posibles segmentos y subredes
utilizando el procedimeinto find. En caso de encon-
trar un segmento, el procedimiento find actualiza to-
dos los conmutadores y enlaces del nuevo segmen-
to (los etiqueta como visited y pertenecientes a la
subred actual). Si el procedimiento falla, el proce-
dimiento find mantiene los conmutadores y enlaces
3
Como muchos conmutadores pueden ser escogidos como con-
mutador starting, SR puede llevarnos a muchas soluciones, Más
tarde escogeremos un criterio para seleccionar el primer conmuta-
dor en mallas 2D.
sin modificarlos y debido a que no existe ningún
segmento nuevo el conmutador es etiquetado como
terminal.
A continuación, el procedimiento busca (función
next_visited) un conmutador marcado como visit-
ed, perteneciente a la subred actual y que tenga al
menos un enlace no marcado como visited. A par-
tir de este conmutador se busca un nuevo segmen-
to. En caso de que no exista dicho conmutador, el
procedimeinto busca (función next_not_visited) un
conmutador no etiquetado como visited ni como ter-
minal. Si existe, una nueva subred es formada y el
conmutador es marcado como starting y visited, es
incluido en la nueva subred y se busca un nuevo
segmento a partir de este conmutador. Si no ex-
iste dicho conmutador, entonces todos los conmu-
tadores han sido provados y el procedimiento fina-
liza. Nótese que el procedimiento se asegura que to-
dos los conmutadores y enlaces en la red hayan sido
considerados y pertenezcan a un segmento de la red.
El procedimiento find es responsable de encon-
trar, a partir de un conmutador visitado dado, un
segmento finalizado en un conmutador visitado y
compuesto por conmutadores y enlaces no visita-
dos. Para esto, el conmutador actual es marcado
como tvisited y es añadido al segmento actual. A
continuación, se construye un conjunto de enlaces
conectados al conmutador y no marcados no como
visited ni tvisited (función suitable_links). En caso
que este conjunto de enlaces sea vacío (no existan
enlaces apropiados), el procedimiento habrá fallado
en la búsqueda de un segmento.
Aún así, en el caso en que el conjunto de en-
laces no sea vacío, los enlaces deben ser considera-
XVI Jornadas de Paralelismo, JP '2005 143
procedure compute_segments()
var
s : segment list
sw : switch
c : integer # subred actual
n : integer # segmento actual
end : boolean
begin
c = 0; n = 0
sw = random
sw.starting = true
sw.subnet = c
sw.visited = true
s[n] = empty
end = false
repeat
if (fi nd(sw,s[n],c))
n++
else
sw.terminal = true
sw = next_visited()
if (sw == nil)
begin
sw = next_not_visited()
c++
sw.starting = true
sw.subnet = c
sw.visited = true
end
if (sw == nil) end = true
until (end)
end procedure
procedure fi nd(sw, segm, snet) : bool
var
nsw : switch
begin
sw.tvisited = true
segm = segm + sw
links = suitable_links(sw)
if (links==nil) begin
sw.tvisited = false
segm = segm - sw
return false
end
for each link ln in links begin
ln.tvisited = true
segm = segm + ln
nsw = aTop[sw,ln]
if ((nsw.visited and nsw.subnet = snet) or
fi nd(nsw, segm, snet)) begin
ln.visited = true
sw.visited = true
ln.tvisited = false
sw.tvisited = false
return true
end
else begin
ln.tvisited = false
segm = segm - ln
end
segm = segm - sw
sw.tvisited = false
return false
end procedure
Figura 2: Procedimiento principal para la busqueda de segmentos.
dos con un orden establecido. Nótese que el orden
establecido puede influir en las prestaciones finales
del algoritmo puesto que diferentes combinaciones
de segmentos serán encontradas. Por lo tanto, es re-
comendable seguir algún orden. Más adelante, se
propondrán algunas reglas para encontrar segmen-
tos en mallas. Para uno de los enlaces del conjun-
to el procedimiento marca el enlace como tvisited,
añade el enlace al segmento e inspecciona si el con-
mutador al otro lado del enlace está marcado co-
mo visited y pertenece a la subred actual. Si esto no
ocurre, el procedimiento es llamado de forma recur-
siva desde el conmutador adjunto al otro lado del
enlace con el fin de encontrar el resto del segmento.
En caso de que el conmutador vecino esté marca-
do como visited) entonces puede afirmarse que un
nuevo segmento ha sido encontrado. En caso de no
encontrar un nuevo segmento a través del enlace,
el enlace se elimina del segmento y se marca como
not visited y un nuevo enlace del conjunto es inspec-
cionado. Finalmente, en caso que ningún segmento
sea encontrado a través del conjunto de enlaces, el
procedimiento habrá fallado en encontrar un nue-
vo segmento desde el conmutador, el conmutador es
eliminado del segmento y el procedimiento retorna.
Una vez los segmentos de la red han sido encon-
trados, el algoritmo colocará las restricciones de en-
caminamiento en cada uno de los segmentos de la
red. El algoritmo clasifica los segmentos de acuer-
do a tres tipos:
144 Redes y Comunicación
starting
(a) (b)
Figura 3: (a) SR aplicado a (a) malla 5 × 5 y (b) malla 5 × 5 con fallos en tres de sus enlaces.
• segmento starting. Este segmento de red
comenzará y terminará en el mismo conmuta-
dor formando un ciclo. Este segmento de red
será encontrado cada vez que una nueva sub-
red sea inicializada.
• segmento regular. Este tipo de segmento
comenzará en un enlace, y contendrá al menos
un conmutador para finalmente terminar en un
enlace.
• segmento unitary. Este tipo de segmento de
red estará formado por un único enlace.
Con el fin de asegurar un algoritmo libre de blo-
queo mientras se garantiza la conectividad, el al-
goritmo de encaminamiento debe agregar en cada
tipo de segmento una o varias restricciones. En par-
ticular, para un segmento starting, una restricción
bidireccional puede ser agregada en cualquiera de
sus conmutadores excepto en el starting. Para seg-
mentos de tipo regular, la restricción bidireccional
puede ubicarse en cualquiera de los conmutadores
que pertenezcan al segmento. Finalmente, para seg-
mentos unitary, todo el tráfico que cruce por el en-
lace debe ser cortado con el fín de evitar bloqueos.
Por tanto, se deben agregar restricciones bidirec-
cionales para cada enlace adjunto a uno de los con-
mutadores del enlace en cuestión. La demostración
de que el algoritmo es libre de bloqueo y conexo
puede consultarse en [12].
2.1. Algoritmo SR aplicado a Mallas 2D
La manera como los segmentos de red son cal-
culados y como las restricciones de encaminamien-
to son agregadas a los segmentos influirá notable-
mente en las prestaciones. Por ejemplo, un segmen-
to escogido aleatoriamente a través de una función
recursiva puede obtener unas bajas prestaciones
(aún peor que up*/down*). Por lo tanto, segmen-
tos y restricciones de encaminamiento deberán ser
calculadas teniendo en cuenta algunos parámetros
de la topología. Por lo tanto y como primer esfuer-
zo, mostraremos en esta sección un ejemplo de apli-
cación del algoritmo SR en mallas 2D.
La Figura 3.a muestra como son calculados los
segmentos para una malla 5 × 5. En particular,
los segmentos serán calculados desde arriba ha-
cia abajo, cada fila en una dirección diferente: La
primera fila de izquierda a derecha, la segúnda fi-
la de derecha a izquierda y así sucesivamente. Cada
segmento será calculado tan corto como sea posi-
ble. Por lo tanto, los enlaces vistados para encon-
trar segmentos serán organizados de tal manera que
aquellos más próximos a los visitados son explo-
rados primero. Despues, las restricciones de enca-
minamiento serán agregadas de manera que las res-
tricciones en la misma fila serán puestas en la mis-
ma posición relativa (Figura 3.a). Esta manera de
buscar segmentos y agregar restricciones de enca-
minamiento, puede ser efectuada tambien en mallas
con fallos. En particular, un ejemplo es ilustrado en
la Figura 3.b donde el anterior método es aplicado
XVI Jornadas de Paralelismo, JP '2005 145
a una malla 5 × 5 con fallos en tres de sus enlaces.
2.2. Coste Computacional
SR puede ser visto como un algoritmo desarro-
llado en tres fases. En la primera fase los segmen-
tos son calculados. La manera como los segmen-
tos sean calculados influenciará en el costo com-
putacional del algoritmo. Una exploración no con-
trolada podría requerir un considerable coste com-
putacional, sin embargo, procedimientos similares
al descrito anteriormente para las mallas 2D tendrán
un coste bajo pues los enlaces sólo son visitados so-
lo una vez, por lo que el coste requerido para esta
fase asciende a O(m) donde m es el número de en-
laces en la red (en el caso de una malla, el coste será
O(2n) siendo n el número de conmutadores). En la
segunda fase del algoritmo, las restricciones de en-
caminamiento son agregadas, como fue propuesto,
el coste computacional de esta fase será O(s) donde
s es el número de segmentos.
Finalmente, en la tercera fase, las rutas son cal-
culadas teniendo en cuenta las restricciones de en-
caminamiento. La complejidad de esta fase puede
variar ampliamente dependiendo de las presta-
ciones deseadas. Nótece que el algoritmo SR puede
proveer varias rutas entre algunos pares de nodos
(fuente-destino). Una busqueda directa de rutas exi-
girá un coste computacional de O(n2
) donde n es
el número de conmutadores. Aun así, más sofistica-
dos y novedosos métodos han sido propuestos con
el fin de obtener el mejor conjuto de rutas, como es
el caso del FX que usa un algoritmo que minimiza
el número máximo de rutas que cruzan un enlace.
Por lo tanto, la selección final de rutas no depende
en sí del algoritmo de encaminamiento.
Por consiguiente, el coste computacional del al-
goritmo SR dependerá de la tercera fase del algorit-
mo. Si la selección de rutas se basa en un conjunto
al azar (dentro de todas las posibles), entonces el
coste será O(n2
) donde n es el número de conmu-
tadores. Por el contrario, si se utiliza una función
de optimización es usada como en el caso del FX,
entonces el coste final será el mismo que el FX.
3. Evaluación de Resultados
En esta sección evaluaremos las prestaciones del
algoritmo SR comparandolo con up*/down* (UD) y
FX. En el caso de SR, el cálculo de los segmentos y
la aplicación de las restricciones de encaminamien-
to se hará según lo explicamos para las mallas 2D.
Para la tercera fase del algoritmo, es decir para la
elección de las rutas finales, utilizaremos el algorit-
mo de balanceo de rutas descrito en [1], y similar al
usado por FX.
Para cada una de las simulaciones, asumiremos
que la tasa de generación de paquetes es constante e
idéntica para todos los nodos finales. Una vez que la
red alcanza un estado estable, la tasa de generación
de paquetes será igual a la tasa de recepción de
paquetes. Evaluaremos un amplio rango de tráfico,
desde un flujo bajo hasta la saturación. Usaremos
los siguientes patrones de tráfico: (1) uniforme, (2)
bit reversal, y (3) distribución de destino hotspot.
En este último caso, 4 % del tráfico inyectado por
un nodo fuente tendrá como destino un nodo selec-
cionado al azar y el resto de tráfico será inyectado a
destinos aleatorios.
En todos los resultados presentados, se grafi-
cará el promedio de latencia de los paquetes con-
tra el promedio de tráfico aceptado medidas en
bytes/ciclos. Diferentes topologías han sido mode-
ladas: mallas y toros de 4×4, 8×4 y 8×8. Así tam-
bien han sido modeladas varias topologías regulares
con 5 % de fallos inyectados aleatoriamente. De-
bido a la falta de espacio, solo los resultados de cier-
tas topologías serán mostrados (resultados similares
han sido obtenidos para el resto de las topologías).
3.1. Resultados
La Figura 4 nos muestra las prestaciones
obtenidas por UD, FX, y SR en mallas con difer-
entes tamaños. En particular, con tráfico uniforme,
FX supera relativamente al SR (por un factor de
1.11 en malla de 8 × 8) y ambos superan ampli-
amente al UD (SR aventaja el comportamiento de
UD por un factor de 1.25). Para las mallas, SR ob-
tiene siempre rutas mínimas (al igual que UD y FX).
Sin embargo, la desviación típica del peso de los en-
laces (número de rutas por enlace) es más alta para
el SR (31.31) que para el FX (27.77). Este es el mo-
tivo por el cual FX obtiene mejores prestaciones con
tráfico uniforme. Por otro lado, la desviación típica
del peso de los enlaces es mucho más baja que la
obtenida por UD (43.40), debido al hecho de que
UD tiende a concentrar el tráfico alrededor del no-
146 Redes y Comunicación
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(a) malla 8 × 8, uniforme
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(b) malla 8 × 8, bitreversal
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(c) toro 8 × 8, bitreversal
Figura 4: Latencia media de paquetes vs productividad para redes regulares.
0
5000
10000
15000
20000
0.05 0.1 0.15 0.2 0.25
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(a) malla 4 × 4
0
5000
10000
15000
20000
0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(b) malla 8 × 4
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(c) malla 8 × 8, semilla 1
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(d) malla 8 × 8, semilla 2
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(e) malla 8 × 8, semilla 3
0
5000
10000
15000
20000
0.1 0.2 0.3 0.4 0.5 0.6 0.7
Average
Message
Latency
(cycles)
Accepted traffic (bytes/cycle)
’FX’
’UD’
’SR’
(f) malla 8 × 8, semilla 4
Figura 5: Latencia media de paquetes vs productividad. Redes regulares con fallos.
do raíz.
Sin embargo, hay que tener presente que FX lo-
gra las mismas rutas que el Dimension Order Rout-
ing (DOR) en las mallas. De la misma manera,
es conocido el excelente comportamiento del DOR
en redes regulares y con tráfico uniforme (inclu-
so mejor que usando encaminamiento adaptativo),
aunque para otro tráfico FX/DOR obtienen bajas
prestaciones. Analizemos ahora las simulaciones de
los patrones de tráfico bit-reversal (Figura 4). Con
un patrón bit-reversal, FX y UD son sobrepasados
por SR. En particular, SR incrementa la productivi-
dad de la red obtenida por FX en un factor de 1.42
para malla 8 × 8 y 1.8 para toro 8 × 8. Estos resul-
tados sugieren el potencial de SR cuando las redes
regulares son consideradas. Para el patrón de trafico
hotspot los algoritmos muestran unas prestaciones
similares.
La Figura 5 muestra resultados para las mallas
con 5 % de fallos de enlaces inyectados aleatoria-
mente y ante la presencia de tráfico uniforme. Para
todos los casos (excepto para la malla 4×4 donde se
observa unas prestaciones similares), SR sobrepasa
a FX y UD. En particular, para algunas mallas 8×8
SR incrementa la productividad de FX y UD en un
factor de 1.4 y 1.65, respectivamente. SR obtiene
XVI Jornadas de Paralelismo, JP '2005 147
mejores rutas que FX y UD en términos de prome-
dio de longitud de rutas (5.33 para el SR frente a
5.46 y 5.43 para UD y FX) y distribución del peso
de los enlaces (43.19 para el SR frente a 63.19 y
59.06 para UD y FX).
4. Conclusiones
En este artículo hemos propuesto un novedoso
método (SR) para obtener un algoritmo de enca-
minamiento agnóstico a la topología. Se ofrece una
gran flexibilidad a la hora de agregar las restriccio-
nes de encaminamiento con el fin de lograr rutas
libre de bloqueo y mantener la conectividad de la
red. Más aún, SR usa la regularidad implicita en la
topología cuando realiza el cálculo de las rutas aún
con la presencia de fallos. Resultados preliminares
(aplicando restricciones bidireccionales y usando
una manera preliminar para el cálculo de segmentos
en mallas) muestran resultados esperanzadores. SR
sobrepasa UD, y también, en algunos escenarios, in-
crementa la productividad del FX por un factor de
1.8.
Como trabajo futuro, planeamos incrementar las
prestaciones del algoritmo. Un tema que quisiera-
mos explorar es el desarrollo de mejores métodos
para el calculo de segmentos y el uso de restriccio-
nes unidireccionales.
Referencias
[1] J. Flich, P. Lopez, M.P. Malumbres, J. Duato,
and T. Rokicki, Combining In-Transit Buffers
with Optimized Routing Schemes to Boost the
Performance of Networks with Source Rout-
ing. in Proc. of Int. Symp. on High Performance
Computing, Oct. 2000.
[2] N.J.Boden and et al. Myrinet: A Gigabit per
Second Local Area Network. IEEE Micro,
15(1):29 35, 1995.
[3] M.Koibuchi, A.Funahashi, A.Jouraku, and
H.Amano. Lturn routing: An adaptive routing
in irregular networks. in Proc. of ICPP, pages
374 383, Sept. 2001.
[4] InfiniBandT M
Trade Association,
InfiniBandT M
architecture. Specification
Volumen 1. Release 1.0.a. Available at
http://www.infinibandta.com. june 2001
[5] F. Petrini, W. Feng, and A. Hoisie. The
Quadrics network (QsNet): high performance
clustering technology. In Proc. of Hot Inter-
connects, pages 125 130, Aug. 2001.
[6] M.Koibuchi et al, Descending Layers Rout-
ing: A Deadlock-Free Deterministic Routing
using Virtual Channels in System Area Net-
works with Irregular Topologies. em Int. Conf.
on Parallel Processing, 2003.
[7] J. Flich, et al, Improving InfiniBand Routing
through Multiple Virtual Networks in Proc. of
2002 Int. Symp. on High Performance Comput-
ing, 2002.
[8] L. Cherkasova et al, Fibre channel fabrics:
Evaluation and design, in Proc. of 29th Int.
Conf. on System Sciences, Feb. 1995.
[9] T. Skeie, O. Lysne, J. Flich, P. Lopez, A.
Robles, J. Duato, LASH-TOR: A Gener-
ic Transition-Oriented Routing Algorithm, in
Proc. of IEEE Int. Conf. on Parallel and Dis-
tributed Systems, 2004.
[10] T. Skeie, et al, Layered Shortest Path (LASH)
Routing in Irregular System Area Networks, in
Proc. of Comm. Architecture for Clusters, 2002.
[11] J.C. Sancho, A. Robles, and J. Duato, A Flex-
ible routing Scheme for Networks of Worksta-
tions, in Proc. of 2000 Int. Conf. on High Per-
formance Computing (ISHPC’01), Sept. 2000.
[12] A. Mejía, J. Flich, and J. Duato, Segment-
Based Routing: A New Approach to Efficient
Topology-Agnostic Routing, enviado a Proc.
of 2005 International Conference on High Per-
formance Computing (HiPC’05), Dec. 2005.
[13] M. D. Schroeder et al., Autonet: A high-speed,
self-configuring local area network using point-
to-point links, SRC research report 59, DEC,
Apr. 1990.
[14] J.C. Sancho, A.Robles, J. Flich, P.Lopez, and
J. Duato, Effective methodology for deadlock-
free minimal routing in InfiniBand networks
Proc. of the 2002 Int. Conf. On Parallel Pro-
cessing, IEEE Computer Society, 2002.
148 Redes y Comunicación
   
                        
  !      $    &     

    (   !           *  !   - / 1 3 5 6 7 9 ; = > ?
@ A C A D F H J L F N O A C A Q S T U W X C A O U T J [ N C A ^ S F _ a b A C a [ c X a c N O A d F e W c
g h i j k l h n p q s t u v j x z { g h i j k l h n p q s t u v j x z { l h } x ~ j h u { ~ €  t { j h ƒ
„ p x … k l h † { ~ j x ‡ ‡ { ‰ Š { ‹ { p z Ž {  † s u i  j { l s t h ~ ‘ { … h p “ „ k • k
i — { t z x { ˜ x p q s ‰ { ™ k  z ‡ u k h ~ „ p x … k › s ‡ x j œ z p x z { l h  { ‡ h p z x { n { p Ÿ   s Ž p ~ s p ˜ ƒ  t { j h ƒ k z s u
i { z s ˜ x p q s ‰ { ™ k  z ‡ u k h ~ ¢ £ x z Ž ˜ l x ~ z { k  i … k h ~ ¤ x p ™ { t Ÿ ¦ { … h p ˜ ƒ  t { j h ƒ k z s u
¢ l  { j s ˜ l x ~ z { k  i … k h ~
§ © ª « ¬ © ®
¯ ° ² ³ ´ ³ µ ´ ³ ¶ · ¸ ³ ² ¹ º · ³ » ¶ ¼ · ¾ ¿ ³ µ ³ ³ À Á Â ³ ° · ³ ·
Ã Ä Å Æ Ç È É Æ
´ ³ Ê Ë µ µ ¿ ³ Â ³ · Á ² ³ µ ³ · ¸ ° ² ² ³ ¾ ¿ ¶ µ ¶ ¸ º µ ¾ ¿ ³
¹ º · ´ ¶ ¹ ¶ º · ° · µ ¿ µ ´ ¶ À ³ · µ ¶ º · ³ µ Í Ê º ² ³ Î ³ À Á Â º Ï Â °
 ¶ À ¶ ¸ ° ¹ ¶ ¼ · ´ ³  ¹ º · µ ¿ À º Ð ´ ³  ¹ º µ ¸ ³ ´ ³  µ ¶ µ ¸ ³ À °
º Ò Â ¶ Ó ° ° ¿ µ ° ² ² ³ ´ ³ µ ´ ³ ¸ ° À ° Ô º ² ³ ´ ¿ ¹ ¶ ´ º Í Õ ° À Ö
Ò ¶ × · Á ¿ ³ ´ ³ µ ³ ² · ³ ¹ ³ µ ° ² ¶ º Ó ° ² ° · ¸ ¶ Ø ° ² ¾ ¿ ³ ³ Â µ ¶ µ Ö
¸ ³ À ° º Ù ² ³ Ø ¹ ° ¹ ¶ ³ ² ¸ º ° · ¹ Û º ´ ³ Ò ° · ´ ° Ï Â º ¾ ¿ ³
µ ¿ Á º · ³ ° ¿ À ³ · ¸ ° ² ³ Â · Ý À ³ ² º À Þ · ¶ À º ´ ³ ¹ º À Á º Ö
· ³ · ¸ ³ µ ´ ³ Â ° ² ³ ´ Í à · ° À Ò º µ ¹ ° µ º µ Ï Á ¿ ³ ´ ³ ° Á ° ² ³ Ö
¹ ³ ² ³ Â ³ Ù ³ ¹ ¸ º ´ ³ Â Ò Â º ¾ ¿ ³ º ´ ³ ¹ ° Ò ³ Ø ° ´ ³ Â Þ · ³ °
ã ä
È å æ ç è é ç ê ë ì È í Ä î Ã ï ë ì ñ ò
Ï Â º ¾ ¿ ³ ´ ³ Ó ² ° ´ ° ² Þ ° Â ° µ
Á ² ³ µ ¸ ° ¹ ¶ º · ³ µ ´ ³ Â ° ² ³ ´ Í Ê º ² ¸ ° · ¸ º Ï ³ µ · ³ ¹ ³ µ ° ² ¶ º
¾ ¿ ³ ° Â Ó Ý · À ³ ¹ ° · ¶ µ À º ² ³ ´ ¿ Ø ¹ ° º ³ Â ¶ À ¶ · ³ ³ µ ¸ ³
³ Ù ³ ¹ ¸ º Ï Ð Á ³ ² À ¶ ¸ ° ° µ Þ ³ Â ´ ¶ À ³ · µ ¶ º · ° À ¶ ³ · ¸ º õ ³ Ö
» ¶ Ò Â ³ ´ ³ Â ° ² ³ ´ µ ¶ · Á × ² ´ ¶ ´ ° ´ ³ Á ² ³ µ ¸ ° ¹ ¶ º · ³ µ Í à ·
³ µ ¸ ³ ¸ ² ° Ò ° Î º µ ³ ° · ° Â ¶ Ø ° ¹ ¼ À º ³ Â ¿ µ º ´ ³ ´ ¶ µ ¸ ¶ · ¸ º µ
À × ¸ º ´ º µ Á ° ² ° ¸ ² ° ¸ ° ² ³ Â
ä
È å æ ç è é ç ê ë ì È í Ä î Ã ï ë ì ñ
¶ · õ ¿ Ð ³ ³ · Â ° µ Á ² ³ µ ¸ ° ¹ ¶ º · ³ µ ´ ³ Â µ ¶ µ ¸ ³ À ° ¹ ¿ ° · ´ º
µ ³ ´ ¶ À ³ · µ ¶ º · ° · ² ³ ´ ³ µ ¹ º · ¸ º Á º Â º Ó Þ ° ´ ³ À ° Â Â ° Í
÷ ø ú
® û ü ý þ « ÿ ÿ
 ®
à · Â º µ Ý Â ¸ ¶ À º µ ° Ô º µ Ï Â º µ
Ã Ä Å Æ Ç È É Æ
´ ³ Ê Ë µ
µ ³ Û ° · ¹ º ·  ³ ² ¸ ¶ ´ º ³ · ¿ · ° ° Â ¸ ³ ² · ° ¸ ¶  ° ° Â º µ
¹ º À Á ¿ ¸ ° ´ º ² ³ µ À ° µ Þ  ° À ³ · ¸ ³ Á ° ² ° Â ³ Â º µ ´ ³ ´ ¶ ¹ ° Ö
´ º µ ° Â ° ¹ º À Á ¿ ¸ ° ¹ ¶ ¼ · ¶ · ¸ ³ · µ ¶  °
ã ä
ë ñ 
È É é î É ç
 å ì Ã È î   Å Ç ë ì ñ 
ä

ò
Í  ´ ³ À  µ Ï ³ µ ¸ º µ
Ã Ä Å Æ ç
Ç È É Æ
¸ ° À Ò ¶ × · µ ³ ³ À Á Â ³ ° · ³ · Â ° ¹ º · µ ¸ ² ¿ ¹ ¹ ¶ ¼ · ´ ³
       ! # ! & ' ) !  * + ' , - ! - . * ! + ' 1 '  4 ! 6 8 6 ; = . ' -
 4 1  ' ?  .  ' = 8 6 B C C E G C I J K L G 6 C N ? 1 '  4 ! P Q S . ' -  4
1  ' ?  .  ' B C C L C W E X Z
Ó ² °
· ´ ³ µ µ ³ ²  ¶ ´ º ² ³ µ ´ ³ [ · ¸ ³ ² · ³ ¸ Í à · ³ µ ¸ º µ µ ¶ µ Ö
¸ ³ À ° µ Ï Â ° ° ¸ ² ° ¹ ¸ ¶  ° ² ³ Â ° ¹ ¶ ¼ · Á ² ³ µ ¸ ° ¹ ¶ º · ³ µ \ ¹ º µ ¸ ³
º Ù ² ³ ¹ ¶ ´ ° Á º ² Â º µ
Ã Ä Å Æ Ç È É Æ
 º µ ¹ º ·  ¶ ³ ² ¸ ³ ³ · ¿ · °
µ º Â ¿ ¹ ¶ ¼ · ¶ · ¸ ³ ² ³ µ ° · ¸ ³ Í Ê ¿ ³ ´ ³ · ³ · ¹ º · ¸ ² ° ² µ ³ · ¿ Ö
À ³ ² º µ º µ ³ Î ³ À Á Â º µ ´ ³
Ã Ä Å Æ Ç È É Æ
³ À Á Â ³ ° ´ º µ ³ ·
ä

³ · Â ° Â ¶ µ ¸ ° ¸ º Á ] ^ ^ ` b c d Ï ´ º · ´ ³ ¹ ³ ² ¹ ° ´ ³
300
µ ¶ µ ¸ ³ À ° µ ´ ³ Â º µ Â ¶ µ ¸ ° ´ º µ µ ³ Ò ° µ ° · ³ ·
Ã Ä Å Æ ç
Ç È É Æ
Í f ³ · ¹ ¿ ° · ¸ º ° Â ³ À Á Â ³ º ´ ³
Ã Ä Å Æ Ç È É Æ
³ ·
µ ³ ²  ¶ ´ º ² ³ µ Ï ¹ ° Ò ³ ¹ ¶ ¸ ° ²  ° ² ¶ º µ Ó ² ° · ´ ³ µ Á º ² ¸ ° Â ³ µ
¹ º À ³ ² ¹ ¶ ° Â ³ µ h i
 å j î ì 
i
è ê  l î î ñ Ä È
º n
å  î î
Í
à · ³ µ ¸ º µ µ ¶ µ ¸ ³ À ° µ Â ° ² ³ ´ ´ ³ ¶ · ¸ ³ ² ¹ º · ³ » ¶ ¼ ·
Î ¿ ³ Ó ° ¿ · Á ° Á ³ Â ¹ Â °  ³ ´ ³ ¹ ° ² ° ° Â ° µ Á ² ³ µ ¸ ° ¹ ¶ º · ³ µ
Ó Â º Ò ° Â ³ µ Ï Á º ² Â º ¾ ¿ ³ µ ¿ ³ Â ³ · ¿ µ ° ² µ ³ ² ³ ´ ³ µ ´ ³ ° Â Ö
¸ °  ³ Â º ¹ ¶ ´ ° ´ ¹ º À º o Ð ² ¶ · ³ ¸ ` p d Ï [ · q · ¶ Ò ° · ´ ` r d º
s
¿ ° ´ ² ¶ ¹ µ ` t d Ï ¾ ¿ ³ º Ù ² ³ ¹ ³ · ¿ · ³ Â ³  ° ´ º ° · ¹ Û º ´ ³
Ò ° · ´ ° Ð Ò ° Î ° µ Â ° ¸ ³ · ¹ ¶ ° µ Í  ´ ³ À  µ Ï ³ µ ¸ ° µ ² ³ ´ ³ µ
Á ² ³ µ ³ · ¸ ° · º ¸ ² ° µ  ³ · ¸ ° Î ° µ Ï ¹ º À º Á º ² ³ Î ³ À Á Â º Â °
õ ³ » ¶ Ò ¶ Â ¶ ´ ° ´ ° Â ° Û º ² ° ´ ³ ¹ º · µ ¸ ² ¿ ¶ ² Â ° ² ³ ´ Ï ¾ ¿ ³
Á ³ ² À ¶ ¸ ³ ¹ º · ³ ¹ ¸ ° ²  ° ² ¶ º µ ¸ ³ ² À ¶ · ° Â ³ µ ° ¿ · À ¶ µ À º
¹ º · À ¿ ¸ ° ´ º ² º ´ ¶ µ ³ Ô ° ² ² ³ ´ ³ µ ¶ ² ² ³ Ó ¿ Â ° ² ³ µ Í
à µ ¸ ° õ ³ » ¶ Ò ¶ Â ¶ ´ ° ´ Û ° ¹ ³ Á º µ ¶ Ò Â ³ ¾ ¿ ³ Â º µ µ ¶ µ Ö
¸ ³ À ° µ Ò ° µ ° ´ º µ ³ ·
Ã Ä Å Æ Ç È É Æ
µ ³ ° · ² ³ ° Â À ³ · ¸ ³ ³ µ Ö
¹ ° Â ° Ò Â ³ µ Ï Â º ¾ ¿ ³ ³ µ µ ¿ À ° À ³ · ¸ ³ Ý ¸ ¶ Â ¹ ¿ ° · ´ º ³ » ¶ µ Ö
¸ ³ · ¹ ¶ ³ ² ¸ º µ ² ³ ¾ ¿ ¶ µ ¶ ¸ º µ ° Â ° Û º ² ° ´ ³ ´ ¶ À ³ · µ ¶ º · ° ²
 ° ² ³ ´ Í Ê º ² ³ Î ³ À Á  º Ï °  ³ ¹ ³ µ Á ¿ ³ ´ ³ ² ³ ¾ ¿ ³ ² ¶ ² µ ³
² ³ ´ ¿ ¹ ¶ ² ° Â À Þ · ¶ À º ³ Â ¹ º µ ¸ ³ ´ ³ Â µ ¶ µ ¸ ³ À ° Í f ° ¾ ¿ ³
³ Â Á ² ³ ¹ ¶ º ´ ³ Â ° µ À º ´ ³ ² · ° µ ² ³ ´ ³ µ ´ ³ ¶ · ¸ ³ ² ¹ º · ³ Ö
» ¶ ¼ · ³ µ ³ Â ³  ° ´ º ² ³ µ Á ³ ¹ ¸ º ° Â ´ ³ Â º µ Ê Ë µ Ï ³ µ ¸ º
Á ¿ ³ ´ ³ ¹ º · µ ³ Ó ¿ ¶ ² µ ³ ´ ¶ µ À ¶ · ¿ Ð ³ · ´ º ³ Â · Ý À ³ ² º ´ ³
¹ º À Á º · ³ · ¸ ³ µ ´ ³ Â ° ² ³ ´ Ð ¹ º · ³ ¹ ¸ ° · ´ º À  µ ¸ ³ ² Ö
À ¶ · ° Â ³ µ ° Â º µ ¹ º · À ¿ ¸ ° ´ º ² ³ µ Í v ¸ ² º À º ¸ ¶  º Á ° ² °
¿ µ ° ² ¿ · · Ý À ³ ² º À Þ · ¶ À º ´ ³ ¹ º À Á º · ³ · ¸ ³ µ ³ µ ² ³ Ö
´ ¿ ¹ ¶ ² ³ Â ¹ º · µ ¿ À º ´ ³ Á º ¸ ³ · ¹ ¶ ° Ï Ð ° ¾ ¿ ³ Â ° ² ³ ´
                  
             #
    &  &       &      * +  &      /     
                    &       6   &    #
   &      6       &      :       &       < 
6    &        <      &   @   /          #
&       C       <        E  F       &  *
+       & 
 @      I      L   &     &   #
            &    &    C           &  #
    L  <  *      /  :  @        &      : F 
6    &        /           &        & 
   &    @ 6       6      :     6  /     *
X   E   6  @           &    C       @
             \    /            6  
   &      L   &             &     <  6  
             * +  &       &    6  /  #
/          &              :   &  <  *       @
6    &             &                 #
&  6     &               :   &  < 
^
       
6 _      
`
@         6     &    /      6 
     &            6    @    /   /     #
       6     &             &   _ * +  & 
              /          /      F   

b
c d e f g h f j k l c 
b
g j
m n o p q k l r
*    I   
   :   &  <  &       6  6  :    6       #
/        &    s  E 
^
       
t m o n c u e c
p o l r c u v k  l

`
@ 6      
b
g j m n o p q k l r
6    
    &    6  &       6     &     
  E      #
   \            6   &       @    
  :        &       &     6   &        *
 \   /    @  6  /     
b
g j m n o p q k l r
6      6     &   /  _            &   6  
               &           &     
   L 6    &   6 
     &  * X   E   6  @ 6    
6  &              &               
   \    /     @                &    
6  
b
 
* +    &        @ 6           
     &   &    C       *      /  :  @
  &       &      :  &             #
&     :      6         E   @  6  &   &  @  
 L   &      /         :   &  <  @ \  / F    
6   &          6     &   6   F  
       #
&     6  
b
g j m n o p q k l r
@       6    F 
        6   &        6  &        *
+       & 
 @ 6                &    
 : I                &       :   &  <    
      :                  &     :  & 
 
^
6     6     &  
b
g j m n o p q k l r `
     
6    &  s  L  /                       & 
        6 _       6   &        *
+ 6  /     
b
g j m n o p q k l r
\     
  6      &    &       @    \   6  6    & 

   
& _       6                 *
X   E   6  @ 6         &  
k t v ‚ d n g ‚ v f
 ‚ v  ‚ c ‚ c u 

g  u

   @ 
k l d  k p d n n 

n n o f
p d v c e  ‚ n v k  ‚ c ‚ c u 
 
  u

    @
 o l r c u v k o l

‚ ! c t u
    @  &  * „      F      &   & _    #
     /         6        &   &  
m ‚ ! c t u
 &        &          &   &      &     @   
6  6        :    
F        6   6     #
/  6     6     &   /         *      /  :  @
  &   & _       6     &       
     &   @ /   
6    6  /                     I &  #
6        &     
^
 
  u `
@ /    6      & 
       /               :      &    
        6       6     &    < 
^

g  u `
*
%   6    /      6         
m ‚ ! c t u
  
         6     &    <    
g  u
  

   
^

g  l c v
 (  @ &   &  
m ‚ ! c t u
6  6   & 
    &              &   
`
@      
g  u
  
        &   
^

g  u +
@ &   &  
m ‚ ! c t u
6  6   &            &   :        &   
`
*
        &  &            <       /  @  
      &  &     &  
b
g j m n o p q k l r
*
„  & _                  
c u v k l d v k o l

d u c e

‚ ! c t  d l d r c  c l v 
  


 /       6  #
6    &          &  6        
b
g j m n o p q f
k l r
*   /       
    &  &         &    
     E   &   @     :       6   &    
m ‚ ! c t
   &   &          E   &  *   &  &       & _    #
  /   &   &        &    :     @ 6   6     & 
6  /     6      &   6  &       &     *
+   "  6  6            
 & _           #
&       :   &  <              3 5
 7 
3
c f
r k o l d n
5 :
 n k p k v  o l r c u v k o l 7 o v k ; p d v k o l

@   
     &          
b
g j m n o p q k l r
6      #
  6   /         :   &  <  * †          &   #
&     :   &  <      6   &       @      : #
              &      6           
6     &      &           \  6   &  @       
  F  &        :   &        
 &     
b
g j
m n o p q k l r
* +   "     &        3 5
 7
    #
6           6   &       &  
b
g j m n o p q k l r
        &   &  6    6          L     
%               6  6   &  @     6       &  #
   &    &    C       @      :         #
L     6   &                   /  *
†    6     &  &  /  E  6  &        @ 6 
   6  &  @ 6  /  
       3 5
 7
&   #
150 Redes y Comunicación
                           "
    #
$            # + ,          0  


 
                           
                         $   9  ;
         # 9        ,            
        
A

B  D  F
         
A

B  H J K F
"
L            ,      ,   ,    O   
  ,       + ,             0 
2
     ;
   9 ,              
L U           0 
3
  ,      ,          ,     0  + , 
       #     
               $
    Y      #      [               ;
   [                             
,                                0  
       ,                    0 
4
"
 c
d 



 
J f g i H j k


k g m g K  i H f J D K g i H  i K g  m j n
K g i H 
 ,                           0 
  9                         9          

          
q
B r s k i m t g H f
" u       #

 
     [                 0     ,   + ,  
 ,          # $                      
             + ,                w 
 ,   
A 
x  i D m i H f J D K g i H j y i D F
"

 
 ,  
+ ,      + ,    + ,              z , { 
             ,                    ;
    + ,              , [  
q
B r s k i m t g H f
  9            
 "


 
           ,   + ,              
  + ,  ,     O                        ;
        + ,                 ,   ,   
                  ,   + ,       ,   
        "   w   w  #

 
9 ,     Y   
                              ;
                   
   n


| J D D

y n
 j H m J y   g K m  g H f
A

 F
   # + ,  ,        ;
        9 ,     " }              + ,   


           
A
K x | H i i k F
+ ,         #
       ,           ,          ,  
  ,    + ,    #        [       
A
        ;
  ,   ,            $ ,         
F
+ , 
       [      + ,         w      ,     "

 #            
K x | H i i k
  ,    + ,    # , 
    ,      ,        ,             
            ,   ,                 "
u         z , {                
   #

 
      ,     { ,             ;
              ,            $        "
L         
 J K

D g y J  x J x J D


 D 
#
$                               
  + ,              , [    ,   ,   
                   " U     ,    


 D
            ,        



#  , $    ;
                 9      0           
              ,          w  $          
       0  $                        



" u         [                 
    + ,    # ,  
      ,  



   w  ;
     w    + ,    w  $       
       
    + ,                     
D K j H y j | y
                      0       w 



"
L         ,           ,   ,       



    O        + ,           
D K j H y j | y
"

                0             0  # 
      ,                  ,     0   
        ,          ,    + ,      ,  
                    $     ,     0  , ;
        ,    #   
     ,       
  + ,           + ,    ,            0 


 
#          + ,  ,   ,             
            "            0           
,              #    ,                
   ,            O        " u         ;
    0            ,               #  
 
   ,       ,                   ;
    " u             #      
D K j H y j | y
 
          
         
m i k j D y J y J n
K J m m g  H
                    ,     #  
    + ,  ,    + ,    + ,      ,     ,    
                          0         
       + ,         "   ,                0 
,      ,    #    ,                 
   ,                      w      "
}             

 
    , $       ;
9      0                 
A
, 
K x | H i i k F
               [     ,              ;
         ,    + ,                 0  "
  
 [          #       ,    , 




$                           
   



    
K x | H i i k
      "    
         #       + ,    + ,      ,  $
 $ 
         ,               
A
  + , 
                   
K x | H i i k
     ;
+ ,            


 F
             



#               
q
B r s k i m t g H f
+ , 
 ,        "
,
 [ #  ,  



     ;
XVI Jornadas de Paralelismo, JP '2005 151
   
             
 
  
           


 
  " $ %    
  '     )       
   +

     
,
-  . / 1 2 3 5

 '       " 8  9  )  )    ' 

=  
       
  '  $    )       




 @
 ' A '    ' 
 C     D F    H 
C             ) 
  "  '             ' '       "    
   )   

" 
   N  '    "         $  '      )   )  C  ) 
=    "  "  9 
'  "  '


 .
)  S '    "  '   
 )  '
)  "  '


 .
 '     )  '  " C      
/ - 1 U  V V W .
)  C  @ 
"   $    ) D  ' A  "    H 
C      '  [

"     $  '     '  
   $  )    
     
  
 '  $    )  '     ' 
  ) 


 .
=    " C      
  =     '  
          '    C  ' C  
[  " D
 )  C  ' )  "   '  $       ) 


 .
 
    +
         " )      
   $  '       "  '   
 )  '
'   '  $     



  )   N    
   @   )  ' "  '
  =     '  " C      )  '   "    "  )  )        

 '    '  [ "    '   ) 

    C      )   N 



D
e  "  '   
 )  ' )  "  '


 .
 h  '     [  
)     
 "  
 '  [ 
=  S


 .
 '      "  '
 h 
 C  '
,
"  '  N  9  ' 
5
)  " 
[  " )     $  '     D

   



 '  
  A  @  '    N  9   '  "  [ 

@  
A                )  "  [ 
       '   +
  )  
m V  U . / 1 2 3

,
 " '     )  )  "  ' 8  9  ' ) 
)    '
5
D  "
   [ 
 '               " 




 +
    
 '    

 
   N  9  @  ' 
   )

"  [ 

'   @  ' A N  '    "    
" 
 A )  " 
[  " D


 
 C  "  C      
   ) 



     +

 " )  8  9   '      "  )    C    ) 

V U 


V 
,
'  C  " 
 "  "  '   
 / V    V 5
D e '      
 "  '
)  H 
    )  "  '  )   
 "  '   "  '
. / 3 U m 3 1 m

)  )          =      '  ) 
 )  '     [ "   

   " =   
 )   '   '   "  '   )   "  '      "  +
[
 )  "  C  C 
  )  "   
  D
 '   ' 
  '  
   
 "    "  '


 .
 "  ' 8  9  '    $  '      )  '
  )
A   " "   

   )  C     "  C  C 
  )   
  
   C    
 ' =    "  '  ) 

V U 


V 
 '  +
$ 
 =      $   



  ' 
 )    
   
 " D
 
 ' )    " "  ' ) 

 
'  )  ' 
 [        D
 t
   u  v   w x y  z y { |  v  } w y {
e   '   '       
 "  
 C  ' "  ' 
 '        '
) 
 )  '        "  $ A  )  C  " "   C  "    ) 
)  '      ' )  C   '     ' )  "  C  ' C   )  '      '
  
   ' )  
    @ )  '      ' C S   )  '  


  
 "
~
 € ‚ W V ƒ „ … U †

 
  
 " ) 
 )
,

  U 2 / 5
 
 
  
 " )     C    ) 

,

 ‡
 .  5
 @

 
D ˆ 

  "  
 '   
 "      
! # %  ' ( # ) # + #   , ! # %   . , 0 # 1 3 5 ( 3 1  7 % , + 3 5
0 3  , + + , ) # 1 : # %  '
<
16 × 16
= > ? <
=
8 × 8
? @ @
A
4 × 4
< ? < ?
@
8 × 8
? @ <
>
4 × 4
< ? <
‰   )
 C ‰    $ 
      ' ) 
 ) 
 "   )  ' D
N  C  '  '  )    '  C  "  ) 
[  '  )    
    '
=    
C    C  )  " 
"  '
 )  '  "  ' 
    ' @
"  ' C      ' C  '     ' 
  ' D   ' 
 [ 
 C  '   

 C 
"  $ 
  " '  C  "  ) 
@ "  '  
 C  
 '
   '  ) 
 )  '   "  ' 
  [  '   
 "   $  
 +
'    
"  '
 '  "   )  '  [     )  ' @    "  
"  ' D
    " # $ % & # $ % * + - / & 2 3 + 4 6
e " '  C  "  ) 
C  )  "  C  " "  ' [  )  C   '     "  '
   )
 )  '    C    '   '  
   % C 


  +
[ "  )     C    ) 
 ' @   "    '           
[  ) 
       "  '        % C 
   C [  S 

  +
[ "  )   
C    "  '        )  '  "  =    
C   

 "  
"  ' 
 '        ' ) 
 )  ' )  )  '      '
)  C   '     ' D e     
    N  C  '  '  ) 
5
   +
 $ 
      ' ) 
 )  C  ' 
 )  '    "    )
 C D
  [  )   " )  '       % C 
 )   
C    "  '  

   C    ) 
    )      $ 
       "  % C 

)    
  '  
   C    ) 
 '

  [ "  D e   ' +
  '   
  '        "    
 )    C   "  '  "  +
)    " '  C  "  ) 
C  )  "     C  C 
  ) 
128
7 8 D F  $  '     )   '   ' C  C 
  ' )     ) 
)  " C      ' C  )     
 " )     $  '      C +
 "   )    "  ' 
  [  ' D
 '   C  "   
  U 2 /

"  C  C 
  )  "   
  )    
 )   '  "  )  ' 
) 
 )   =      
 C            '   "  '   C 
 
C    "  '  h  '          "    " '  '   C  D
 ' 
 C  "   
  . 
 "  C  C 
  '  ) 
 )       +
  '   "  '   C    
  '    $       C    ) 
D
ˆ 


 
 "  C  C 
  )      
   '   C +
 
  )   
  )  ' "  '   "  ' )     )  '   )   N 
  
      C  C     )  )   )  H 
C  )    C  +
 
,
"  '   " )  ' )  C  C 
  '   '  $          " 
@ '  "  [ 
      )   '     ' 
  @   '  [ " 
5
D ˆ 

        "  '   
 )  ' "  C  C 
  '    C  
 
 
"  '   "  ' )  )         @ "  '


 .
   
 '
    C  C     )  )   @   "  ' '  "  )  '  
" 
  " 
. / 3 U m 3 1 m
@ "  '


 .
D Š      
 "    +

 )    C   
 "  '  "  )   '  N   '   [ "    ) 
152 Redes y Comunicación
 
    
8 


            

 #                    .      
 .        
 
0   2  3    .          6
  7    2   .   
;
  .   2  2      0      7   
2   .     A 7 
B C  B 
0  . 2
D
0 E  2   6
   .       2 #                2     
  E  .     .   J          2   .    .   6
.                          .  2 2  M  
2   N   .  M  3     O     .   2  2     
P               #        S      6
   2          .   .        .   .   
6
W       2     #                
  2 #       
8
Z  
0 .         M 
[ \ ] ] `
a \  ] b
3   N    .  2  M    .   J  2   .   
2    .      .     0   #           

e f B   Z g f
  .        .   .       .   
2            0 2      j     2    2  2     
   2       .  2 2  M         



J              .    .   .   j      
2   .     A 7  m     
 
0     2   .   
 A 7         2  p  .             6
.  0 E         2            .       6
.     E  .        2   
 q g C a g f a
   
 

   .        .    2    .    0     . 
 2   .     A 7         J      .    0   .  6
.    2  p  .                     .  
    
;
   .   
D
       .    t    
             N    .     .     .   
;

    
D
  
 0   #          2   .    
A 7 
B C  B 
m         2             
  
u 
  #         2   .     A 7 
       2  p  .      2    J    .  2    0  
 v      2  p  .                  2   
   .                 .    t    
             N    .     .  3    v    
 2              2 #     .  W      6
  7    2   .     A 7  2      .       2 #  
             2        E  .     .  

     E     .            2    2 .   
   2    .             .         6
.   
;
 C  \ q

a g  q b f 
0


 D
y  

     6
   2     v      7   2           M  0
  N        E    
u C b q
;
.   .   2    
2    .                 .   
D
3   v    
         2        3  2 2  M  0 E    N   
       E    E        .         
   2    .          2     2         O 0
   #    



              



 
     
 
y      N            7  0
         # $   %  $ & '    ' ( * , 
- # *     ' * ' (  ' ( * 3   ' * ' (  ' ( * 3
*     
4 4 6 6
# $ ' # * 3 7 7
8 9 : 3 ;
# $ ' # * 3 4 8 3 ;
<  * 7 ( >  *
? : ;
# $ ' # * 3 8 ;
<  * 7 ( >  *
y    @ A m  .       . 
 2         
      2        2          M   

    N 6
       .    0 3   .       .     j     
  2       3  2 2  M  0            E  .  

 #            E  .   
64
 3 .  
                 
          S         2   .       2    6
N   2            .              .  0   6
     .     p      .  M   . 
 2      
     .       . 
 2     . p .  2 
;
   .    
    2    @
D
E    A  7     .  2            
      N    2  .     E          .          
   2 2  M       j     .     2          .    6
.   .   2      .      .     . 
 2 
J  .         .      0     2   .  7       6
    j   .     3  2 .  . 
 2     .         .  6
    J  .     2   .  7     
100 
        6
.  M 
1
0                .     
2
3
3
J 
  .   2     0      .   j   .     3  2 .  . 
6
 2        M     .   
;
D B q `   B q D
0 2     

       2   N   .  M  J  2        0   
j   .     3  2 .   . 
 2  2          .    0
E    #          2      .      .         6
.   .               .             
    .  2        j  2  M     2   N   . 
 2 
           
 2   .    2  M       .        .       6
   2  M  E       .        S         2 .   
    
 
3 
u  
 2       .       

         .  2           2        .  
  E    .                   .  P     p 
     .        .        
u C b q
0 2   
  j     2       
         .  2          6
   
;
2     .  . p 2   2  0  

u € Z ] B e  ‚ C ƒ
  2 
        2  
D
J         N        S      
  2       E      .    t         .  
      2   2      3 2   .  0 3   N    2  6
    E                      N    
XVI Jornadas de Paralelismo, JP '2005 153
            
   
         %   '   *   + - 
  *   *  *      2     %  + -   '  *   
  *  
       -      * ;  +  > ' 
-     *     -     *     *   *       '  E
          H  > '   * 
         *    E
        * K    *      +  %        E
     *     2     %  2 -   '  *    E
  *    * 
    *    
Q
'   R    
T

   

     
      
  "  # U    * 
   +  ' -        > '               *  
*  X     + -           *         E
*  *    K      *         H   *  *  +   E
-       -   
          '       
  
1
+
2
2
3
    ' 

Q
+ + 
T
 '   *  
-    *        *     -    *       '  E
      '    '  - *  %   * 
   *  *    * 
'   R    
Q
- *  % 
1T
 H '           > '   
  ^  
        
`    -    * E
         *               + -    b  * 
              *  -  *      2     % 
*   '     ' 
d  f 
             
U  *       > ' 
d  f 
     *     E
 '    *  
g
d h j k l m n o p q
> '  -     
       ' *      *         '  

 +
 2
  > '  ^
- '     '      > ' 
d r
 f 
  '    '   %    - *  -      
* 
        ;           +  * 
  
   '    '   
R   + 2     *      
    -     *       ' *        '  
 +

  2
 R  '   *        ' *   -       E
 '          
1
+
2
2
3
 '     '  '  - E
*  %   * 
       `   *  ' 
 l t r f  l t
   

Q
- *  % 
2T
 H  *         '        
  +
d  f 
        '   *     %   
`  E
  -    *       -  *      2     %    E
   *   
 K  + -       '    % 
  
1
+  %          '   ' 
50 

-   '  *      *    H  *  X     
       +
d  f 
*           '   '   E
2   -   '  *      *      *      
> '      * '       ' *         + 
> '    '      -  *  
g
d h j k l m n o p q
 H  
 *  -  *  + 
 
      '  -   `      * 
$ &
     ! # $ ' $   ' (  # $ '  ' (   ' * ' !  ( !  (  !  ,
  (      ! # $ ' $   - *  (  #  $ ' $ $     (      ! ,
# $ ' $    ) $   # '   $ !  * +  ' ' *  * ' ' ! ' * ' (  3 ! 4  '
-  3  ' (  - $ * ' ! ! $  3 5 - *  *      3    ( (  '
N × N
*
(      ! # $ ' $    ) $   ' *
4 × N
- 6 # ' * 0 3 * 5

`   -   '  *      *  
Q
90 
  
-      
T
 8   - '   +   *              

g
d h j k l m n o p q
-   '    -   
      E
   *  %  + 2 -   *  *  -     *  ' *   ^        *  E
   *          R      -     
H  '  - *  %   * 
      ' 
 l t r f  l t

   *    
Q
- *  % 
3T
+      ' *          E
   + -         %   -    *       - 
d  f 
  
  ' 
Q
  '  
  +
  2
 
T

U      *   + 
 
-     *        '   

`    -    *                
- 
 *      *  *   
g
d h j k l m n o p q
  
 2   '              
d  f 
+
-    ' -  *  +   *
 ;          '    
`  E
         R      -      
   *       '    *  
g
d h j k l m n o p q

1
    "     4 
5    8 4   4 # U    E
*     %    '          -   *     *  
d  f 
2 
 
 '    *  X    
  '    * -   R       2         E
 H  *         '             E
'      *      % 
Q
     '       
1
+
4
2
5T
+   K      *             *    E
    ' *         *  * 
Q
1T
 H   *  *  +
'    *   *  X     + '    * 

 K      *        + 2 *   b      * '
      ' *  > '     '     - > '  *  
Q

> '          *        
g
d h j k l m n o p q T

    '   9  + 9  2 9    '   *   
-    *       -     *   *       '       
    '     '  '  - *  %   * 
   '   E
R    
Q
- *  % 
1T
 8    *    *     ' * E
 -    -       > ' 
d  f 
     -   *

        R         
 

d r
 p | t
+ 2 > '  -   *  *  -       '    '   % 
  - *  -  
g
d h j k l m n o p q
   ' E
   *   *  X      H    +  *    ^ +
  *  '    %      
  '   -     ' 

         *  %       '   9  + 9   2 9  R
 '   *        ' *   -  '  - *  %   * 
E
   > '     *     ' 
 l t r f  l t
   

Q
- *  % 
2T

H '      -        '    > ' 
d  f 
 
   '    
g
d h j k l m n o p q
> '  -         * 
   + 2 -         -            
  R      -    
Q
-   '  *   
  *   - 
d  f 
 '   -  
70 
T

    '   9   + 9   2 9    '   *        ' * E
  -  ' 
 l t r f  l t

   *    
Q
- *  % 
6T

154 Redes y Comunicación
10
20
30
40
50
60
70
80
90
100
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
     
 

1
10
20
30
40
50
60
70
80
90
100
5 10 15 20 25 30 35
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

2
10
20
30
40
50
60
70
80
90
100
2 4 6 8 10 12 14 16
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

3
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw

     
 

1
10
20
30
40
50
60
70
80
90
5 10 15 20 25 30
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

2
20
40
60
80
100
5 10 15 20
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

3
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

1
10
20
30
40
50
60
70
80
90
100
5 10 15 20 25 30 35
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

2
10
20
30
40
50
60
70
80
90
100
2 4 6 8 10 12 14 16 18
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
      
 

3
   

          
   
  



  "    
   "      
1
$
2
%
3
$ 
   "      '    
$ ) $  
1
$   $  $ , 
2
%   $ . $  
3
0
 2 4 5 6 7 9 ; 9 = 5 ? 
 
@ ; 6 7 = B 6 B 2 ; E F 9 B E 7 ; I
4 = 5 6 B E ; 2 @  L = @ 5
N
; 2 6 = ! B 2 O B 
P  Q R T U
F ; 9 ;
7 5 O ; E 2 ; E 4 5 6 # X Y 9 ; 4 = 5 6 B E O B 9 B O Z 
 
4 5 6 I
E = X Y B B E 7 ; E F 9 B E 7 ; 4 = 5 6 B E Y E ; 6 O 5 Y 6 @  L = @ 5 O B
8 
$
 \
? F ; 9 ; 4 Y ; 2 ] Y = B 9 7 ; @ ; _ 5 O B 9 B O ? F 5 9 2 5
] Y B E B 7 9 ; 7 ; O B Y 6 ; 7 d 4 6 = 4 ; B E 4 ; 2 ; e 2 B Z
 g

i k l  m n % i k o n
 B @ 5 E @ 5 E 7 9 ; O 5 2 ; = @ F 5 9 7 ; 6 4 = ; O B B @ F 2 B ; 9
Y 6 ; 7 d 4 6 = 4 ; ; F 9 5 F = ; O ; F ; 9 ; B 2 4 5 6 7 9 5 2 O B 2 ;
4 5 6 X B E 7 = v 6 ] Y B B 2 = @ = 6 B 7 5 7 ; 2 @ B 6 7 B B 2
x
P z
{ | } ~  € Q 
] Y B F Y B O B ; F ; 9 B 4 B 9 ; 2 O = @ B 6 E = 5 6 ; 9
4 5 6 O = E 7 = 6 7 5 E 4 9 = 7 B 9 = 5 E 9 B O B E O B = 6 7 B 9 4 5 6 B L = v 6
4 5 6 7 5 F 5 2 5 X … ; O B @ ; 2 2 ; Z  B 2 5 E 9 B E Y 2 7 ; O 5 E F 9 B I
E B 6 7 ; O 5 E B 6 B E 7 B 7 9 ; e ; ‡ 5 ? F Y B O B O B O Y 4 = 9 E B ] Y B
2 ; E F 9 B E 7 ; 4 = 5 6 B E O B 2 ; 9 B O E B ! B 6 E B 9 = ; @ B 6 I
7 B ; ‰ B 4 7 ; O ; E F 5 9 B 2
x
P z { | } ~  € Q 
4 Y ; 6 O 5 E B
Y E ; 
P  \ 
Z Π5 9 B 2 4 5 6 7 9 ; 9 = 5 ? B 2 @ B 4 ; 6 = E @ 5

 
F B 9 @ = 7 B O = @ B 6 E = 5 6 ; 9 2 ; 9 B O O B ‰ 5 9 I
@ ;  B L = e 2 B 4 5 6 O = E 7 = 6 7 5 E 4 9
= 7 B 9 = 5 E @ ; 6 7 B 6 = B 6 I
O 5 ? ; 2 @ = E @ 5 7 = B @ F 5 ? F 9  4 7 = 4 ; @ B 6 7 B ; 2 @  L = I
@ 5 2 ; E F 9 B E 7 ; 4 = 5 6 B E O B 2 ; 9 B O ? X 9 ; 4 = ; E ; Y 6 ;
X B E 7 = v 6 B # 4 = B 6 7 B O B 2 F 9 5 e 2 B @ ; O B 2
x
P z { | } ~  
€ Q 
Z  O B @  E ? 
 
B E Y 6 ; 7 d 4 6 = 4 ; 7 5 7 ; 2 @ B 6 7 B
B E 4 ; 2 ; e 2 B Z ‘ 6 O B # 6 = 7 = ! ; ? 
 
F B 9 @ = 7 B 7 ; 6 7 5
9 B O Y 4 = 9 B 2 7 ; @ ; _ 5 O B 2 ; 9 B O
N
F ; 9 ; O = E @ = 6 Y = 9
B 2 4 5 E 7 B ” B 2 4 5 6 E Y @ 5
U
4 5 @ 5 ; Y @ B 6 7 ; 9 2 5
N
F ; 9 ;
4 5 6 E B X Y = 9 @ ; ” 5 9 ; 6 4 • 5 O B e ; 6 O ;
U
E = 6 O = E @ = 6 Y = 9
2 ; E F 9 B E 7 ; 4 = 5 6 B E O B 2 ; 9 B O B 6 6 = 6 X – 6 4 ; E 5 Z
— o  o ˜ o k l %
n
( ) *   O ! ; 6 4 B O   = 7 4 • = 6 X ™ 5 9 B  9 4 • = I
7 B 4 7 Y 9 B  F B 4 = # 4 ; 7 = 5 6  Z  ! ; = 2 ; e 2 B ; 7
• 7 7 F , - -    Z ; E = I E = X Z 5 9 X - E F B 4 = # 4 ; 7 = 5 6 E Z
( . * š Z  6 O B 9 E 5 6 B 7 ; 2 Z ?   = X • I  F B B O   = 7 4 •
 4 • B O Y 2 = 6 X ‰ 5 9 ž 5 4 ; 2 I  9 B ;  B 7  5 9  E  ?
$
   Ÿ   Q \   ~ T € } Q \ } Q  } 0 2 ¢ T R Ÿ   \ T R 0 \
?
! 5 2 Z ) ) ? 6 5 Z  ? F F Z 4 )  ! 4 5 . ?  5 ! Z )   4 Z
XVI Jornadas de Paralelismo, JP '2005 155
10
20
30
40
50
60
70
80
90
100
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
   

 

1
10
20
30
40
50
60
70
80
90
100
5 10 15 20 25 30 35
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

4
10
20
30
40
50
60
70
80
90
2 4 6 8 10 12 14
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

5
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw

   

 

1
10
20
30
40
50
60
70
80
90
5 10 15 20 25 30 35
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

4
10
20
30
40
50
60
70
80
2 4 6 8 10 12
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw

   

 

5
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

1
10
20
30
40
50
60
70
80
90
5 10 15 20 25 30 35
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

4
10
20
30
40
50
60
2 4 6 8 10
Relative
Throughput
(percent)
Generated traffic (bytes per nanosecond)
VOQnet
RECN
VOQsw
    

 

5
   

           
   
  



  "   
   "      
1
$
4
%
5
$ 
   "      '   
$ ) $ 
1
$   $  $ ,
2
%   $ . $ 
3
0
    2  2  4 6 8 9 8 ; = ? 2 A ! C D E 9 8 ; F " H E H = I E ; K 8 D
N 8 P 4 9 6 ? 4 P = ? = D 8 = 9 8 ;  4 D  A


  
 V W X Z
A
K K 2 $     A  8 I 2 %   & 2
    2  2  = ? ? C 8 ; = ? 2 A ^ _ 8 " ' E P E ^ 8 D = I E ;
 E ; P _ )
4 e ; 8 D
A E 9
* X Z W

g
Z h  i h j X W Z i k
i j W h l 
A " e H 2 %   , 2
 &   2  e = ; 4 A . 2  4 _ 9 N 4 9 A  2  ? E P _ A  2  = ' 8 9 A
n 2  2  = D P o = A ^ 2  = P _ E 4 9 6 4 A "  8  P = ? F
= I ? 8 = 9 6 s 4 N ; F t  8 P ; E ' 8 s 4 9 H 8 N ; E 4 9 ! = 9 F
= H 8 u 8 9 ; ; D = ; 8 H C x 4 D y 4 N N ? 8 N N ! e ? ; E N ; = H 8
. 9 ; 8 D P 4 9 9 8 P ; E 4 9  8 ;  4 D  N
A E 9
* X Z W

g
* 2
3
 
h 5
A K K 2 % 7 ,  % %  A  8 I 2 $ 7 7 & 2
    2  e = ; 4 A  2  ? E P _ A = 9 6 ^ 2  = P _ E 4 9 6 4 A
s 4 N ; F t  8 P ; E ' 8 ^ 8 P _ 9 E } e 8 ; 4
8 6 e P 8  9 y
 ? 4 P  E 9 H E 9 E 9 H ? 8 F ; = H 8 = 9 6 ! e ? ; E N ; = H 8
 E ; P _  = I D E P N
A 
~ X Z : V W X Z 2 Z i € j X j i W j Z i
*  X  ‚ ‚ j ‚ ;

V l h X V ƒ ~ h j „  i „  j h  Z X … k ƒ  l j „
* X Z W j l l V i †
A K K 2  , F &  A  8 I 2 $ 7 7  2
 <  . 9 > 9 E  = 9 6
T M ^ D = 6 8 " N N 4 P E = ; E 4 9 A
5 h h ?      
V i  i V ƒ  i „ h 
W Z :
2
 , 
@
e = 6 D E P N
@
N  8 ; 2 " ' = E ? = I ? 8 = ;
_ ; ; K A ) ) 6 4 P 2 } e = 6 D E P N 2 P 4 u
   y 2 _ = 9 H 8 ; = ? 2 A  C 9 = u E P  4 ? ; = H 8 P = ? E 9 H
 E ; _ y E 9  N x 4 D n 4  8 D 9 K ; E u E ˆ = ; E 4 9 4 x . 9 F
; 8 D P 4 9 9 8 P ; E 4 9  8 ;  4 D  N
A E 9
* X Z W

g
* 2
3

h 5
A K K 2  %  % 7 $ A  8 I 2 $ 7 7  2
 % 7  " 2 u = E 8 ; = ? 2 A  ? 4 I = ?
8 = P ; E ' 8 s 4 9 H 8 N F
; E 4 9 s 4 9 ; D 4 ? E 9 ! e ? ; E P 4 u K e ; 8 D  8 ;  4 D  N
A
E 9
* X Z W
# h 5  i h j X i  h V Z i  ‚ 2 Z i € j X j i W j Z i
g
V † 5 * j X € Z X :  i W j 2 Z : ? ~ h V i †
A %   , 2
 % %  G 2 ^ = u E D = 9 6  2 y 2  D = ˆ E 8 D A  C 9 = u E P = ? F
? C " ? ? 4 P = ; 8 6 ! e ? ; E F
@
e 8 e 8  e  8 D N x 4 D  y .
s 4 u u e 9 E P = ; E 4 9  E ; P _ 8 N
A

  
 X  i l  W k
h V Z i l Z i 2 Z : ? ~ h j X l
A ' 4 ? 2  % A 9 4 2  A %   $ 2
 % $  ^ 4 K & 7 7 N e K 8 D P 4 u K e ; 8 D ? E N ; A
5 h h ?      
h Z ? # ' '
Z X †
2
156 Redes y Comunicación
HOL Blocking reduction with a New Cost-Effective Strategy in Multistage
Networks *
T. Nachiondo, J. Flich, and J. Duato
Dept. of Computer Engineering
Universidad Politécnica de Valencia
Camino de Vera, 14, 46071–Valencia, Spain
E-mail: {tnachion,jflich,jduato}@gap.upv.es
3 de junio de 2005
Resumen
Head-of-line blocking is one of the main prob-
lems arising in input-buffered switches. The best-
known solution to this problem consists of us-
ing Virtual Output Queues (VOQs). However this
strategy is not scalable. Its implementation cost
increases quadratically with the number of ports
in the switch. Taking into account current trends,
the demand for larger number of ports in high-
performance switches is likely to increase very
rapidly in the future. Therefore, a scalable and cost-
effective solution is required.
In this paper we propose a very efficient
and cost-effective strategy (belonging to a fami-
ly of strategies previously proposed, referred to as
Destination-Based Buffer Management (DBBM)),
to reduce HOL blocking in single-stage and mul-
tistage networks. The proposed strategy is based
on allowing certain destinations to share the same
queue. Its main purpose is to maximize network
throughput whereas keeping HOL blocking to neg-
ligible values. In this paper, we apply the strategy at
every switch included in a bidirectional multistage
network (BMIN). We have evaluated DBBM, VOQ,
and alternative strategies in different BMIN sizes
and with synthetic traffic. Results show that DBBM
with a reduced number of queues at each switch
obtains roughly the same throughput as the VOQ
mechanism. Moreover, VOQ at the switch level (as
many queues as output ports at every switch) has al-
*
This work was supported by the Spanish MCYT under Grant
TIC2003-08154-C06-01 and by Universidad Politecnica de Valen-
cia under Grant 20040937.
so been analyzed. Results demonstrate that it does
not scale at all. As the number of stages in the
network increases, the VOQ solution at the switch
level introduces more HOL blocking that leads to
a severe degradation in network throughput. With
the DBBM strategy using 16 queues, maximum
throughput is sustained for all the traffic cases an-
alyzed. Moreover, as the network size increases (up
to a 2048×2048 BMIN), DBBM keeps roughly the
same performance with the same number of queues.
1. Introduction
Nowadays, parallel and distributed computing is
evolving towards network-based computing, where
supercomputers, server clusters and terminals col-
laborate and exchange data through Internet. In all
these systems, a common switch-based intercon-
nection has been used to provide an efficient and
scalable interconnection structure. For the intercon-
nects used in parallel computers and server clusters
an increasing bandwidth demand has been observed
as a common requirement.
One way to satisfy this demand is by increas-
ing the number of ports in the switch, but this in-
troduces new problems. Traditional switches use
queues at their output links. They are known as OQ
(Output Queuing) switches. However, this scheme
requires the switch to operate at a much faster speed
than the link operates in order to handle all the
possible packets arriving at every input link. The-
oretically, a N × N switch must work N times
faster than the link speed. As link speeds increase
to the Gbit/s range and switches have much more
1
input ports, this scheme becomes infeasible. A so-
lution adopted to overcome this problem is the use
of switches with queues at their input links. They
are known as IQ (Input Queuing) switches [4, 5].
Head-of-line (HOL) blocking is one of the main
problems arising in high-speed switches, due to the
use of FIFO queues. It occurs when a blocked pack-
et at the head of the input queue prevents packets
behind it from reaching idle outputs, leading to se-
vere throughput degradation. In [7] the best-known
solution to the HOL blocking problem is present-
ed. It consists of using as many queues as output
ports in the switch, one for each port. This solution
is known as Virtual Output Queues (VOQs). The
cost of implementing VOQs increases quadratically
with the number of output ports in the switch fab-
ric. Although there exist commercial implementa-
tions of VOQs for a large number of ports (e.g., Avi-
ci Terabit Router [1], with 520 virtual channels per
link), this solution leads to very high costs and it is
not scalable at all. The situation is aggravated when
several priorities and/or Quality of Service (QoS)
levels must be supported in the switch. Taking in-
to account current trends in the demand for larger
number of ports in high-performance switches, the
VOQ solution is no longer cost-effective, and may
even become infeasible. Therefore, a more scalable
and cost-effective solution is required to reduce or
eliminate HOL blocking.
2. Motivation
Temporal and spatial locality in the packet des-
tination distribution suggest that a small number of
queues should be enough to store incoming packets
while still classifying them according to their des-
tination, and thus, eliminating HOL blocking, al-
though not completely. In general, there is a trade-
off between performance and the number of queues.
The idea is to use a small number of queues in each
endnode and switch (a fraction of the number of
ports in the network), together with a suitable map-
ping scheme that promotes a proper utilization of
those queues and exploits locality.
In [3] we presented a new methodology, re-
ferred to as Destination-Based Buffer Management
(DBBM), to reduce the HOL blocking effect on
interconnection networks using eficiently the re-
sources (mainly memory queues) of the network. In
particular, DBBM maps packets addressed to differ-
ent destination nodes to different queues, thus, elim-
inating the HOL blocking among particular flows
heading to different destinations.
With the previous approach, each flow is mapped
to only one queue and that queue only stores pack-
ets for just one flow. One possible drawback of this
approach is that the number of required queues is
unbounded. For this, the DBBM methodology also
defines a simple mapping method that allows differ-
ent flows to share the same queue. Although HOL
blocking will be introduced among flows sharing
the same queue, this approach allows to use a re-
duced set of queues. Indeed, the simplest mapping
(flows to queues) method is based on the coding of
the destination. In fact, some bits of the destination
address are extracted from the packet header in or-
der to select the queue to place the packet in. This
method is referred to as modulo mapping (as a set
of the lowest bits are extracted). As an example, if
we have 16 queues and the network has 256 destina-
tions, the four least significant bits of the destination
ID (8 bits) indicate the queue to map the flow into.
The methods based on sharing queues among
flows try to obtain a trade-off between the per-
formance achieved and the number of available
queues. In [3] we evaluated DBBM applied to the
endnodes. The purpose was to study only the effects
of the HOL blocking at the endnodes and the bene-
fits of the method, thus we used a network with no
HOL blocking (a single switch with full end to end
VOQ at every input port). With the modulo map-
ping method, we showed that the required number
of queues at the endnodes to practically eliminate
the HOL blocking effect was low. We reduced by a
factor of 8 the required number of queues (taking as
a reference a VOQ solution).
However, the modulo mapping method can be
easily applied to each switch in the network. In-
deed, in a realistic scenario with a large network,
it is necessary that the same mapping method is ap-
plied both at the endnodes and at the switches. In
this paper we take on such challenge. We apply the
modulo mapping method to the interconnection net-
work. In particular, we will focus on bidirectional
multistage networks.
Also, in this paper we will evaluate different al-
ternative mapping policies to compare with. The
most interesting one will be the VOQ solution at
158 Redes y Comunicación
the switch level. With this solution, every input port
of every switch has as many queues as ports at the
switch, and a queue will be assigned exclusively to
a port.
Finally, one of the primary concerns for the
method is scalability. For this reason, in this pa-
per we will also evaluate how the method behaves
in different BMIN sizes. We will see that the shar-
ing queue approach will scale in the number of
queues and, more interestingly, will keep low the
HOL blocking introduced. Indeed the VOQ solution
at the switch level will increase the HOL blocking
as the network size increases, thus degrading per-
formance.
The rest of the paper is organized as follows. In
Section 3 the DBBM methodology is described. In
Section 4 the modulo mapping method is evaluat-
ed in terms of performance, resource requirements,
and scalability issues. Finally, in Section 5 some
conclusions are extracted and future work is plot-
ted.
3. Destination-Based Buffer Management
The DBBM strategy is a family of buffer man-
agement strategies that aims at reducing the total
buffer requirements while keeping roughly the same
network throughput as when using VOQs. In or-
der to do so, DBBM takes advantage of tempo-
ral and spatial locality existing in packet destina-
tion distributions. In DBBM, packets are stored in
queues sorted by destination. However, as the num-
ber of queues is smaller than the number of ports
in the switch fabric, packets with different destina-
tions sometimes may be stored in the same queue.
DBBM strategies will exploit packet destination lo-
cality in order to reduce HOL blocking. For a de-
tailed description of the DBBM family refer to [3].
One of the alternatives of the DBBM family is the
shared-queue buffer management. In this case, each
buffer queue behaves as a FIFO queue. This strategy
works as follows. Each queue can only store packets
for a subset of destination ports. This can be viewed
as if the physical output ports of the network were
grouped into a smaller set of logical output ports
and a queue was used at each switch to allocate only
packets destined to a particular logical output port,
i.e., VOQ at the logical port level.
This strategy should be designed in such a way
that the total number of queues and the number of
destinations mapped per queue (the size of the log-
ical port) reduce the HOL blocking effect to the
minimum. Note that in-order delivery is guaranteed
as packets for a given destination can only use one
queue and are stored in that queue in order of ar-
rival.
When a packet arrives, a mapping algorithm
computes the logical output port and, therefore, the
queue that will be used to store that packet, as a
function of its destination. It can be done simply
by removing some bits from the destination ID in
the packet header. However, it is not clear whether
consecutive port addresses should be mapped to the
same queue (block mapping) or consecutive port
addresses should be mapped to different queues,
cycling again when all the queues have been tried
(cyclic mapping or modulo mapping). Therefore, it
is necessary to run simulations in order to determine
which is the best mapping strategy.
The mapping algorithm described in this section
is simple to implement. Which bits are removed de-
pends on the mapping strategy, as discussed above.
In particular, block mapping is implemented by re-
moving the least-significant bits in the packet ad-
dress and cyclic mapping is implemented by remov-
ing the most-significant bits in the address.
The main advantage of allowing queue sharing is
simplicity. Just a suitable mapping method imple-
mented in hardware is required. Simply, incoming
packets will be buffered in the queue whose ID is
computed by the mapping method. While this strat-
egy does not directly avoid HOL blocking, it may
reduce it to negligible values when a suitable map-
ping method is used (refer to Section 4).
4. Performance Evaluation
In this section we will evaluate the performance
achieved by the proposed methodology. The modu-
lo mapping strategy, referred to as DBBM, will be
evaluated and compared with the VOQ solution and
other mapping strategies. In particular, two solu-
tions of VOQ will be analyzed. The first one will be
applying an end to end VOQ to the entire network.
That is, using as many queues as destinations in the
network. This approach will be referred to as VOQ.
The second one will be applying the VOQ at switch
level. That is, every switch will have, on every in-
XVI Jornadas de Paralelismo, JP '2005 159
put port, as many queues as output ports. This will
be referred to as VOQ SW. Using different virtu-
al channels for improving network performance in
wormhole networks was introduced in [2]. Howev-
er, nowadays networks rely on virtual cut-through.
As we will see, these strategies no longer work in
virtual cut-through to reduce the HOL blocking ef-
fect. In order to simulate an equivalent strategy in
virtual cut-through networks, emptiest and random
strategies will be evaluated. In random queue map-
ping strategy, whenever a new packet arrives to a
switch it is mapped on a random queue. This map-
ping strategy will be referred to as RANDOM. In
emptiest queue mapping strategy, the packet will be
mapped at the next switch in the queue with minor
occupancy at the moment of injection. This map-
ping strategy will be referred to as EMPTIEST. Al-
though these two mapping strategies introduce out
of order delivery, they are used only for comparison
purposes.
In order to evaluate DBBM, the VOQ scheme and
the alternative mapping strategies we have devel-
oped a detailed event-driven simulator that allows
us to model the network at the register transfer lev-
el. In the next section, the main issues of the simu-
lator are described. Then, the topologies and traffic
patterns used in the evaluation are shown. Finally,
evaluation results are plotted and analyzed.
4.1. Simulation Model
The simulator models a bidirectional multistage
interconnection network with switches, endnodes,
and links. In all the cases evaluated, deterministic
routing has been used. Buffers are modeled for both
input and output ports of every switch. In this eval-
uation, we use the same buffer size for input and
output ports (up to 1 KB). The buffer size is statical-
ly divided by the number of queues defined by each
mapping strategy, resulting in a fixed maximum size
for every queue.
At every switch, packets are forwarded from any
input queue to any output queue through a mul-
tiplexed crossbar. We have considered a crossbar
bandwidth of 1.5 GB/s (we model crossbars with
speed up of 1.5). The access to the crossbar is con-
trolled by a scheduler that receives requests from
packets at the head of any input queue. A requesting
packet is forwarded only when the corresponding
crossbar input and crossbar output are free. At each
output port, an arbiter selects the output queue for
injecting packets to the output link. This selection
is made following a weighted round-robin scheme.
To model the links, we have assumed serial full-
duplex pipelined injection links. We have modeled
links with 1 GB/s bandwidth. We have modeled a
credit-based flow control at the link level. So, when-
ever a new packet is transmitted from an output port
to the corresponding input port of the next switch, a
credit is consumed. When a packet leaves an input
port, a new credit is granted to the previous output
port at the upstream switch or endnode. A similar
flow control scheme has been implemented for the
internal (input-output) packet forwarding. So, the
maximum number of credits per output (or input)
port depends on the total buffer size at the next in-
put (or output) port, and the total number of queues
at this port. Flow control packets have been mod-
eled and they share the link bandwidth with data
packets.
Endnodes are connected to switches using Input
Adapters (IAs). Every IA is modeled with a fixed
number of N message admittance queues follow-
ing a VOQ scheme, and a variable number of in-
jection queues, that follow a scheme similar to that
of the output ports of a switch. When a message is
generated, it is stored completely in the admittance
queue assigned to its destination, and is packetized
before being transferred to an injection queue. We
have used 64-byte packets. The transfer from admit-
tance queues to injection queues are controlled by
an arbiter that follows a round-robin scheme. The
injection of packets from injection queues to the
network is also controlled by an arbiter that selects
the next packet to be transmitted, using a weighted
round-robin scheme among all the queues.
4.2. Topologies and Traffic Patterns
To evaluate the proposed methodology, we have
used four BMIN configurations: 64 × 64 (3 stages),
512 × 512 (5 stages), 1024 × 1024 (5 stages), and
2048 × 2048 (6 stages), using 48, 640, 1280, and
3072 8-bidirectional port switches respectively. In
all the cases, the interconnection pattern used is the
perfect shuffle pattern.
In order to evaluate the proposed strategy, we will
use synthetic traffic patterns. With this traffic pat-
160 Redes y Comunicación
Traffic to random destinations Traffic to hotspot
Case Network % Sources Injection rate ( %) % Sources Injection rate # Dests
#1 64 × 64 100 % 100 % - - -
#2 64 × 64 70 % 60 % 30 % 60 % 1
#3 64 × 64 70 % 60 % 30 % 100 % 1
#4 64 × 64 70 % 90 % 30 % 60 % 1
#5 64 × 64 70 % 60 % 30 % 100 % 5
#6 512 × 512 70 % 60 % 30 % 60 % 1
#7 1024 × 1024 70 % 60 % 30 % 60 % 1
#8 2048 × 2048 70 % 60 % 30 % 60 % 1
Cuadro 1: Synthetic traffic patterns evaluated.
tern we will analyze the behavior of the different
mapping strategies. When using the VOQ mech-
anism we will obtain the maximum performance
as HOL blocking is completely eliminated. Also,
this will be taken as a reference for the other map-
ping strategies evaluated. This will let us to ana-
lyze the trade-off between the number of queues
used by DBBM and the performance achieved. In
this scenario several different traffic patterns will
be used. Table 1 shows them. The first case defines
an uniform traffic pattern where all the sources in-
ject at the full injection rate to random destinations.
The rest of the cases define at least one congestion
tree, as the traffic injected from different sources to
the same destination is higher than the link band-
width. For instance, for the second case, 70 % of the
sources (selected randomly) inject traffic at a rate
of 60 % of link bandwidth to random destinations
whereas the rest (30 % of sources) inject to the same
destination (selected randomly) at a rate of 60 % of
the link bandwidth.
In all the cases, except for the first one, HOL
blocking will be introduced as the random traffic
will share queues with the flows belonging to the
congestion tree.
4.3. Evaluation Results
In this section we will evaluate the performance
achieved by DBBM. For this, we will obtain the
maximum throughput that the system can achieve
for the different traffic cases, which will be achieved
when using the VOQ scheme. This will let us to see
if the proposed strategy achieves the maximum per-
formance.
Also, we will be able to evaluate the trade-off
between network performance and number of used
queues by DBBM. We will compare the behavior
of DBBM and VOQ with RANDOM, EMPTIEST,
1Q, and VOQ SW mapping strategies. When deal-
ing with RANDOM and EMPTIEST we will use 32
queues per input port. Finally, we will analyze scal-
ability issues of the mechanisms. For this, we will
evaluate DBBM in 64×64, 512×512, 1024×1024,
and 2048 × 2048 BMINs.
4.3.1. Basic Performance
Figure 1.(a) shows the performance achieved by
the different mapping strategies for the traffic case
#1. In this case all the traffic is uniformly sent to all
destinations. Due to all the destinations are demand-
ed at the same rate, no congestion tree is formed,
and HOL blocking is minimum. With this traffic
pattern, the maximum network throughput is ob-
tained. In this case, the network is able to deliver
53 bytes/ns (82 % of ideal throughput; 64 bytes/ns).
As Figure 1.(a) shows, the applied mapping strategy
has no effect in the results, except when using 1 or
2 queues. When using a single queue (1Q), network
throughput is significantly degraded (only achieves
28 bytes/ns). When using 2 queues with DBBM, al-
though throughput is around 50 bytes/ns, it does not
achieve the same performance as VOQ, thus there
is a significant HOL blocking. However, for DBBM
with 4 queues (and upwards) the throughput is the
maximum achievable. Notice also, that RANDOM,
and EMPTIEST mapping strategies also eliminate
XVI Jornadas de Paralelismo, JP '2005 161
0
10
20
30
40
50
60
70
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
16Q_DBBM
1Q
2Q_DBBM
32Q_DBBM
4Q_DBBM VOQ
8Q_DBBM VOQ_SW
32Q_Random
32Q_Emptiest
(a) traffic case #1
0
5
10
15
20
25
30
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
16Q_DBBM
1Q 2Q_DBBM
32Q_DBBM
4Q_DBBM
VOQ
8Q_DBBM
VOQ_SW
32Q_Random
32Q_Emptiest
(b) traffic case #3
0
5
10
15
20
25
30
35
40
45
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
16Q_DBBM
1Q
2Q_DBBM
32Q_DBBM
4Q_DBBM
VOQ
8Q_DBBM
32Q_Emptiest
VOQ_SW
32Q_Random
(c) traffic case #4
0
5
10
15
20
25
30
35
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
16Q_DBBM
1Q
2Q_DBBM
32Q_DBBM
4Q_DBBM VOQ
8Q_DBBM VOQ_SW
32Q_Random
32Q_Emptiest
(d) traffic case #5
Figura 1: Accepted traffi c vs. simulated time for traffi c cases (a) #1, (b) #3, (c) #4, and (d) #5.
(in this scenario) the HOL blocking introduced.
Figure 2.(a), 1.(b), and 1.(c) shows performance
results for the different mapping strategies for traf-
fic cases #2, #3, and #4. In these cases, there is a
hotspot made up of 30 % of sources sending traf-
fic to the same destination at different rates. First-
ly, it can be observed that VOQ behavior is not
affected by the congestion tree. It simply achieves
the maximum performance for the traffic injected
(around 28 bytes/ns for traffic cases #2 and #3, and
40 bytes/ns for traffic case #4). Secondly, in this
case, the 1Q, RANDOM and EMPTIEST mapping
strategies achieve the worst performance. Indeed, at
the beginning of the simulation (the congestion tree
is forming), none of them achieve the maximum
performance (achieved by VOQ). With 1Q, only 17
bytes/ns of throughput is achieved for all the cas-
es, whereas RANDOM and EMPTIEST achieve 23
bytes/ns for traffic cases #2 and #3, and 34 bytes/ns
for traffic case #4. Moreover, once the queues in
the network fill up (around 120K ns), behavior of
RANDOM and EMPTIEST drop reaching 1Q per-
formance. This is because in such situation massive
HOL blocking is introduced and no longer having
more than one queue helps at all.
On the other hand, VOQ SW at the beginning
of the simulation achieves similar performance as
RANDOM, and EMPTIEST. However, when the
queues in the network are full, VOQ SW drops.
At the end, VOQ SW only achieves 71 %, 71 %,
and 50 %, of VOQ throughput for cases #2, #3 and
#4, respectively. For DBBM strategy with only 2
queues, it reaches the same performance as VOQ
SW. Also, for traffic case #4, it obtains better per-
formance. The interesting issue is that DBBM is
able to achieve practically the same performance as
VOQ with a very low number of queues for all the
traffic cases. With 4 queues per input port, DBBM
is able to achieve 92 % of the VOQ performance
(with 8 queues, the performance achieved is 96 %).
Also, it can be noticed that with just two queues the
throughput is around to 19 bytes/ns (26 bytes/ns for
162 Redes y Comunicación
0
5
10
15
20
25
30
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
16Q_DBBM
1Q 2Q_DBBM
32Q_DBBM
4Q_DBBM
VOQ
8Q_DBBM
VOQ_SW
32Q_Random
32Q_Emptiest
(a) traffic case #2 (64 × 64)
0
50
100
150
200
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
1Q
2Q_DBBM
4Q_DBBM
8Q_DBBM
12Q_DBBM
VOQ_SW
12Q_Random
12Q_Emptiest
(b) traffic case #6 (512 × 512)
0
50
100
150
200
250
300
350
400
450
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
1Q
2Q_DBBM
4Q_DBBM
8Q_DBBM
12Q_DBBM
VOQ_SW
12Q_Random
12Q_Emptiest
(c) traffic case #7 (1024 × 1024)
0
100
200
300
400
500
600
700
800
0 100000 200000 300000 400000 500000
Network
throughput
(bytes
per
nanosecond)
Nanoseconds
1Q
2Q_DBBM
4Q_DBBM
8Q_DBBM
12Q_DBBM
VOQ_SW
12Q_Random
12Q_Emptiest
(d) traffic case #8 (2048 × 2048)
Figura 2: Accepted traffi c vs. simulated time for traffi c cases #2, #6, #7, and #8 .
traffic case #4) even when the network queues fill
up. The reason for the high performance degrada-
tion of VOQ SW, compared to DBBM with half of
the queue size, is because VOQ SW maps more non
congested flows in the same resources used to map
congested flows, introducing more HOL Blocking,
whereas DBBM keeps constant the number of flows
mapped on such resources.
Figure 1.(d) shows the performance achieved
when applying the traffic case #5. In this case there
are five hotspots each one made of up to 6 % of
sources sending traffic to the same destination at
100 % of the link rate. The only difference of this
case with traffic #3 is that the hotspot traffic is dis-
tributed in five destinations. As can be seen, the be-
havior differs significantly from the behavior pre-
sented for case #3 (Figure 1.(b)). In this case, 1Q,
RANDOM, EMPTIEST, and 2Q DBBM are not
able to keep VOQ performance. However, to the
contrary of case #3, VOQ SW obtains roughly the
maximum performance (obtained by VOQ). This
behavior is as a consequence of the lower degree of
HOL blocking introduced by congestion trees with
lower intensity. Nevertheless, DBBM with just four
queues and upwards is able to keep the maximum
achievable performance.
4.4. Scalability of DBBM
In order to analyze the scalability of DBBM,
we have injected the same traffic case to different
BMIN sizes (64×64, 512×512, 1024×1024, and
2048×2048). For BMINs with sizes 512×512 and
upwards the VOQ mechanism has not been evalu-
ated due to memory problems in the simulator (in
fact, this problem clearly shows that VOQ is not
scalable in the number of queues). Figures 2.(a),
2.(b), 2.(c), and 2.(d) show the results for 64 × 64,
512×512, 1024×1024, and 2048×2048 BMINs,
respectively. As can be observed, 1Q, RANDOM,
and EMPTIEST do not work at all. As the conges-
tion tree remains in the network their throughput
XVI Jornadas de Paralelismo, JP '2005 163
degrades significantly. Concretely, the achieved net-
work throughput is just a 0.02 % (9 bytes/ns out of
400 bytes/ns) for 1024 × 1024 BMIN, and 0.01 %
(9 bytes/ns out of 800 bytes/ns) for 2048 × 2048
BMIN. These extreme low percentages indicate that
the network has been flooded by packets belonging
to the congestion tree.
Focusing in VOQ SW we can observe that,
as network size increases, the network throughput
achieved decreases. For the 64 × 64 BMIN VOQ
SW achieved 74 % (20 bytes/ns) of the maximum
achievable throughput (27 bytes/ns). With the 512×
512 BMIN, its throughput decreases significantly to
the 40 % (80 bytes/ns out of 200 bytes/ns). Equal
effect occurs for 1024 × 1024, and 2048 × 2048
BMINs. In particular, the achieved throughput is
only 30 % (120 bytes/ns out of 400 bytes/ns) and
26 % (210 bytes/ns out of 800 bytes/ns).
On the other hand, DBBM keeps the performance
irrespective of the BMIN size. For the 64 × 64
BMIN DBBM is able to reach almost the maxi-
mum performance with only 4 queues (96 %, 26
bytes/ns out of 27 bytes/ns). With the 512 × 512
BMIN, its throughput is 92 % (185 bytes/ns out of
200 bytes/ns). This decrease is even less signifi-
cant for 1024 × 1024, and 2048 × 2048 BMINs.
For these BMINs, the achieved network throughput
keeps in 91.5 % (366 bytes/ns out of 400 bytes/ns)
and 90 % (723 bytes/ns out of 800 bytes/ns). More-
over, with only 8 queues (and upwards), DBBM
achieves a throughput of 97 % for 1024×1024, and
2048 × 2048 (390 bytes/ns out of 400 bytes/ns, and
777 bytes/ns out of 800 bytes/ns, respectively), and
99 % for 64 × 64, and 512 × 512 BMINs. To sum
up, DBBM is able to keep roughly the maximum
performance when the BMIN size increases, using
a small number of queues.
5. Conclusions
Head-of-line blocking is one of the main prob-
lems arising in input-buffered switch fabrics. Al-
though VOQs is able to eliminate HOL blocking,
this solution is not scalable and represents a very
high cost when implemented in very large BMINs.
Moreover, temporal and spatial locality in pack-
et destination distribution can be used in order
to reduce HOL blocking by using a small num-
ber of queues and dynamically mapping packets to
them, according to their destination. In this paper,
we have proposed the queue-sharing Destination-
Based Buffer Management (DBBM) strategy ap-
plied to every switch included in a BMIN.
Simulation results have shown that it is pos-
sible to achieve roughly the same throughput as
when using VOQs while using only a small frac-
tion of the queues. Concretely, DBBM strategy with
8 queues (and upwards) has shown better behavior
than the other mapping strategies used (1Q, RAN-
DOM, EMPTIEST, and VOQ SW). Furthermore,
the scalability analysis results show that DBBM
strategy with only 8 queues is able to achieve rough-
ly the same throughput as with VOQ in all the
BMINs analyzed (64×64, 512×512, 1024×1024,
and 2048×2048), while the throughput drops dras-
tically with the other mapping strategies.
Referencias
[1] Avici’s Homepage, http://www.avici.com.
[2] W. J. Dally, Virtual-channel Flow Control, in
Proceedings of the 17th Int. Symp. on Comput-
er Architecture, ACM SIGARCH vol. 18, no. 2,
pp. 60-68, May 1990.
[3] J. Duato, J. Flich, and T. Nachiondo, Cost-
Effective Technique to Reduce HOL Blocking
in Single-Stage and Multistage Switch Fabrics,
Euromicro Conference on Parallel, Distributed
and Network-based Processing, Feb. 2004.
[4] M. Karol and M. Hluchyj, Queuing in high-
performance packet-switching, IEEE J. Select.
Areas. Commun. vol. 6, Dec. 1998.
[5] N. McKeown, M. Izzard, A. Mekkittikul, W.
Ellersick, and M. Horowitz, The Tiny Tera: A
packet switch core, IEEE Micro, vol. 17, pp. 27-
33, Jan./Feb. 1997.
[6] C. Ruemmler and J. Wilkes, “Unix Disk Access
Patterns”, in Proc. Winter Usenix Conference,
Jan. 1993.
[7] Y. Tamir and G.L. Frazier, Dynamically-
Allocated Multi-Queue Buffers for VLSI Com-
munication Switches, IEEE Transactions on
Computers, vol. 14, no. 6, June 1992.
164 Redes y Comunicación
An Effective Routing Strategy for Direct Interconnection Networks *
María E. Gómez Pedro López José Duato
Dept. de Informática de Sistemas y Computadores
Universidad Politécnica de Valencia
megomez@disca.upv.es
Resumen
Recent massively parallel computers are based
on clusters of PCs. These machines use one of
the recently proposed standard interconnects, which
use source or distributed routing based on forward-
ing tables. While source routers are simpler, dis-
tributed ones provide more flexibility allowing the
network to achieve a higher performance. The main
problem of forwarding tables is the lack of scalabil-
ity. In this paper, we propose a distributed routing
strategy for commercial switches, Flexible Interval
Routing, that is scalable, both in memory and rout-
ing time, for the most commonly-used routing algo-
rithms in regular topologies.
1. Motivation
In large parallel computers, high-performance in-
terconnection networks are crucial to achieve the
maximum performance. Routing is one of the most
important design issues of interconnection net-
works. Routing is deterministic if only one path is
provided for every source–destination pair, or adap-
tive, if several paths are available. Adaptive routing
better balances network traffic. Routing algorithms
are implemented by means of the routing and selec-
tion functions. The routing function supplies a set
of routing options (channels or paths). A selection
from this set is made by the selection function.
Routing strategies can be also classified accord-
ing to the place where routing decisions are tak-
en. In source routing, the source node computes the
path prior to packet injection and stores it in the
packet header. Since the header itself must be trans-
mitted through the network, it consumes network
bandwidth. In distributed routing, each switch com-
putes the next link that will be used by the pack-
et. The packet header only contains the destination.
*
This work was supported by the Spanish MCYT under Grant
TIC2003-08154-C06-01.
Source routing has been used in some networks be-
cause routers are very simple. On the other hand,
distributed routing has been used in most hardware
routers for efficiency reasons.
Distributing routing can be implemented in two
ways. In the first case, there is a hardware at the
switches that implements a combinational logic cir-
cuit and computes the output port to be used as a
function of the current and destination nodes and
the status of the output ports. The implementation is
very efficient in terms of both area and speed, but it
is specific to the topology and to the routing strate-
gy. With the introduction of clusters of PCs, routers
based on forwarding tables were proposed. In this
case, there is a table at each node that stores, for
each destination node, the output port that must be
used. This scheme can be easily extended to support
adaptive routing by storing several outputs in each
table entry [9]. The main advantage of table-based
routing is that any topology and any routing algo-
rithm can be used. However, forwarding tables are
not scalable. The size of the forwarding table grows
linearly with network size, and, most important, the
time required to access the table also depends on it.
Recently, large cluster-based machines with
thousands of nodes have been built [2]. These ma-
chines use any of the commercial high-performance
switch-based point-to-point interconnects. The cho-
sen topology for these large networks is no longer
irregular. Either regular direct networks (tori and
meshes) or indirect multistage networks are the usu-
al choice. The large network size of these machines
makes source routing inefficient due to the header
size, and distributed routing based on forwarding
tables is also inefficient due to the forwarding table
size. On the other hand, specifically designed hard-
wired routing algorithms are not feasible, as general
purpose switches are used.
Our challenge is to develop a routing strategy for
switch-based networks which is optimized for the
most widely used network topologies. In this paper,
we will focus on direct networks. By optimized, we
understand that it is scalable, from several points of
view: (i) the required memory space does not lin-
early depend on network size, (ii) the hardware re-
quired to apply the routing algorithm is not complex
and does not depend on network size and (iii) the
time required to perform a routing operation does
not depend on network size.
The rest of the paper is organized as follows. Sec-
tion 2 describes our proposal. Section 3 shows the
configuration of these registers for the most wide-
ly used regular network topologies. Section 4 gives
some comments about the memory required by the
mechanism. Finally, some conclusions are drawn.
2. Flexible Interval Routing
Interval routing was introduced in [10], and ex-
tended in [8]. The idea behind an interval routing
scheme is to group destination nodes belonging to
the same output port into some interval. At each net-
work switch, each output port has one associated
interval. The intervals are usually non-overlapping.
Each packet is forwarded through the output port
whose interval contains the destination identifier of
the packet. To implement interval routing, it is suf-
ficient to store the bounds of each interval, thus,
its required memory space is 2dlog(N) bits per
switch, d being the number of switch ports or switch
degree and N the network size. Moreover, this
scheme requires a simple hardware, at most a pair of
comparators for each output link, then it is also very
fast, since the output port can be determined after
a single comparison delay if all comparators work
concurrently. In [1], the authors show that determin-
istic routing can be implemented in hypercube and
n-dimensional meshes (with Y X routing) by using
interval routing. However, this proposal can neither
be applied to tori nor adaptive routing.
We are interested in the proposal of a compact,
simple and flexible routing scheme that can be used
for the most widely used regular topologies, that can
easily deal with changes in the routing algorithm on
a given topology. According to [5], while numer-
ous topologies have been proposed over the years,
almost all the networks that have actually been con-
structed use topologies derived from two main fam-
ilies: tori or butterflies. In this paper, we do not fo-
cus on multistage networks because interval routing
is actually able to route packets in most topologies
of this kind, so we focus on direct networks. Our
proposal, called Flexible Interval Routing (FIR), is
an extension of interval routing. As in interval rout-
ing, each output port has also an associated inter-
val, which is implemented with two registers, First
Interval (FI) and Last Interval (LI). But, in order to
add flexibility, we propose to associate additional
registers to the output ports.
Regular topologies usually identifies each node
by its coordinates in each network dimension.
Therefore, it is very interesting to be able to select
the bits of the packet destination address that must
be inside the interval associated to the output port.
In particular, each output port has a Mask Regis-
ter (MR). This register has n bits (n = log(N))
and indicates which bits of the packet destination
address are compared with the output port bounds.
The MR register gives flexibility since the interval
can refer to a subset of the destination address bits.
As a consequence, our proposal can be applied to
more topologies and routing algorithms. This oper-
ation is performed in parallel in all the output ports.
The result of the comparison for all the output ports
can be stored in the Allowed Register, unique for
the switch, with a size of d bits (d being the switch
degree). Notice that cyclic (or modulo N) intervals
can be also allowe.
Notice that our proposal permits that the associ-
ated intervals to the different output ports of a given
switch overlap and, therefore, more than one output
port can be allowed. That is, the Allowed Register
may contain more than one 1. This can be used to
provide adaptive routing.
However, in order to guarantee deadlock free-
dom, some routing restrictions must usually be ap-
plied. Usually, in regular topologies, deadlock free-
dom is ensured by traversing network dimensions
following some order. These routing restrictions are
taken into account in our proposal by means of an
additional register associated to each output port,
the Routing Restrictions Register (RRR). It defines,
for each output port, which other output ports of the
switch should be selected prior to this one. This reg-
ister has one bit per each output port. For a given
output port i, the j bit in the RRR indicates if the
output port j has more preference (bit set to 1) or
not (0) than output port i. Thus, the final routing de-
cision for a given output port i is obtained taking in-
to account the Allowed bits of the other output ports
166 Redes y Comunicación
and the bits in its RRR. If there is, at least, other
output port with more preference (bit set to 1 in the
RRR) that also has its Allowed bit set to 1, then the
output port will not be returned to route the pack-
et. This is done in all the output ports of the switch,
and all the results can be stored in a Routing Regis-
ter (RR), with a number of bits equal to the number
of output ports. The Routing Register is unique per
switch and it contains the result of the routing func-
tion. Notice that in case of adaptive routing, it may
contain more than one 1.
To summarize, our proposal needs the following
configuration registers associated to output ports:
• First Interval (FI): contains the lower bound of
the interval, with a size n = log(N) bits.
• Last Interval (LI): contains the upper bound of
the interval, with a size n = log(N) bits.
• Mask Register (MR): selects the bits of the
destination address that will be compared with
FI and LI, with a size n = log(N) bits.
• Routing Restrictions Register (RRR): one bit
per output port, describes the restrictions of the
routing algorithm.
Moreover, in the implementation of the mecha-
nism, we assume the use of two registers per switch:
• Allowed Register (AR): one bit per output
port (d bits). It represents the output ports that
could be used before considering the RRR.
• Routing Register (RR): one bit per output port
(d bits). It represents the output port(s) re-
turned by routing function.
Up to this point, we have assumed no virtual
channel multiplexing [4]. If so, the proposed reg-
isters will be associated to virtual channels instead
of output ports. Hence, each virtual channel will be
provided with a LI, FI, MR and RRR register. More-
over, the RRR will have one bit per virtual channel,
and will define which virtual channels have more
preference. This is also the case for the registers as-
sociated to the whole switch (AR and RR), that will
represent virtual channels instead of physical ones.
Therefore, our proposal requires, at each switch,
d × v FI, LI, MR and RRR registers, and one RR
and AR registers of size d × v, d being the number
of output ports in the switch, and v the number of
virtual channels per output port.
Notice that the FIR scheme will obtain the same
level of performance than routing with forwarding
tables, if the applied routing algorithm is the same.
Indeed, the latency obtained by packets could be
smaller for our strategy because the time required
to perform a routing operation at each switch in FIR
may be smaller than for routing using forwarding
tables. Routing delay of the FIR scheme is given
by the time required to check if the destination ad-
dress is inside the interval (all the ports make these
comparisons concurrently) thus generating the Al-
lowed bits plus the time to merge this information
with the routing restrictions register (RRR). On the
other hand, accessing the forwarding table may take
longer, even more, in large systems, since the time
required to access it depends on its size.
By appropriately setting the configuration regis-
ters, the routing algorithm is defined. Following, we
will show how to configure them for the most pop-
ular routing algorithms used in direct networks.
3. FIR Registers Configuration
Next, we present some illustrative examples
showing the configuration of the proposed registers
for direct networks for both deterministic and adap-
tive routing.
3.1. Deterministic Routing
3.1.1. Meshes.
Although the proposed set of registers allows
routing on any mesh, we will assume as an exam-
ple a 16-node 2-D mesh (4 × 4 mesh). We will first
assume that there is only one processing node per
switch and that packets are “magically” delivered to
this node once it reaches the destination switch. So,
the destination addresses require 4 bits, and the LI,
FI and MR will also contain 4 bits (assuming that
output ports are not split into virtual channels). The
RRR requires one bit per each output port. For a 2-
D mesh, 4 bits are needed, since each switch has, at
most, 4 ports.
Figure 1.(a) shows the configuration of the regis-
ters associated to the output ports in a 4×4 mesh for
XY routing. The network links X+,Y+,X- and Y-
have been mapped to switch ports 0,1, 2, and 3, re-
spectively. Figure 1 also shows the prototyped con-
figuration for a central switch ji in a 4 × 4 mesh
with XY routing, i being the two least significant
XVI Jornadas de Paralelismo, JP '2005 167
1100,0101
0100..1100
0011,0000
0001..0011
0011,0000
0001..0011
0001..0011
0011,0000
0 1 2 3
7
6
5
4
9
8 10 11
15
14
13
12
0011,0X00
2
X− X+
Y+
Y−
0
4 bits
RRR, AR, RR
FI..LI
MR,RRR
Y+
X+
3 1
0011,0000
0011,000X
0000..0000
0010..0011
0011,0X00
0000..0000
1100,01X1
0100..1100
1100,0101
0000..0000
1100..01X1
1100,0100
0100..1100
0000..0000
1100,01X0
0001..0011 0010..0011
0011,0X00
0011,0X00
0011..0011
0011..0011
0011..0011
0011,0X00
0000..0000
0011,000X
0000..0000
1100,00X1
0000..0001
0011,000X
0000..0010
0011,0000
0011,000X
0000..0001 0000..0010
0000..0001
0011,000X
0000..0010
0011,0000
1000..1100
1100,X001
0000..0100
1000..1100
1100,00X1
1100,X101
0000..0100
1100,01X1
1000..1100
1100,X101
0000..0100
1100,01X1
1000..1100
1100,X100
0000..0100
1100,01X0
0010..0011
0011,0X00
0011..0011
0011,0X00
1100,X101
1100..1100
0000..0000
0011,000X
0000..0001
0011,000X
0000..0010
0011,0000
1100..1100
1100,X001
0100..1000
1100,0001
0000..1000
1100,0101
1100..1100
1100,X101
0000..1000
1100,0101
1100..1100
1100,X100
0100..1000
1100,0100
0010..0011
0011,0X00
0000..0000
0011,000X 0011,0000
0100..1100
1100,0001
X+
Y+
00(i+1)..0011
(j+1)00..1100
MR,RRR
FI..LI
0000..(j−1)00
1100,01X1
0011,0X00
0000..00(i−1)
0011,000X
1100,X101
ji
Figura 1: Configuration of the proposed registers in a 4×4 mesh with XY routing. Prototyped configuration of the proposed
registers in a mesh with XY routing.
bits of the switch address and j the two most signif-
icant bits. As can be observed, the MR selects the
two most significant bits of the destination address
for the Y links, and the two least significant bits for
the X links. LI and FI mark the bounds of the in-
terval associated to each port. Finally, the RRRs en-
force the XY routing that guarantees deadlock free-
dom. For the XY routing, in the Y links, the bits
in the RRRs corresponding to the X links are set
to 1, since packets must be first routed in the X di-
mension. In the X links, the bits in the RRRs cor-
responding to the Y ports are set to 0. In the RRRs
there are some bits that can be set to either 0 or 1
(do not care). Consider, for instance, the case of the
RRR associated to the X+ port. The bit that corre-
sponds to X− can be set to either 0 or 1 because
the routing algorithm never will return both X+
and X−. In fact, the intervals associated to X− and
X+ are not overlapping.
Next, we will consider that nodes are attached to
the switches by switch ports. That is, these ports de-
liver the packets to their final destination. Figure 2
presents the register configuration, but considering
that each switch has a processing node connected to
it (shown in dotted line). One bit has been added to
the RRRs. The internal channel does not mask any
bit in the destination address and only accepts pack-
ets that are addressed to that particular processing
node. Its RRR has not bits set to 1, as neither output
X+
+
00(i+1)..0011
RRR, AR, RR
(j+1)00..1100
MR,RRR
FI..LI
0000..(j−1)00
1100,X01X1
0011,X0X00
0000..00(i−1)
0011,X000X
1100,XX101
5 bits
X+
1
2
3 0
X−Y+
Y−
I1
4
ji..ji
1111,XXXXX
ji
Figura 2: Prototyped configuration of the proposed regis-
ters in a mesh with XY routing. One node is attached to
each switch.
port has more preference. In fact, there are not out-
put ports that include this address in its associated
interval. If several processing nodes are attached to
each switch, then the address of the processing node
does not coincide with the switch address. Anyway,
it is still possible to deliver packets to the process-
ing nodes. For example, we can assume that each
switch has two processing nodes connected to it,
and they have consecutive addresses. Then, the net-
work ports will not consider the least significant
bit, masking it in the MRs, and only the destina-
tion switch will consider this bit in order to deliver
the packet to the proper processing node.
On the other hand, other routing algorithms can
be implemented. For Y X routing, the same register
168 Redes y Comunicación
X+
1
2
3 0
X−Y+
Y−
4 bits
RRR, AR, RR
Y+
X+
FI..LI
MR,RRR
((j+1) mod K)00..((j+K/2)mod K)00
1100,RRR
00((i+(K+1)/2) mod K)..00((i+K−1)mod K)
0011,RRR
00((i+1) mod K)..00((i+K/2)mod K)
0011,RRR
((j+(K+1)/2) mod K)00..((j+K−1)mod K)00
1100,RRR
ji
Figura 3: Prototyped Register configuration for a 4 × 4
Torus network. Routing function depends on the configu-
ration of the Routing Restrictions Registers.
configuration as for XY is valid for the LI, FI and
MR, but the RRR must be reconfigured. In this case,
in the X links, the bits of the RRR corresponding to
the Y links are set to 1, since packets are first rout-
ed in the Y dimension. In addition to dimension or-
der routing, the proposed registers also allow rout-
ing following direction order routing algorithms or
the turn-model algorithms. Again, for these routing
algorithms the FI, LI and MR register configuration
shown in Figure 1 is valid, and the RRR registers
establish the ordering to follow in the directions.
3.1.2. Tori.
Next, we show how our proposal can be applied
to torus networks using deterministic routing. The
first difference with mesh networks is that some of
the intervals are cyclic (LI < FI), since in tori
there are wraparound links. The use of wraparound
links introduces cycles in the channel dependency
graph, so some action must be performed in order to
prevent deadlocks. We will address this issue later.
Again, we will show how to configure the flexible
interval routing registers by using a small network
(4 × 4 torus). In Figure 3, the prototyped configura-
tions of the LIs, FIs and MRs are shown for a switch
in a 4 × 4 torus, considering the switch address di-
vided in two sets of bits corresponding to the X (i)
and Y (j) coordinates. The RRR will be configured
depending on the routing function to be used. K is
the network radix or number of nodes in a dimen-
sion. In this case, K = 4. A dimension order rout-
ing or a direction order routing can be applied by
configuring properly the RRRs.
On the other hand, as we mentioned before, in
torus networks some action must be performed in
order to prevent deadlocks. Two are the main ap-
X+
+
X+L
X+H
+L
Y
+H
Y
X−L
X−H
Y−L
Y−H
8 bits
RRR, AR, RR
0
1
3
5
6
7 4 2
MR,RRR
FI..LI
VC1
VC6
VC0
VC2
VC3
VC7
H
L
H
L
H L
H L
VC5
VC4
ji
Figura 4: Virtual channel numbering for a 4×4 Torus net-
work that avoids deadlocks by using two virtual channels.
proaches to deal with deadlocks in this context. The
first one is splitting each physical channel into two
virtual channels [6]. Other approach that is the bub-
ble flow control mechanism [3].
The first option to avoid deadlocks in rings is us-
ing two virtual channels per physical link, one of
them (H) is used to send packets to destination ad-
dresses greater than the current node and the oth-
er (L) to send packets to destination addresses low-
er than the current one. In this way, cyclic depen-
dencies are avoided, and, therefore, deadlocks. To
use this approach with our flexible interval rout-
ing scheme, each virtual channel will be provided
with a set of LI, FI, MR and RRR registers. More-
over, the RRR will have one bit per virtual chan-
nel of the whole switch. The registers associated to
the whole switch (Allowed and Routing Registers)
will also have one bit per virtual channel. Figure 4
shows a possible numbering of the virtual channels
and the format for the RRRs, ARs and RRs for a
4 × 4 torus with two virtual channels per physical
link (H and L). There are, therefore, 8 virtual chan-
nels per switch. Notice that any topology link can
be mapped to any switch port, but the virtual chan-
nels associated to the same physical link should be
mapped to adjacent positions in the registers.
Considering this mapping, the prototyped config-
uration for the proposed registers is shown in Fig-
ure 5 for a 4 × 4 torus with 2 virtual channels per
physical link and XY routing. It must be noticed
that by following the routing restrictions applica-
ble to the H and L virtual channels, some of them
would never be used. For instance, from a source
node with 0 coordinate in a dimension, the + direc-
tion would only be used to send packets to destina-
tions between 1 and K/2 in the same coordinate,
K being the number of nodes per dimension. As
these destinations are greater than the current one
XVI Jornadas de Paralelismo, JP '2005 169
X+L
X+H
+L
Y
+H
Y
X−L
X−H
Y−L
Y−H
8 bits
RRR, AR, RR
0
1
3
5
6
7 4 2
MR,RRR
FI..LI
H L
H
L
L
H
L
H
else
1100,00110011
0000..((j+K/2) mod K)00
if ((j+K/2)>K−1) then
1100,00110011
if (j<K−1) then
(j+1)00..min(j+K/2,K−1)00
1100,00110011
else
0000..((j+K/2) mod K)00
1100,00110011
(j+1)00..min(j+K/2,K−1)00
00(i+1)..00min(i+K/2,K−1)
0011,00000000
else
0000..00((i+K/2) mod K)
0011,00000000
if (i+K/2>K−1) then
0011,00000000
else
0011,00000000
if (i<K−1) then
0000..00((i+K/2) mod K)
+
X+
else
0011,00000000
0011,00000000
if (i>0) then
0011,00000000
else
0011,00000000
00((i+(K+1)/2) mod K)..00(K−1)
if (i<K/2) then
00((i+(K+1)/2) mod K)..00(K−1)
00max(00,i−(K/2))..00(i−1)
00max(00,i−(K/2))..00(i−1)
00(i+1)..00min(i+K/2,K−1)
1100,00110011
else
1100,00110011
if (j>0) then
max(00,j−(K/2))00..(j−1)00
if (j<K/2) then
((j+(K+1)/2) mod K)00..(K−1)00
1100,00110011
else
max(00,j−(K/2))00..(j−1)00
1100,00110011
((j+(K+1)/2) mod K)00..(K−1)00
ji
Figura 5: Prototyped register configuration for a 4 × 4 Torus network with XY routing and H and L virtual channels for
avoiding deadlocks.
(0), the L channel in the + direction would never be
used. This can be improved by allowing those virtu-
al channels that would never be used, to be used like
the other one associated to the same physical chan-
nel. This does not introduce cycles in the channel
dependency graph. In Figure 5, the virtual channels
that would never be used are configured as the other
virtual channel of the same output port. Notice that
no preference order is established between the two
virtual channels associated to each output port since
either the associated intervals do not overlap or both
have the same associated interval.
The second mechanism to avoid deadlocks in tori
is the bubble flow control mechanism. With this
mechanism, packets that are injected into the net-
work or cross a network dimension require two free
buffers to guarantee deadlock freedom. In order to
support the bubble flow control mechanism in our
proposal, we require one additional register associ-
ated to each output port: the Bubble Register (BR).
It has one bit per input port (including the injection
ports). The input ports that only need one free buffer
to be allowed to send through the current output port
will have its associated register bit set to 1. If two
buffers are required in the output port because the
packet is injected into the network or crosses a net-
work dimension, then this bit must be set to 0. On
the other hand, it is necessary to track the number of
free buffers that each output port has. This informa-
tion is usually available as part of the flow control
mechanism used in the switch, so it is not an extra
cost of the proposed strategy. Then, a packet that en-
ters the switch through a given input port and would
like to use a particular output port, to meet the bub-
ble flow control mechanism, either the bit associat-
ed to the input port is 1 in the BR associated to the
output port (one buffer is enough), or this bit is zero
but there are at least two free buffers in the output
port. Notice that if only one free buffer is required,
but there is not free space in the output port, the
port is still returned by the routing function. Obvi-
ously, the selection function will not select this port
because it has not free space. The Routing bit as-
sociated to output port i will be obtained consider-
ing the Allowed Register, the Routing Restrictions
Register, the bit associated to the corresponding in-
put port in the Bubble Register and the bubble space
available at the output port.
If the bubble flow control mechanism were used
in Figure 3 (4×4 Torus with XY deterministic rout-
ing), then the configuration of the BR is shown in
Figure 6. We assume that each switch has two injec-
tion channels per switch (I1 and I2) that correspond
with ports 4 and 5 in the switch.
3.2. Adaptive routing
When using adaptive routing, several output
ports can be returned by the routing function. So,
in this case, the proposed Routing Register could
contain more than one bit set to 1.
170 Redes y Comunicación
Y+
X+
X+
1
2
3 0
X−Y+
Y−
I1
4
6 bits
Bubble Register
I2
5
000010
000100
001000
000001
111111
111111
BR
ji
Figura 6: Configuration of BR registers in a Torus network
assuming two injection channels per switch.
3.2.1. Meshes.
We will consider fully adaptive routing based on
Duato’s protocol [6]. Each physical link is split in-
to several virtual channels. Some of them can be
used to route packets without any restriction, pro-
vided that there is a set of virtual channels (escape
channels) free of cyclic dependencies that provides
a deadlock free routing subfunction. Escape chan-
nels can be provided by means of any deadlock free
routing algorithm. In meshes, one escape channel is
required, which is used according to the XY rout-
ing algorithm. Therefore, two virtual channels are
at least required. One of them is the escape channel
(D) and the rest are the adaptive (A) ones.
A possible configuration of the Flexible Interval
Routing registers is shown in Figure 7 for a 4 × 4
mesh assuming two virtual channels per physical
link and that the deterministic routing subfunction
is XY . In the deterministic channels, the RRRs es-
tablish the ordering among the deterministic virtu-
al channels associated to the different output ports,
according to the routing subfunction. As expected,
the RRRs associated to the adaptive channels do not
give any preference to other channels.
3.2.2. Tori.
Again, we will focus on adaptive routing algo-
rithms based on Duato’s protocol. In this case, the
deadlock free routing subfunction can be based ei-
ther on the deterministic routing algorithm that uses
two virtual channels per physical link or on the bub-
ble flow control. In both cases, at least a new virtual
channel (A) that allows routing without restrictions
is added, thus requiring at least two virtual channels
with the bubble flow control and three virtual chan-
nels in the other case. In Figure 8, the prototyped
configuration for a 4 × 4 Torus assuming XY de-
terministic routing based on the bubble flow control.
As the deterministic virtual channels must meet the
bubble condition, they must set in the BR those bits
that correspond to the ports that may inject a new
packet in the ring formed by the deterministic vir-
tual channels. These ports are not only the ones that
perform a dimension transition, but also the ones
mapped to adaptive virtual channels of the same di-
mension as the deterministic virtual channel.
If the bubble mechanism is not used, then at least
three virtual channels are used. In this case, the con-
figuration is very similar to the one presented in Fig-
ure 5, taking into account that an additional virtual
channel is used, the adaptive one, whose FI, LI, and
MR configuration is the same shown in Figure 8 for
the adaptive virtual channel. In addition, the Bubble
register must be set to all ones in order to ignore the
number of free buffers at output channels.
4. Memory required by the FIR registers
In this section we will provide a brief compari-
son between the amount of memory required at each
switch by the FIR registers and an implementation
of a routing algorithm based on forwarding tables.
Assume that we have a network composed by N
nodes, built with switches with d ports. The links
attached to each port may be split into up to v virtu-
al channels. Finally, the routing algorithm we want
to use offers a maximum of r routing options. Ob-
viously, with r = 1, this is a deterministic routing
algorithm.
The FIR approach needs to associate five config-
uration registers to each output port, three of them
(FI, LI and MR) of size log(N) bits and two (RRR
and BR) of size d·v bits. No matter if the routing is
deterministic or adaptive, or the number of routing
options provided in the latter case. Therefore, the
total number of bits required to implement the FIR
strategy is given by CFIR = d · v · (3 · log(N) + 2 ·
d· v) bits. As we can see, its cost is O(log(N)). On
the other hand, routing based on forwarding tables
requires a table with as many entries as the number
of nodes, and each entry must contain the r port(s)
returned by the routing function. Hence, the cost of
this alternative is CFT = N · log(d · v) · r bits in
each switch. Clearly, this cost is O(N), which is not
scalable with the network size.
XVI Jornadas de Paralelismo, JP '2005 171
MR,RRR
FI..LI
X+D
X+A
+D
Y
+A
Y
X−D
X−A
Y−D
Y−A
A D
A
D
D
A
D
A
1100,00000000
0000..(j−1)00 0000..(j−1)00
1100,00010001
X+
0000..00(i−1)
0011,00000000
0000..00(i−1)
0011,00000000
Y+
(j+1)00..1100
00(i+1)..0011
0011,00000000
0011,00000000
00(i+1)..0011
1100,00010001
1100,00000000
(j+1)00..1100
8 bits
RRR, AR, RR
0
1
3
5
6
7 2
4
ji
Figura 7: Register configuration for a 4 × 4 mesh with adaptive routing and an escape channel to avoid deadlocks and an
adaptive virtual channel.
X+D
X+A
+D
Y
+A
Y
X−D
X−A
Y−D
Y−A
A D
A
D
D
A
D
A
((j+(K+1)/2) mod K)00..((j+K−1) mod K)00
1100,00010001,00000100
X+
00((i+1) mod K)..00((i+K/2) mod K)
0011,00000000,11111111
0011,00000000,00010000
1100,00010001,01000000
00((i+1) mod K)..00((i+K/2) mod K)00
+
8 bits
0
1
3
5
6
7 2
4
RRR, AR, RR, BR
MR,RRR,BR
FI..LI
((j+1) mod K)00..((j+K/2) mod K)00
0011,00000000,11111111
00((i+(K+1)/2) mod K)..00((i+K−1) mod K)
0011,00000000,00000001
00((i+(K+1)/2) mod K)..00((i+K−1) mod K)
((j+(K+1)/2) mod K)00..((j+K−1) mod K)00
1100,00000000,11111111
((j+1) mod K)00..((j+K/2) mod K)00
1100,00000000,11111111
ji
Figura 8: Register configuration for a 4 × 4 Torus with adaptive routing and the bubble flow control mechanism.
5. Conclusions
We have proposed a distributed routing strate-
gy for commercial switches, Flexible Interval Rout-
ing, that is scalable for the most widely used net-
work topologies, that does not use tables for rout-
ing packets and that does not make any assumption
about which switch port will be used to implement
a topology link. The strategy is able to implement
the most commonly-used deterministic and adap-
tive routing algorithms in the most widely-used di-
rect regular topologies (meshes and tori). To imple-
ment the proposed strategy, only 5 registers must be
associated to each output port of switches, with a
total requirements of buffer space O(log(N)).
Referencias
[1] E. Bakker, J. van Leeuwer and R.B. Tan. Linear In-
terval Routing Algorithms review, 2. pp. 45-61, 1991.
[2] IBM BG/L Team. An Overview of BlueGene/L
Supercomputer. ACM Supercomputing Conference,
2002.
[3] C. Carrion, R. Beivide, J.A. Gregorio, and F. Valle-
jo. A Flow Control Mechanism to Avoid Message
Deadlock in K-ary N-Cube Networks. 4th Interna-
tional Conference on High Performance Computing,
pp. 332-329, December 1997.
[4] W. J. Dally, Virtual-channel flow control, IEEE Trans-
actions on Parallel and Distributed Systems, vol. 3,
no. 2, pp. 194-205, March 1992.
[5] W.J. Dally and B. Towles. Principles and Practices of
Interconnection Networks. Morgan Kaufmann, 2004.
[6] J. Duato, S. Yalamanchili and L. Ni. Interconnection
Networks. An Engineering Approach. Morgan Kauf-
mann, 2004.
[7] J. Duato. A Necessary and Sufficient Condition for
Deadlock-Free Outgoing in Cut-Through and Store-
and-Forward Networks, in Proc. of IEEE Trans. on
Parallel and Distributed Systems, vol. 7, no. 8, pp.
841-854, August 1996.
[8] J. van Leeuwen and R. B. Tan. Interval Routing. The
Computer Journal, 30(4), pp.298-307, 1987.
[9] J.C. Martinez, J. Flich, A. Robles, P. Lopez, and J. Du-
ato. Supporting Adaptive Routing in IBA Switches.
Journal of Systems Architecture, 49:441–449, 2004.
[10] N. Santoro and R. Khatib. Routing without routing
tables. Technical report SCS-TR-6, School of Com-
puter Science, Carleton University, 1982.
172 Redes y Comunicación
Reachability-Based Fault-Tolerant Routing Methodology∗
J. M. Montañana, J. Flich, A. Robles, and J. Duato
Dept. of Computer Engineering (DISCA)
Universidad Politécnica de Valencia
Camino de Vera, 14, 46021–Valencia, Spain
E-mail: jmontana@gap.upv.es
Abstract
Currently, clusters of PCs are considered as a cost-
effective alternative to large parallel computers. In
some of them, it is critical to keep the system run-
ning even in the presence of faults (i.e. web servers
and high-performance computing). As the number
of elements increases in these systems, the probabil-
ity of faults increases dramatically, and thus, fault-
tolerance in the interconnection network plays a key
role.
A possible approach to provide fault-tolerance
consists of migrating the paths affected by the fail-
ure to new paths free of failures. However, to
this end, a routing algorithm able to compute the
new paths, in the presence of failures, while still
guaranteeing deadlock-freedom and connectivity, is
required. Also, it is desired that the algorithm
computes the new paths in a time-efficient man-
ner. In this paper we address this issue, propos-
ing a simple and effective fault-tolerant methodol-
ogy that can be applied to any topology. The al-
gorithm, referred to as Reachability-Based Fault-
Tolerant Routing (RFTR), builds new paths by join-
ing subpaths extracted from the set of already com-
puted paths. In order to avoid deadlock, RFTR
may perform a virtual channel transition on every
junction. RFTR meets the trade-off between the
achieved fault-tolerance degree and the number of
virtual channels required.
Additionally, in this paper, we apply RFTR to In-
finiBand (IBA), a new standard interconnect suit-
able for clusters. Preliminary results show that the
∗
This work was supported by the Spanish MCYT under Grant
TIC2003-08154-C06-01, and the JCC de Castilla-La Mancha un-
der Grant PBC-02-008.
RFTR tolerates up to six failures in tori and meshes
with only two virtual channels. Also, it exhibits a
low computation cost and does not degrade perfor-
mance.
1 Introduction
Over the recent years there is a trend in using clus-
ters of PCs for building large systems. Some ex-
amples are cluster-based commercial Internet portal
servers like AOL, Google, Amazon or Yahoo. Also,
clusters of PCs are currently being considered as a
cost-effective alternative for small and large-scale
parallel computing. Each time, more cluster-based
systems are included in the top500 list of supercom-
puters [5]. As an example, the Columbia system [7],
with 10,240 Intel® Itanium® 2 processors, is in the
second position.
In these systems, the interconnection network
plays a key role in the performance achieved. In
fact, clusters are being built by using high-end in-
terconnection networks like Quadrics [6], Infini-
Band [3], and Myrinet [1]. Among them, Infini-
Band (IBA) is a standard interconnect technology
for interconnecting processor nodes and I/O nodes,
thus building a system area network (SAN). The
InfiniBand Architecture (IBA) is designed around
a switch-based interconnect technology with high-
speed serial point-to-point links connecting multi-
ple independent and clustered hosts and I/O de-
vices. Therefore, this interconnect technology is
suitable to build large clusters. As an example, the
Columbia system uses InfiniBand.
Often, clusters are arranged on regular network
topologies when the performance is the primary
concern. Low dimensional tori (2D and 3D) are one
of the most widely used topologies in commercial
parallel computers. Furthermore, recent proposals,
such as Alpha 21364 [9] and BlueGene/L [8], use
2D and 3D tori, respectively.
In many cluster-based systems is critical to keep
the system running even in the presence of faults.
These systems use a very large number of compo-
nents (processors, switches, and links). Each in-
dividual component can fail, and thus, the proba-
bility of failure of the entire system increases. Al-
though switches and links are robust, they are work-
ing close to their technological limits, and therefore
they are prone to faults. Increasing clock frequency
leads to a higher power dissipation, and a higher
heating could lead to premature faults. So, fault-
tolerant mechanisms in cluster-based systems are
becoming a key issue.
In order to deal with faults, two fault models can
be used: static or dynamic. In a static fault model, it
is assumed that all the faults are known in advance
when the machine is(re)booted. In order to imple-
ment it, once a fault is detected, all the processes in
the system are halted, the network is emptied and a
management application is run in order to deal with
the faulty component. In a dynamic fault model,
once a new fault is found, actions are taken in order
to appropriately handle the faulty component with-
out stopping the network. For instance, a source
node that detects a faulty component through a path
can switch to a different path that does not use the
failed component.
Basically, there are three ways to tolerate a fault
in the interconnection network: component redun-
dancy, fault-tolerant routing algorithms, and recon-
figuration. Using component redundancy has been
the easiest and more costly way to provide fault tol-
erance. Components in the system are replicated
and once a failed component is detected, it is sim-
ply replaced by its redundant copy. An example of
using component redundancy can be found in the
Tandem’s Himalaya Servers [11].
Most of the fault-tolerant routing strategies pro-
posed in the literature for massively parallel com-
puters are not suitable for clusters (see chapter 6 of
[2] for a description of some of the most interesting
approaches). This is because they often require cer-
tain hardware support that is not provided by current
commercial interconnect technologies [1, 3]. Other
strategies rely on the use of adaptive routing. How-
ever, they cannot be applied as routing in clusters is
usually deterministic, which prevents packets from
circumventing the faulty components found along
their paths. Also, some of these routing strategies
need to perform dynamic virtual channel transitions
when the packet is blocked due to a fault. However,
virtual channels cannot be selected at routing time.
When using reconfiguration, once a fault is de-
tected, a reconfiguration process is started. This
process discovers the new topology and then com-
putes the new routing information. This approach
is appropriate for switch-based networks (Myrinet
[1], Quadrics [6], InfiniBand[3]) in which the topol-
ogy is defined by the end user. When using re-
configuration, any number of faults is tolerated as
long as the network remains connected. Reconfigu-
ration techniques can be either static or dynamic.
Unlike static techniques, dynamic reconfiguration
techniques [10] do not require completely stopping
the traffic in the network. However, some packets
must be removed from the network and re-injected
later, which could cause a strong degradation in per-
formance during the reconfiguration time.
In this paper we are interested in the dynamic
fault model applied to networks with determinis-
tic routing. Notice that dynamic reconfiguration
could be used. However, reconfiguration is used
when there is a need in changing the entire rout-
ing algorithm. The reouting algorithm use after re-
configuration will be different. This implies that
all the paths for every source-destination pair must
be computed. Additionally, there is a need to
add/use new hardware resources in order to guar-
antee deadlock-freedom during the reconfiguration
process. This is because packets routed with both
routings (before and after the reconfiguration pro-
cess) could form a cycle.
However, notice that when failures appear in the
network, they usually only affect to some paths. As
an example, Figure 1 shows a 3 × 3 mesh using
the XY routing. For the shake of simplicity, we as-
sume that endnodes will be attached only at switch
A, C, and E. When the link l fails, the path from
A to E is affected, whereas paths from A to C and
from C to E are not affected by the failure. Thus, we
would need to compound a new path from A to E.
However, notice that the XY routing does not pro-
vide a failure-free path from A to E. Therefore, the
endnodes are logically disconnected. In this situa-
174 Redes y Comunicación
(a) (b)
Path 3
Path 2 Path 2
New Path 3
Path
1
Path
1
A
A
L L
B
C D E
B
C D E
Figure 1: Example of the proposed methodology (a) Initial
paths, and (b) Paths after applying RFTR.
tion, a reconfiguration process would be launched.
Now, imagine that the network has several virtual
channels and they can be used for routing purposes.
In this situation, an illegal transition (Y → X) is
permitted (does not lead to deadlock) by perform-
ing a virtual channel transition (at the switch where
the illegal transition would be performed). There-
fore, a path performing a virtual channel transition
can be viewed as two joined subpaths, each one on
a different virtual channel. Since each subpath does
not introduce an illegal transition in its virtual chan-
nel, and virtual channels are used in an established
order, deadlock-freedom is ensured.
Applying this concept to the example, now the
new path from A to E could be computed by the
original XY routing and a virtual channel transi-
tion. In particular, the path A-B-C-D-E can be used
by placing a virtual channel transition at switch C.
Additionally, the new path can be obtained from the
set of paths already computed. Indeed, the new path
can be viewed as the A-C and C-E subpaths joined.
Notice that by using virtual channel transitions,
a full reconfiguration process is no longer needed
as the routing algorithm will be always the same.
Thus, no deadlock can be formed at any time. This
will let us to achieve the following benefits. Firstly,
the required amount of routing information to be
updated will be lower, leading to send a lower num-
ber of control packets. Secondly, the traffic not
affected by the failure will be left unmodified (a
kind of local reconfiguration process will suffice).
Thirdly, the method will take less time to compute
(compared with a full reconfiguration method), as
only affected paths will be recomputed. And, as a
consequence, less packets will be lost by the pro-
cess.
In this paper we propose a new fault-tolerant
routing methodology, referred to as Reachability-
Base Fault-Tolerant Routing (RFTR). The method,
applied to any topology, will tolerate dynamically
an unbounded number of failures with a low number
of virtual channels. It will provide new paths, for
those affected by a failure, based on routing by lay-
ers (on each layer an established path will be used).
When the transition between layers is not allowed
by the routing algorithm it will perform a virtual
channel transition. Moreover, RFTR will obtain the
substitutive routing paths in a time-efficient manner
for any network size. Notice that the methodology
does not depend on the hardware used for detect-
ing failures. Also, it does not depend on the way
failures are notified.
The rest of the paper is organized as follows. In
Section 2, the RFTR algorithm will be described.
In Section 3, RFTR will be applied to InfiniBand.
Then, in Section 4, the methodology will be evalu-
ated in terms of fault-tolerance and resource needs.
Finally, in Section 5, some conclusions will be
drawn.
2 Description of RFTR
In this Section, we will describe RFTR. Firstly, we
will introduce the concepts of direct and indirect
reachability. Then, the algorithm will be presented.
2.1 Direct and Indirect Reachability
Let us define the concepts of direct and indirect
reachability. Given a routing algorithm, switch B is
directly reachable from switch A if the routing algo-
rithm provides a valid path from A to B. At the same
time, switch A is indirectly reachable from switch B
if the algorithm provides a valid path from A to B.
Now let’s define the reachability concept related
to a given set of paths. Every switch visited by a
routing path is directly reachable from the source
of the path and indirectly reachable from the des-
tination of the path. As we are using deterministic
routing and we will base the computation of new
paths from the computed set of paths, we will use
this later definition.
In order to achieve a simple and fast computation
method, we create two tables, one for identifying
XVI Jornadas de Paralelismo, JP '2005 175
directly reachable nodes and one for identifying in-
directly reachable nodes. Taking into account the
switches and links used in all the routing paths, we
fill the tables.
The first table (Table 2.(a)), referred to as di-
rect reachability table (DRT), defines, for each path,
several entries. Each entry contains each directly
reachable switch from the source through the path,
in a sequential order (switch with lower number of
hops from source first). Also, it contains the source
and destination switches, the input link used at the
reachable switch, the number of hops needed to ar-
rive from the source to the reachable switch, and
the number of transitions (if any) of virtual chan-
nels required along the path to arrive from source to
the switch (initially none).
The second table (Table 2.(b)), referred to as indi-
rect reachability table (IRT), defines several entries
for each path. Each entry contains each indirectly
reachable switch from the destination through the
path, in a sequential order (switch with lower num-
ber of hops to destination first). In the same sense,
it contains the source and destination switches, the
output link used at the reachable switch, the num-
ber of hops needed to arrive to destination from the
reachable switch, and the number of transitions (if
any) of virtual channel required along the path to
arrive from the switch to the destination (initially
none).
2.2 Fault Tolerant Routing Methodology
The methodology will be applied for each path af-
fected by a failure, and will provide a substitu-
tive path. Basically, for a given source-destination
pair whose path uses the failed link, the method
will search in both tables and will build two sets.
The first one will contain all the directly reachable
switches from the source, whereas the second will
contain all the indirectly reachable switches from
the destination. Later, the method will intersect
both sets and will select one switch (directly reach-
able from the source and indirectly reachable from
the destination) as an intermediate switch. The new
path will consist of a subpath from the source to
the intermediate switch, if required a virtual chan-
nel transition, and a subpath from the intermediate
switch to destination.
The method starts from the notification of a new
failure. As a first step, it will identify the paths af-
fected by the failure. This is achieved by sweeping
both tables. Whenever it finds the failed link (input
link for DRT and output link for IRT) it annotates
the path. Also, it marks the entry as containing a
failed link and removes all the remaining entries for
the given path until destination (they are no longer
reachable using the path).
In order to build the set of directly reachable
switches, the method will sequentially sweep the
DRT searching for directly reachable switches from
the source. Indeed, the set will only include the in-
dexes to the table, not the switch ids. The same
is done with the IRT in order to build the set of
indirectly reachable switches. Note that a switch
may appear in one of the set several times as can be
reached by the source (or indirectly reached by the
destination) through different subpaths. Also, each
replica may use different number of virtual chan-
nel transitions and may be at different distance from
source (or destination). The method will keep the
replicas on each set in order to get the best option
when computing the final path.
Once sets are computed for a given affected path,
the method will select the appropriate intermediate
switch. For this, it will intersect both sets. No-
tice that when considering replicas, the method will
search each possible combination and will select the
best one based on the following criteria: the se-
lected final path will have the minimum number of
virtual channel transitions, and in the case of a tie,
the shortest path. In order to compute the number of
virtual channel transitions required by each combi-
nation, the method will take into account the num-
ber of virtual channel transitions for each subpath
(extracted from both tables) and if a new transition
is required at the intermediate switch (taking into
account the input and output link used, extracted
from both tables, and the routing restrictions of the
routing algorithm).
Once a substitutive path is obtained, the old path
is removed and the new one is added to DRT and
IRT. At the same time, the new routing info is dis-
tributed to the appropriate switches.
3 RFTR on InfiniBand
In this Section we will apply RFTR to InfiniBand
(IBA). For this, we will first describe the main as-
176 Redes y Comunicación
Src Dst Reach Trans. Input Link Hops
A C B - 2 1
A C C - 2 2
C E D - 1 1
C E E - 1 2
(a)
Src Dst Reach Trans. Output Link Hops
A C B - 0 1
A C A - 0 2
C E D - 3 1
C E C - 3 2
(b)
Figure 2: Examples of (a) DRT and (b) IRT filled with information of A-C and C-E paths.
pects of IBA (failure detection, VLs and SLs, and
mapping conflicts). Then, we will propose an en-
hancement to RFTR in order to be effective on IBA.
3.1 Routing and Mapping Conflicts in InfiniBand
In IBA, routing and virtual channel (they are re-
ferred to as Virtual Lanes, VLs) selection is per-
formed based on the destination local ID (DLID)
and the service level (SL) fields of the packet
header. These two fields are computed at the source
node and do not change along the path. Every
switch has a forwarding table where the output port
for each destination is provided. The destination ID
is located at the packet header and does not change
along the path. Therefore, IBA routing is a kind of
source routing with the routing info distributed.
Up to 15 data virtual lanes can be used in IBA.
Virtual lane selection is based on the use of service
levels (SLs). By means of SLtoVL mapping tables
located on every switch, SLs are used to select the
proper VL at each switch. This table returns, for a
given input port and a given SL, the VL to be used
at the corresponding output port. For this, the SL is
placed at the packet header and it cannot be changed
by the switches. Therefore, we should also assign
the proper SL that must be used for a given path.
However, the fact of fixing a path with a unique
SL can lead to a mapping conflict. It occurs when
two packets labeled with the same SL enter a switch
through the same input port, and they need to be
routed to the same output port but through different
VLs. The problem is that the SLtoVL mapping ta-
ble does not use the input VL in order to determine
the output VL. Figure 3.(a) shows an example. At
switch R a mapping conflict arises as it is not pos-
sible to distinguish both paths because they are la-
beled with the same SL. It has to be noted that this
problem arises only when there are paths that use
different VLs in the network. For example, the path
B uses VL0 until switch Q and then uses VL1.
A mapping conflict can be solved only by using
different service levels (SLs) for each path causing
the mapping conflict. However, this often leads to
an excessive number of SLs. Another solution is to
use an alternative path that does not cause a map-
ping conflict. However, obtaining such alternative
path strongly depends on the flexibility provided by
the applied routing algorithm, on the available net-
work resources (VLs), and the strategy applied to
obtain SLtoVL tables.
3.2 Fault Detection in InfiniBand
An IBA network is divided in subnets (connected
through routers). On each subnet there is a network
connecting endnodes, switches, and routers. The
SubnetManager (SM) is the entity that discovers all
the devices on an IBA subnet, configures them, and
detects any change in the subnet’s topology. The
SM is allocated in a particular node in the network.
A change in the topology can be due to the fact that
either some devices are added or removed from the
network, or because of a link failure. In each net-
work device there exists a SubnetManager Agent
(SMA), which is responsible for monitoring port’s
link integrity.
The IBA specs define two complementary mech-
anisms for detection of failures. On one hand the
SM will perform periodic sweeps of the subnet to
detect any change to the subnet’s topology and re-
questing monitoring information to each SMA as-
sociated to each switch. The frequency of these
sweeps is not defined by the specs. It can be ad-
justed according to parameters like the size of the
subnet or the desired detection time for failures. On
the other hand, each SMA could notify to the SM
the changes detected in the switch links.
XVI Jornadas de Paralelismo, JP '2005 177
R
A (SL=1)
B (SL=1)
VL1
VL1 VL1
VL1 VL1
VL0
VL0
VL0
VL1 VL1
Q
(a)
0
2
4
6
8
10
0 2 4 6 8 10
Medium
lenght
path
Number of failure links
Mesh 7x7
Torus 7x7
(b)
Figure 3: (a) Mapping conflict example. (b) Example of medium length Paths in a 7x7 Torus and a 7x7 Mesh Network.
Once the occurrence of a failure is notified to the
SM, the SM will send the notifications for path mi-
gration to all the nodes which have routing paths
traversing the fault link. To this end, a special rout-
ing mechanism, namely Directed-Route, is used.
According to the IBA specs, Directed-Route is used
for routing control packets, through a reserved VL.
The path of each packet is established by specifying
all the output ports along the switches to be crossed.
As it defines the route paths port by port, the failure
will be avoided.
Flow control packets have higher priority than
control and sweep packets from the SM. In a con-
gested scenario, control packets may be discarded.
If the SM does not receive an answer before a
TIMEOUT (this time will be defined as a function
of subnet’s size), it will send again the packet, (it is
not defined how many times it can be resent). In the
evaluation section, we will follow this method for
fault detection.
3.3 Applying RFTR to InfiniBand
In order to apply this methodology to IBA, we will
consider that the computation will be performed by
the SM.
As previously exposed, the number of SLs are
limited in IBA. Thus, we will include an addi-
tional criteria to select the appropriate intermediate
switch. In particular, we will select the intermediate
switch that minimizes the number of SLs used.
RFTR on IBA will use a new LID for each new
computed path, trying to use the same LID for all
the new paths with the same destination. This is al-
lowed in IBA with the virtual addressing scheme[3].
Notice that in IBA up to 128 different LIDs can be
used to address the same destination. Also, in the
case there is a routing conflict (two packets with
the same LID at the same switch must be forwarded
through two different output ports), a new LID may
be required.
Once all the new paths are computed, the SM will
send the new routing info (only changes in the rout-
ing tables and SLtoVL tables to be updated) , to the
switches, and new LIDs to all the endnodes. Notice
that the size of information sent will be different
for each switch or endnode (even some switches or
nodes will do not receive new routing information).
This information will be sent using Direct-Route.
When an endnode receives the new LIDs, it will
start to send messages with the new LID, and the
switches will route them with the new routing info.
However, it may happen that a message arrives to
a switch which still does not have the new routing
info. In this case, it will discard the packet (because
the LID has not an output link defined in the for-
warding table). By using different LIDs we guaran-
tee that the process is deadlock free, because the old
and new paths are deadlock free.
4 Evaluation
We will evaluate RFTR in 7x7 Torus and 7x7 Mesh
networks. In the analysis, we will only consider
faults of links connecting switches. Note that a
switch failure can be viewed as if all its links had
failed. Moreover, a failure in a link connecting
a host to a switch does not change the topology.
RFTR will be evaluated when different traffic rates
(low and near saturation) are applied and when dif-
178 Redes y Comunicación
ferent sequential random link failures appear. The
applied routing algorithm is up*/down* with one
virtual channel (initially no virtual channel transi-
tions).
For this we will use the simulation tool and sim-
ulation parameters presented in [4]. The simulator
models an IBA network, following the IBA specifi-
cations [3].
4.1 Simulation Experiments
Figure 5(a) shows the performance of up*/down* in
a 7x7 Torus Network. Figures 5(b,c) show the traf-
fic evolution when a failure is injected and RFTR is
applied for different injection rates. Vertical lines
indicate (in sequential order), the time when the
failure is injected, the time when the SM receives
the notification of the failure, the time when the SM
finishes the computation of substitutive paths and
the time when all switches and nodes have received
all the new routing information.
Figures 5(b,c) also show the discarded traffic.
The computation time required by RFTR has been
estimated from real experiments (Athlon 1800).
The percentage of traffic lost is low. Notice also
that the loss rate keeps constant as sources are not
notified until the new paths are computed. An opti-
mization would be to notify sources (from the SM)
that no more packets should be injected to certain
destinations. Also, notice that useful traffic is not
significantly affected by the process. It has to be
noted that in this case the failed link is near the root
switch (in up*/down*) thus affecting almost half of
the paths (worst case). Finally at the end of the
process a slight increase in loss rate is experienced.
This is due to the new LIDs being used by endnodes
and in some cases switches will have not updated
their tables.
Table 1 shows the resources required in IBA. No-
tice that we are considering an unbounded number
of resources. For each case, up to 37.000 random
combinations have been evaluated (table shows the
worst case). It has to be noted that all the cases
where successfully handled by RFTR. Also, with
three virtual channels up to 8 failures are tolerated
in the torus case (four virtual channels for the mesh
case). Additionally, with 4 SLs, up to 5 failures in
Torus (5 SLs for tolerating 5 failures in the mesh
cases).
Torus 7x7 Mesh 7x7
Number
of
failures
Maximum
of
SL
Maximum
of
VLs
Maximum
of
SL
Maximum
of
VLs
1 2 2 2 2
2 2 2 3 2
3 3 2 4 2
4 4 2 5 2
5 4 2 5 2
6 6 2 23 4
7 6 3 24 4
8 6 3 37 4
Table 1: Results for a Torus 7x7 and a Mesh 7x7
Using the RFTR the size of the routing infor-
mation sent will depend on the number of affected
paths by the failure, Figures 4(a,b) show the amount
of routing information sent to every switch when
there is a failure in a Torus 7x7. Figure 4(a) repre-
sents where the failure is equidistant from the leaves
and the root of the up*/down*, whereas Figure 4(b)
represents the case when the failure is a link of the
root switch (worst case). Figure 4(c) shows the case
for a total reconfiguration. It can be seen that RFTR
sends a very small fraction of routing info.
5 Conclusions
In this paper, we have proposed a new fault-tolerant
routing algorithm. The algorithm, referred to as
Reachability-Based Fault-Tolerant Routing (RFTR)
is based on the direct and indirect reachability con-
cept. The method computes new paths for those
source-destination pairs affected by failures, and
obtains the new paths by computing the set of di-
rectly reachable switches from source, the set of in-
directly reachable switches from destination and in-
tersecting them. A virtual channel transition may be
required in order to guaranteeing deadlock freedom.
Preliminar evaluation results show that with a
low number of resources (in terms of virtual chan-
nels and service levels for InfiniBand), RFTR is
able to tolerate up to 5 failures in 2D meshes and
tori. As the method only computes paths for those
failed, it is able to obtain an stable set of paths in a
XVI Jornadas de Paralelismo, JP '2005 179
0
500
1000
1500
2000
2500
0 5 10 15 20 25 30 35 40 45
Bytes
Switches
(a)
0
500
1000
1500
2000
2500
0 5 10 15 20 25 30 35 40 45
Bytes
Switches
(b)
0
500
1000
1500
2000
2500
0 5 10 15 20 25 30 35 40 45
Bytes
Switches
(c)
Figure 4: Example of routing Information sent to each switch after a failure, (a-b) proposed methodology, (c) reconfiguration
process, in a torus 7x7.
0
2000
4000
6000
8000
10000
0 0.0010.0020.0030.0040.0050.0060.007
Average
Message
Latency
(cycles)
Traffic (flits/cycle/switch)
(a)
0
0.0002
0.0004
0.0006
0.0008
0.001
1.28e+08 1.32e+08
Traffic
(flits/cycle/switch)
Execution Time
Traffic Lost (flits/cycle/switch)
Traffic Useful (flits/cycle/switch)
(b)
0
0.002
0.004
0.006
0.008
0.01
1.2e+07 1.4e+07 1.6e+07 1.8e+07
Traffic
(flits/cycle/switch) Execution Time
Traffic Lost (flits/cycle/switch)
Traffic Useful (flits/cycle/switch)
(c)
Figure 5: (a) Network Latency vs injected traffic,Example of injection of 1 failure in a 7x7 Mesh Network for (b) low load
(c) near congestion.
time-efficient manner, thus minimizing the number
of lost packets.
As a future work we plan to optimize the method
by preventing the nodes to inject packets after the
detection of the failure. Also, want to compare
performance of RFTR with a full reconfiguration
method like Simple Reconfiguration and Double
Scheme.
References
[1] N. J. Boden, D. Cohen, R. E. Felderman, A. E. Ku-
lawik, C. L. Seitz, J. Seizovic and W. Su, “Myrinet -
A gigabit per second local area network,” IEEE Mi-
cro, pp. 29–36, Feb. 1995.
[2] J. Duato, S. Yalamanchili, and L. Ni. Interconnec-
tion Networks. An Engineering Approach. Morgan
Kaufmann Publishers, 2003.
[3] InfiniBand™Trade Association, Infini-
Band™Architecture. Specification Volume 1. Re-
lease 1.0. Available at http://www.infinibandta.com/
[4] O. Lysne, J. M. Montañana, T. Mark Pinkston, J. Du-
ato, T. Skeie, J. Flich, "Simple Deadlock-Free Dy-
namic Reconfiguration" in Int’l Conference on High
Performance Computing, Dec 2004.
[5] Top5000 Supercomputer list webpage,
http://www.top500.org, Nov. 2004.
[6] F. Petrini, W.Feng, A. Hoisie, S. Coll, and E. Fracht-
enberg. "The Quadrics Network (QsNet): High-
Performance Clustering Technology," in Proc. of the
9th IEEE Hot Interconnects. (HotI’01), Palo Alto,
California, Aug. 2001.
[7] COLUMBIA SUPERCOMPUTER web-
page http://www.nas.nasa.gov/About/Projects/
Columbia/columbia.html
[8] IBM BG/L Team, An Overview of BlueGene/L
Supercomputer, ACM Supercomputing Conference,
2002.
[9] S.S. Mukherjee, P. Bannon, S. Lang, A. Spink, D.
Webb, "The Alpha 21364 Network Architecture," in
IEEE Micro, Jan-Feb 2002.
[10] R.Casado, A Bermdez, J. Duato, F.J. Quiles, and J.L.
S�chez, "A protocol for deadlock-free dynamic
reconfiguration in high speed local area networks,"
in IEEE Trans. on Parallel and Distributed Systems,
Vol. 12, No. 2, pp. 115-132, 2001.
[11] Himalaya server, http://www.compaq.com
180 Redes y Comunicación
Reducción del consumo de potencia en redes de interconexión
construidas con conmutadores de alto grado
Marina Alonso; Juan-Miguel Martínez; Vicente Santonja; Pedro López; José Duato1
DISCA
Universidad Politécnica de Valencia
malonso@disca.upv.es
1
Este trabajo ha sido financiado por el MCYT con el proyecto TIC2003-08154-C06-01
Resumen
Una de las alternativas para aprovechar la
disponibilidad de conmutadores con un alto número
de puertos para la construcción de clusters de PCs
consiste en interconectar cada par de conmutadores
a través de varios enlaces formando lo que
denominaremos enlace múltiple (en inglés trunk
link). Esta conectividad extra puede explotarse
mediante la utilización de algoritmos de
encaminamiento adaptativos, que incrementan la
productividad y reducen la congestión. Sin
embargo, con baja carga no se utilizarán todos los
enlaces que componen el enlace múltiple, aunque sí
continuarán consumiendo potencia. En este trabajo,
presentamos un mecanismo que dinámicamente
conecta y desconecta los enlaces de los
conmutadores en función del tráfico presente en la
red. El mecanismo puede apagar cualquier enlace
mientras se garantice la conectividad de la red. Esta
restricción hace posible el uso del mismo algoritmo
de encaminamiento con independencia de las
acciones que realice el mecanismo de ahorro de
potencia, simplificando así el diseño de la red.
1. Introducción
Desde hace ya algún tiempo, los cluster de PCs son
una alternativa viable a las máquinas paralelas de
gran escala. Actualmente, los clusters utilizan
tecnologías de interconexión basadas en el uso de
conmutadores y enlaces punto a punto. Myrinet [5],
Quadrics [6], InfiniBand [9] o ASI (anteriormente
PCI AS) [1] son algunos ejemplos. El progresivo
aumento en el tamaño de los clusters ha motivado la
utilización de topologías regulares, directas o
indirectas, en lugar de las irregulares empleadas en
un principio. Por otra parte, el número de puertos por
conmutador (grado) ha ido también aumentado
progresivamente. Por ejemplo, Mellanox [4] que
comercializa conmutadores con 24 puertos de 10
GB/s; y Myricom [5] dispone de conmutadores que
llegan hasta 32 puertos. Hay varias alternativas para
aprovechar la disponibilidad de conmutadores de
grado alto. Las redes multietapa son una buena
elección [15,8]. Sin embargo, cuando el tamaño de la
red aumenta, la longitud del conexionado y su com-
plejidad crece notablemente. Por otra parte, las topo-
logías regulares directas (p.e. toro o malla 2-D/3-D)
permiten construir redes grandes sin comprometer la
longitud del conexionado o su complejidad. De
hecho, la disponibilidad de conmu-tadores de grado
alto permite implementar cada dimensión de la red
con varios canales físicos en paralelo. Los canales
físicos pueden combinarse para trabajar como un
único enlace más ancho (así se incrementa el ancho
de banda del canal) o pueden utilizarse para
incrementar el número de caminos en la red,
aumentando así la flexibilidad de encaminamiento,
reduciendo la contención e incrementando las
prestaciones de la red de interconexión. En este
trabajo, consideraremos la segunda propuesta. La
Figura 1 muestra un ejemplo para una malla 2-D
donde cada par de conmutadores se conectan
mediante 4 enlaces.
Sin embargo, con poca carga, sólo se utilizan unos
pocos enlaces del enlace múltiple. Para soportar el
gran ancho de banda de los enlaces es necesario
mantener la sintonización de frecuencia del enlace
incluso cuando no se transmiten datos. Como conse-
cuencia, los enlaces inactivos continúan consumiendo.
Figura 1. Malla 2-D con enlaces múltiples
Un mayor consumo de potencia no sólo ocasiona
un mayor gasto económico y energético, sino que
además obliga a utilizar mecanismos complejos de
disipación del calor. Además, la probabilidad de que
se produzcan ciertos fallos aumenta con la
temperatura. Todos estos aspectos justifican la
importancia que el control de consumo de potencia
tiene en el sistema. En este trabajo nos centramos en
las redes de interconexión. Aunque la potencia
consumida por la interconexión es una fracción del
total, tampoco es despreciable. Seguidamente se
ilustran algunos ejemplos. El router integrado y los
enlaces del microprocesador Alpha 21364 consumen
en torno al 20% del total de potencia (23 W de un
total de 125 W), donde el 58% de la potencia se
consume en la circuitería de enlace [18]. El
conmutador InfiniBand de 8-puertos 12X de IBM,
tiene un consumo estimado de 31 W, con un consu-
mo para los enlaces superior al 65% (20 W) [16].
Se han propuesto algunas técnicas para reducir el
consumo de potencia en las redes de interconexión.
La de escalado de voltaje dinámico (DVS) [14]
permite que el enlace trabaje en un rango discreto de
frecuencias y tensiones de alimentación. En [16] se
propone usar la utilización pasada en la red para
predecir el futuro, ajustando en consecuencia el nivel
DVS de los enlaces. El principal inconveniente del
DVS es la complejidad del circuito que asegura el
correcto funcionamiento de los enlaces durante el
proceso de escalado, añadiendo importante retraso y
necesidad de área CMOS adicional. Además, los
enlaces DVS continúan consumiendo potencia
incluso cuando están inactivos. La política de gestión
dinámica de potencia (DPM) [17] apaga y enciende
enlaces de forma selectiva en función de la
utilización de los mismos. Para evitar utilizar los
enlaces que se encuentran apagados, se debe utilizar
un algoritmo de encaminamiento tolerante a fallos, lo
cual incrementa su complejidad, y, lo que es peor,
penaliza las prestaciones de la red. La propuesta
DALW [7] ajusta el ancho del enlace en función de
la carga presente en la red. Sin embargo, DALW
nunca desconecta completamente los enlaces, por lo
que puede utilizarse el mismo algoritmo de
encaminamiento independientemente de si está
ahorrando potencia o no, lo que simplifica el diseño
del router. Por otra parte, se pueden llegar a valores
muy bajos de consumo de potencia. Su principal
inconveniente es el incremento en la latencia cuando
la red se encuentra con baja carga.
En este trabajo, se propone una estrategia
sencilla para reducir el consumo de potencia en redes
regulares construidas con conmutadores de grado
alto y enlaces múltiples. Se basa en la conexión y
desconexión selectiva de los enlaces serie de alta
velocidad que componen el enlace múltiple, en
función del tráfico presente en la red. Esta propuesta
se encuentra a mitad de camino entre las propuestas
DPM (en la medida que apaga enlaces) y el DALW
(en la medida que nunca apaga completamente un
enlace múltiple). El resto del trabajo se ha organizado
como sigue. La Sección 2 describe el mecanismo
propuesto para la reducción del consumo de
potencia, éste se evalúa en la Sección 3. Finalmente,
se presentan algunas conclusiones.
2. Descripción del Mecanismo de Ahorro
de Potencia
El mecanismo propuesto incrementa o reduce
dinámicamente el número de enlaces serie que
componen un enlace múltiple, en función del tráfico
presente en la red. Cuando el tráfico es alto, todos los
enlaces (de una dimensión) se encontrarán ocupados,
y se mantendrán en este estado. Por otra parte,
cuando el tráfico es bajo, como máximo n-1 de los n
enlaces que componen el enlace múltiple se podrán
desconectar para reducir el consumo de potencia.
Nótese que, al mantener uno de los enlaces siempre
operativo, se puede utilizar en la red de interconexión
el mismo algoritmo de encaminamiento.
Obviamente, los enlaces desconectados no pueden
ser utilizados por el algoritmo de encaminamiento
como posibles opciones para encaminar. Esto es fácil
tratando enlaces desconectados como ocupados.
El tráfico a través de los enlaces múltiples se
mide a partir de la utilización del enlace, la cual se
obtiene mediante un contador que se incrementa cada
vez que se transmite un phit a través de cualquiera de
sus enlaces individuales. Este contador se comprueba
periódicamente a los efectos de aplicar si procede
alguna de las acciones de ahorro de potencia. Tras
obtener la utilización de un enlace múltiple, se actúa
en función de las siguientes reglas:
182 Redes y Comunicación
x Si la utilización del enlace múltiple baja por
debajo de un cierto umbral uL, uno de sus enlaces
se apaga (sólo si éste no está siendo utilizado por
algún paquete). Se debe prestar especial atención
para evitar el apagado del último enlace
operativo en el enlace múltiple.
x Si la utilización aumenta por encima de un cierto
umbral uH, se conecta uno de los enlaces que
previamente se habían desconectado, si hay
alguno.
Debe tenerse presente una consideración adicional
para evitar la congestión en la red. En una red con
enlaces desconectados, un aumento del tráfico sin
que los enlaces se reconecten rápidamente puede
hacer que la red entre en saturación, degradando
notablemente sus prestaciones. En esa situación la
utilización de los canales nunca aumentará y los
enlaces no se reconectarán. Por este motivo, el
mecanismo propuesto comprueba si hay mensajes
generados localmente que están esperando a ser
inyectados en la red (en una cola de inyección). En
caso afirmativo, puede ser un síntoma de saturación
de la red, por lo que todos los enlaces desconectados
deberán conectarse inmediatamente, independiente-
mente de su utilización.
El comportamiento del sistema vendrá condicionado
por la pareja de umbrales (uH y uL). El efecto de estos
dos parámetros se puede analizar en términos de dos
aspectos complementarios:
x Agresividad del mecanismo. Viene determinada
por el valor medio de los dos umbrales, uavg
(uavg=(uH+uL)/2). Un valor alto de uavg
proporciona una política agresiva, ya que los
enlaces se mantienen desconectados incluso con
cargas altas. Por otra parte, si uavg es bajo, se
aplicará una política conservadora ya que el
ahorro del consumo de potencia sólo se activará
con cargas muy bajas.
x Capacidad de respuesta (responsiveness) del
mecanismo. El ancho de la histéresis, definido
como la diferencia entre uH-uL, controla la
capacidad de respuesta del mecanismo ante
variaciones en el tráfico. Con anchos de
histéresis altos, serán necesarias variaciones
importantes en el tráfico para que se conecten o
desconecten enlaces, mientras que pequeñas
variaciones de tráfico no afectarán al estado del
sistema.
Teniendo en cuenta las consideraciones anteriores,
nuestra propuesta puede sintonizarse para conseguir
distintos comportamientos en base a ajustar la
agresividad y la capacidad de respuesta. Sin
embargo, aparecen ciertas limitaciones en relación a
los valores posibles de los umbrales. En primer lugar,
uH debe ser mayor que uL. En segundo lugar, uH debe
ser menor que la utilización máxima alcanzada por
los enlaces con la carga más alta aceptada por la red.
En caso contrario, la red entrará en saturación antes
de intentar conectar los enlaces. Obviamente, se debe
garantizar que uL>0. Finalmente, se presenta una
limitación adicional condicionada por la fracción del
ancho de banda del enlace múltiple disponible para
cada estado del enlace múltiple. Seguidamente se
explica este aspecto utilizando un sencillo ejemplo.
Consideremos una red basada en enlaces múltiples
con cuatro enlaces serie por cada enlace múltiple
(Figura 2). Habrá cuatro posible estados del enlace
múltiple, y, consecuentemente cuatro anchos de
banda posibles. El ancho de banda B se alcanzará
cuando estén conectados los cuatro enlaces (estado
S4); B’ se alcanzará con tres conectados y uno
desconectado (estado S3); B’’ con dos enlaces
conectados y dos desconectados (estado S2); y B’’’
cuando se encuentre un enlace conectado y tres
desconectados (estado S1). Como se indicó
anteriormente, al menos un enlace del enlace
múltiple debe estar conectado.
Figura 2. Ancho de banda del enlace múltiple en función
del estado del enlace múltiple, Si, donde i
indica el número de enlaces activos
Consideremos la situación en la que el enlace
múltiple de la Figura 2 está en el estado S4. Si la
utilización del enlace múltiple baja por debajo del
umbral bajo uL, el mecanismo propuesto desconec-
tará un enlace. El ancho de banda disponible se redu-
ce, y suponiendo que no ha habido variación en el
tráfico, la utilización aumentará en el mismo factor
(4/3 para la transición entre S4 y S3, 3/2 entre S3 y S2,
y 2/1 entre S2 y S1). Este aumento en la utilización se
detectará en el siguiente muestreo, y en función de
los umbrales escogidos, puede ocurrir que la utiliza-
XVI Jornadas de Paralelismo, JP '2005 183
ción medida, U, sea mayor que uH (U > uH),
volviendo a conectar el enlace desconectado previa-
mente. Este fenómeno podría producir oscilaciones
en el estado del enlace múltiple. Como el encendido
y apagado de un enlace requiere un tiempo no
despreciable y durante este tiempo el enlace está no
operativo pero consume como si estuviera conectado,
estas oscilaciones deben evitarse. Para ello, el umbral
uH debe ser mayor que el incremento en la utilización
media del enlace cuando cambia del estado Si al Si-1.
Este incremento vendrá dado por el ratio de anchos
de banda disponibles en cada estado. En nuestro
ejemplo con cuatro enlaces serie por cada enlace
múltiple, estos ratios son 4/3, 3/2, y 2/1 cuando hay
respectivamente 4, 3, 2 enlaces conectados y el
mecanismo desconecta uno de ellos. El peor caso
ocurre cuando se cambia del estado S2 al estado S1.
Así pues, para evitar transiciones de estado cíclicas,
se debe cumplir uH •2uL con lo que en el peor caso,
cuando cambia del estado S2 al S1, el incremento en
la utilización media del enlace múltiple no hará que
se vuelva al estado anterior. La Figura 3 muestra la
región de los umbrales posibles teniendo en cuenta
las restricciones anteriores. Cualquier punto dentro
de la zona sombreada proporciona una configuración
válida, combinando capacidad de respuesta y política
de ahorro de potencia. Este diagrama puede aplicarse
a sistemas basados en conmutadores con cualquier
número de enlaces por enlace múltiple, donde n-1 de
los n enlaces pueden desconectarse. El sistema tendrá
una transición entre un estado con dos enlaces conec-
tados a sólo uno conectado, debiendo así mantenerse
la condición indicada anteriormente: uH • 2 uL.
3. Evaluación de Prestaciones
Seguidamente, evaluaremos la estrategia de ahorro
de potencia propuesta en el presente trabajo.
Utilizando un modelo de simulación, se analizará la
relación entre ahorro de potencia y latencia.
Analizaremos también la influencia de los párame-
tros de diseño más importantes (umbrales uH y uL).
3.1. Modelo de la Red
Nuestro simulador modela una red de interconexión
basada en wormhole a nivel de flit [11]. Cada nodo
de la red está compuesto por un procesador, su
memoria local y un encaminador. El encaminador
contiene una unidad de control de encaminamiento,
un conmutador, y varios enlaces físicos. Hay cuatro
canales de memoria independientes conectando el
encaminador con la memoria local. Se utiliza
evitación de bloqueos con un algoritmo de
encaminamiento totalmente adaptativo [11]. Los
nodos se interconectan mediante enlaces múltiples, y
cada enlace múltiple está compuesto por 4 enlaces
físicos. Los canales físicos se descomponen en tres
canales virtuales (uno adaptativo y dos de escape).
Cada canal virtual tiene asociado un buffer con
capacidad de cuatro flits. En cada nodo se incluye el
mecanismo de ahorro de potencia propuesto en este
trabajo. Haciendo uso de este simulador, hemos
evaluado un toro 2-D con 32x32 nodos.
Figura 3. Mapa de posibles umbrales. El área sombreada
corresponde con el espacio de valores
válidos para uH yuL
3.2. Modelo de Tráfico
El tráfico en la red depende de la tasa de generación
de mensajes en cada nodo, el tamaño de los
mensajes, y el destino de cada mensaje.
Vamos a presentar dos tipos de experimentos. En
primer lugar, evaluaremos el comportamiento de la
red con una tasa de generación constante, evaluando
todo el rango de tráfico, desde baja carga hasta la
saturación. Seguidamente analizaremos el comporta-
miento dinámico de la red, usando durante la
simulación tasas variables para la generación de
mensajes. En estos experimentos hemos utilizado
una carga auto-similar. Todos los nodos en la red
tienen el mismo comportamiento: el tiempo entre
llegadas se genera en función del tipo de carga, la
longitud del mensaje es fija e igual a 16 flits y, el
nodo destino de cada mensaje se escoge entre todos
los nodos de la red (excepto el nodo origen) con la
misma probabilidad.
184 Redes y Comunicación
3.3. Parámetros del Mecanismo Propuesto
Cada enlace múltiple está preparado para operar con
cuatro anchos de banda distintos: desde sólo un
enlace activo hasta los cuatro. La dinámica de este
modelo se gestiona mediante el umbral bajo (uL) y el
umbral alto (uH). La Figura 3 marca el área permitida
para la elección de los valores de los umbrales. En
los experimentos siguientes se explora esta área
mediante la selección de diferentes valores para uL y
uH para así poder alcanzar diferentes objetivos en
cuanto a la capacidad de respuesta y agresividad del
mecanismo de ahorro del consumo de potencia.
(a)
(b)
Figura 4. Comparación de (a) latencia y (b) potencia
relativa consumida en un toro 2D: uH = 2uL
Por otra parte, un enlace no puede conectarse de
forma instantánea, se requiere un tiempo Ton. La
desconexión de un enlace también precisa un cierto
tiempo Toff. Cuando un enlace se desconecta,
supondremos que queda inmediatamente inutilizado
pero continúa consumiendo potencia hasta que han
transcurrido los Toff ciclos. Por el contrario, cuando se
conecta un enlace estará disponible para enviar
mensajes después de haber transcurrido Ton ciclos,
pero el consumo de potencia se aumenta desde el
comienzo. Basándonos en los valores indicados en
[14, 17], se ha utilizado Ton=Toff=1000 ciclos de
reloj. El estado de la red se comprueba
periódicamente a los efectos de determinar si es
necesario apagar o encender algún enlace. Se ha
utilizado un período mayor a Ton y Toff para que la red
se pueda estabilizar tras cada cambio.
Concretamente, el período se ha fijado en 2000 ciclos
de reloj.
Tal y como se indicó en la Sección 2, el valor de los
umbrales está condicionado por la utilización
máxima alcanzable por la red UMAX. Se ha analizado
la utilización media de los enlaces en un toro 2-D con
1024 nodos en función del tráfico procesado usando
una distribución uniforme, obteniendo que la
utilización aumenta linealmente con el tráfico hasta
un valor UMAX=0.65. Con tasas de inyección mayo-
res, la utilización de la red se reduce debido a la
congestión presente en la red. Basado en esta utiliza-
ción máxima y en las restricciones mostradas en la
Figura 3, se estudia el efecto de los umbrales en el
consumo de potencia y en las prestaciones de la red.
3.4. Prestaciones y Resultados de Consumo de
Potencia
Las figuras 4a y 4b comparan la latencia de los
mensajes y la potencia relativa consumida para
diferentes valores de umbrales de conexión/
desconexión. Para todas las curvas, se ha tomado
uH=2uL, la condición mínima para evitar los ciclos.
Las figuras 4a y 4b muestran que utilizando un valor
superior para uH, supone una política más agresiva.
Cuando uH se acerca a UMAX, se consigue un ahorro de
potencia mayor con la penalización de incrementar la
latencia. La figura 4a también incluye una curva que
representa la latencia de la red cuando no se aplica el
mecanismo de ahorro de potencia. Como puede
observarse, la latencia aumenta moderadamente
excepto para un punto en la curva (uL=0.32, uH=0.65).
La razón es que, en este caso, estamos utilizando
valores muy ajustados para los umbrales. Por lo
general, el mecanismo de ahorro de potencia está libre
de ciclos, pero de forma aleatoria en la carga se pueden
generar algunos ciclos de conexiones/desconexiones
en algunos puntos de la red. Como puede apreciarse, el
comportamiento desaparece cuando se utilizan valores
pequeños para (uL, uH). La figura 4b muestra que
utilizando una opción agresiva para (uL, uH) se pueden
obtener importantes ahorros de potencia. En el caso
(uL=0.32, uH=0.65) se producen importantes ahorros
de potencia con baja carga. Cuando el tráfico aumenta,
se obtiene menores ahorros de potencia, y cuando el
tráfico alcanza 0.38 flits/ciclos/conmutador, la red se
encuentra totalmente conectada: los cuatro enlaces en
cada enlace múltiple se encuentran activos. Si se
XVI Jornadas de Paralelismo, JP '2005 185
utilizan valores pequeños para (uL, uH), la potencia
consumida es mayor y la red se conectará
completamente. Nótese que la cota inferior del
consumo de potencia es 25% (ahorro del 75%, 3
enlaces desconectados de los cuatro disponibles).
Las Figuras 5a y 5b muestran resultados para
uH=3 uL, los valores (uL, uH) no son tan ajustados
y el sistema evita ciclos de encendido/apagado. El
incremento de latencia (figura 5) es muy reducido.
El uso de intervalos anchos (uL, uH) supone que,
para un valor dado de uH, el valor de uL es menor.
Así, se requieren valores muy pequeños de la
utilización del enlace para apagar el enlace, y la
potencia consumida por la red es mayor. Esto se
ilustra en la figura 5b. Para poder verificar si el
incremento de la latencia se compensa con el
ahorro de potencia, se evalúa el producto LrelPrel
[10], donde Lrel es la latencia relativa con relación
a la latencia obtenida. Cuando no se aplica
mecanismo de ahorro de potencia; y Prel es la
potencia relativa consumida cuando no se utiliza
el mecanismo de ahorro de potencia LrelPrel=1, ya
que ambos factores son igual a uno.
(a)
(b)
Figura 5. Comparación de (a) latencia y (b) potencia
relativa consumida en un toro 2 D: uH=3uL
La figura 6 muestra que para uH=2uL se
obtiene un buen balance ya que LrelPrel”1.
Se han realizado diversos experimentos para
analizar el comportamiento de la red cuando
incorpora el mecanismo de ahorro de energía.
Concretamente, se han probado umbrales medios de
0.3, 0.4 y 0.5 con un ratio, uH/uL, de 2, 2.5 y 3,
excepto para uavg=0.5 ya que este punto corresponde
con el vértice derecho superior del gráfico mostrado
en la Figura 3, donde únicamente uH/uL=2 es posible.
Estos puntos de test, cuyos resultados se muestran en
la figura 7, proporcionan diferentes configuraciones
del sistema cercanas a la máxima capacidad de
respuesta alcanzable, conforme a las consideraciones
presentadas en la sección 2. Como era de esperar, se
obtienen mayores ahorros de potencia con una
política más agresiva. Cuando se mantiene constante
el umbral medio y se estrecha la banda de histéresis,
se incrementa el ahorro de potencia; esto es debido
principalmente por el incremento de uL cuando
disminuye la banda de histéresis: como uL se
incrementa el router intenta desconectar enlaces con
cargas altas.
Figura 6. Producto de la latencia relativa y consumo de
potencia relativo: uH=2uL
Para analizar el comportamiento dinámico del
mecanismo propuesto, se han ejecutado simulaciones
utilizando dos niveles de carga. Se inicia la
simulación con poco tráfico, tras un período de
tiempo, la carga crece lentamente y de forma
constante hasta un valor siete veces superior al
inicial. Esta carga elevada se mantiene durante 60000
ciclos. Entonces, el tráfico de entrada se decrementa
nuevamente de forma constante hasta alcanzar el
valor inicial. Para este estudio se ha utilizado tráfico
auto-similar cuyos resultados se muestran en la
Figura 8. La carga auto-similar se ha generado por la
agregación de fuentes de ON/OFF. Las fuentes de
ON/OFF concatenan períodos de inyección de tráfico
con periodos de inactividad, ambos con distribución
Pareto. En nuestro simulador cada nodo actúa como
una fuente ON/OFF. Para cada enlace de la red, el
tráfico generado por cada nodo se combina de acuerdo
con la distribución de destinos y el algoritmo de
186 Redes y Comunicación
encaminamiento, produciendo un tráfico auto-similar.
Hemos verificado la autosimilitud del tráfico mediante
la herramienta Selfis [13], obteniendo en todos los
casos valores para el parámetro Hurst mayores a 0.7.
(a) Latencia con uavg=0.3 (c) Latencia con uavg=0.4 (e) Latencia con uavg=0.5
(a) Consumo de potencia con uavg=0.3 (c) Consumo de potencia con uavg=0.4 (e) Consumo de potencia con uavg=0.5
Figura 7. Resultados con uavg constante y diferentes histéresis
Inicialmente todos los enlaces de la red
están conectados. Como el tráfico inicial es
bajo, el mecanismo de ahorro de energía
comienza a desconectar enlaces. Esta
desconexión continúa hasta que cada enlace
múltiple tenga únicamente un enlace activo. En
este momento, el consumo de la red es del 25%
de su valor nominal y la latencia crece un
19%.Cuando el tráfico aumenta, el consumo de
potencia aumenta motivado por la reconexión
de enlaces que previamente habían sido
desconectados. Finalmente, todos los enlaces
vuelven a estar activos. En la primera parte del
incremento de tráfico, muchos de los enlaces
todavía continúan desconectados, sin embargo
la latencia del sistema sufre un pequeño pico
que desaparece cuando el mecanismo de ahorro
de potencia reacciona conectando enlaces
adicionales. Cuando el tráfico alcanza su valor
alto y todos los enlaces están totalmente
operativos, la latencia se estabiliza en el mismo
valor alcanzado por la red cuando no se utiliza
mecanismo de reducción de consumo de
potencia. Cuando el tráfico baja, es seguido por
un decremento en la latencia y el consumo de
potencia. Como los enlaces comienzan a
desconectarse (hasta que quede únicamente
uno activo en cada enlace múltiple) se produce
un pequeño incremento en la latencia.
Figura 8. Resultados con tasas de inyección variables
XVI Jornadas de Paralelismo, JP '2005 187
4. Conclusiones
En este trabajo se ha presentado un
mecanismo para reducir el consumo de potencia en
redes de interconexión basadas en el uso de una
topología regular y conmutadores de grado alto. El
mecanismo se puede implementar en cualquier
topología con enlaces múltiples. Está basado en
agregar enlaces en cada enlace múltiple de forma
dinámica conectando y desconectándolos en fun-
ción del tráfico presente en la red. El compor-
tamiento del mecanismo depende de la elección de
dos umbrales. Se han identificado las restricciones
de diseño que se deben aplicar para la elección de
los umbrales, mientras se analiza la relación entre
estos parámetros y el comportamiento de la red en
términos de latencia y de consumo de potencia.
El mecanismo se ha evaluado para un toro 2-D de
1024 nodos. Se ha mostrado que con una elección
cuidadosa de los umbrales, el sistema puede
sintonizarse para conseguir diferentes niveles de
ahorro de potencia con un moderado incremento en
la latencia. Una contribución importante en la
estrategia propuesta es que el incremento en la
latencia se compensa con el ahorro en la potencia
consumida, ya que el producto de latencia relativa
y potencia relativa siempre se mantiene por debajo
de la unidad.
Referencias
[1] Advanced Switching Interconnect SIG home
page. http://www.asi-sig.org/home.
[2] Brocade home page. http://www.brocade.com.
[3] IEEE P802.3ad Link Aggregation Task Force
home page. http://www.ieee802.org/3/ad/.
[4] ]Mellanox home page.
http://www.mellanox.com.
[5] Myricom Inc. home page.
http://www.myricom.com.
[6] Quadrics home page. http://www.quadrics.com.
[7] M. Alonso, J.-M. Martínez, V. Santonja, and P.
López. Reducing Power Consumption in
Interconnection Networks by Dynamically
Adjusting Link Width. In Lecture Notes in
Computer Science, volume 3149, pages 882–
890, Springer- Verlag, 2004.
[8] N. J. Boden, D. Cohen, R. E. Felderman, A. E.
Kulawick, C. L. Seitz, J. N. Seizovic, and W.-K.
Su. Myrinet: A Gigabit-per-Second Local Area
Network. IEEE Micro, 15(1):29–36, January
1995.
[9] D. Cassiday. Infiniband architecture tutorial. Hot
Chips 12 Tutorial, August 2000.
[10] X. Chen, L.-S. Peh, G.-Y. Wei, Y.-K. Huang,
and P. Prucnal. Exploring the Design Space of
Power-Aware Opto- Electronic Network
Systems. In Proceedings of the 11th
InternationalSymposium on High-Performance
Computer Architecture, San Francisco, CA,
February 2005.
[11] J. Duato. A New Theory of Deadlock-Free
Adaptive Routing in Wormhole Networks.
IEEE Transactions on Parallel and Distributed
Systems, 4(12):1320–1331, December 1993.
[12] J. Duato and P. López. Performance Evaluation
of Adaptive Routing Algorithms for k-ary n-
cubes. In K. Bolding and L. Snyder, editors,
Parallel Computer Routing and Communication
Workshop, volume 853 of LNCS, pages 45–59,
Seattle, Washington, USA, May 1994.
[13] T. Karagiannis and M. Faloutsos. SELFIS: A
Tool For Self-Similarity and Long-Range
Dependence Analysis. In 1st Workshop on
Fractals and Self-Similarity in Data Mining
:Issues and Approaches, Edmonton, Canada,
July 2002.
[14] J. Kim and M. A. Horowitz. Adaptive Supply
Serial Links with sub-1V Operation and Per-pin
Clock Recovery. IEEE Journal of Solid State
Circuits, pages 1403–1413, November 2002.
[15] F. Petrini,W. chun Feng, A. Hoisie, S. Coll, and
E. Frachtenberg. The Quadrics Network: High
Performance Clustering Technology. IEEE
Micro, 22(1):46–57, January-February 2002.
[16] L. Shang, L.-S. Peh, and N. K. Jha. Dynamic
Voltage Scaling with Links for Power
Optimization of Interconnection Networks. In
Proceedings of the 9th International Symposium
on High-Performance Computer Architecture
(HPCA), Anaheim, CA, January 2003.
[17] V. Soteriou and L.-S. Peh. Dynamic Power
Management for Power Optimization of
Interconnection Networks Using On/Off Links.
In Hot Interconnects 11, Stanford University,
Palo Alto CA, August 2003.
[18] H.-S. Wang, L.-S. Peh, and S. Malik. A Power
Model for Routers: Modeling Alpha 21364 and
Infiniband Routers. IEEE Micro, pages 26–34,
January-February 2003.
188 Redes y Comunicación
MVCM: A Packet Marking/Validation Mechanism for
Congestion Management in InfiniBand
Joan-Lluís Ferrer
juaferpe@doctor.upv.es
Elvira Baydal, Antonio Robles, Pedro López, José Duato
Dept. Informática de Sistemas y Computadores
Univ. Politécnica de Valencia
46071 Valencia
{elvira,arobles,plopez,jduato}@disca.upv.es
Abstract
InfiniBand is a switch-based network technology
with point-to-point links and buffered credit-based
flow control. Often, the persistence of a high
utilization degree of some links may lead to
congestion. This congestion can spread along the
network blocking upstream switches and causing
the degradation of the overall network
performance. Therefore, a congestion
management strategy should be used. However,
InfiniBand specs do not establish any specific
support for congestion management. Until now,
only one mechanism based on marking packets in
transit has been proposed and evaluated to detect
and manage congestion in InfiniBand. However,
this solution does not guarantee that marking
actions are only carried out on those packet flows
causing congestion.
In this paper, we propose a hybrid mechanism,
namely MVCM (Marking and Validating
Congestion Management), that combines a
marking packet technique in the input buffers and
its corresponding validation in the output buffers
belonging to the highly utilized links. This
mechanism tries to distinguish "hot flows"
(responsible for the congestion), from "cold
flows" (not causing congestion but can be affected
by it). So, corrective actions should be applied on
the “hot flows” minimizing the penalization of
“cold flows” performance. Preliminary results
show that the proposed congestion management
strategy is able to avoid the degradation of
network performance. Furthermore, it allows a
quick recovery when congestion disappears.
1. Motivation
Over the last years, processing systems have
experimented a dramatically growth due to the
necessities of the new communication-intensive
applications and the increasingly demand of new
services by the users. Fortunately, the existence of
high performance network technologies, like
InfiniBand [1], allows us to tackle the
requirements derived from this new scenario.
InfiniBand technology uses a credit-based
flow control over the links. According to it, packet
advance is allowed only if enough space (credits)
exists in the input buffer of the next switch. A
serious problem that can arise in this environment
is congestion. Congestion occurs when one or
more links keep saturated during long time. An
output link becomes saturated when it is
demanded by several packets coming
simultaneously from different input links during a
certain period of time. As a consequence of the
backpressure action performed by the flow control
mechanism, packet advance is delayed, causing
input buffers to fill up and eventually stopping the
advance of the packets. This situation can spread
along the network in a saturation tree way
blocking upstream switches and causing the
degradation of the overall network performance.
So, it is necessary to detect soon the beginning of
congestion situations, as well as the nodes
responsible for that, proceeding to apply
corrective actions over them (v.g., a reduction of
injection rate) to avoid that the network reaches a
progressive degradation in its performance.
Congestion management mechanisms can
tackle the congestion problem in two different
ways, that is, either by prevention or by detection
and recovery strategies. The best strategy would
be to prevent the problem, but it is quite complex
since it is necessary to know in advance the real
needs of network resources and their priorities.
However, an early detection of the problem is
simple to implement and it works fine if thorough
detection-notification-correction strategies are
defined.
On the other hand, InfiniBand specs do not
define any specific support for implementing
congestion management strategies. However, it
does not prevent different congestion management
strategies from being applied to InfiniBand
networks, as long as they are compatible with the
specs. In particular, packet marking-based
strategies could be easily applied to InfiniBand,
taking advantage of the fact that a few bits in the
packet headers remain undefined by the specs.
Until now, only one mechanism based on
marking packets in transit has been proposed in
the literature to detect and manage congestion in
InfiniBand. However, this solution does not
guarantee that marking actions are only carried
out on those packet flows causing congestion
(“hot flows”). As a consequence, correction
actions are little selective, penalizing the
throughput of those traffic flows not causing
congestion (“cold flows”).
Indeed, what it is needed is a selective packet
marking mechanism able to perform an early
detection of congestion situations and, at the same
time, allows us to measure the congestion degree
in the network.
In this paper, we take on such a challenge and
propose a cost-effective control management
strategy for InfiniBand that combines a marking
packet mechanism in the switch input buffers and
its corresponding validation in the output buffers
belonging to those links that are saturated. So,
only the packets belonging to “hot flows” will be
validated. Additionally, we propose an effective
correction mechanism of the injection rate of the
“hot flows” able to give a quick response in
accordance with the congestion degree in the
network.
The rest of the paper is structured as follows.
Section 2 shows a background of the congestion
management mechanisms proposed for SANs.
Section 3 presents, in detail, the proposed strategy
for congestion management in InfiniBand. The
simulation scenario is described in Section 4,
whereas a preliminary evaluation results are
presented in Section 5. Finally, some conclusions
are drawn.
2. Related work
Congestion management in interconnection
networks has been widely studied and it continues
to represent an important issue in the design of
interconnection networks. Some approaches are
based on the knowledge of the needs and the early
reservation of resources (v.g., control admission
protocol aimed at providing QoS). On the other
hand, other mechanisms are able to detect and to
solve the congestion at the moment it takes place,
notifying it either to all the hosts in the network
by means of broadcast or only to those causing
congestion. Depending on the implemented
mechanism, satisfactory results can be obtained
or, on the contrary, the network becomes
overloaded by control packets, degrading even
more the situation. Anyway, delay between
detection and reaction would be minimized.
Packet marking techniques allow us to design
cost-effective congestion management strategies.
Recently, they have been applied to InfiniBand.
For this purpose, one bit in the packet header is
used [6]. The marking action is carried out when
the input or output buffers are filled up over a
defined threshold value [3,4]. The decision for
which packets must be marked depends on the
applied strategy. To notify congestion situation to
the origin hosts, another bit in the header of ACK
packets is used. This type of marking is effective
but not efficient enough. This is because it is able
to detect the beginnings of a saturation tree and to
reduce its effects, but it does not guarantee that
“cold flows” can not be affected by the actions
taken to eliminate the congestion.
Other mechanisms try to solve the problem
separating temporarily the “hot flow”, which
cause the congestion, from the “cold flow” by
removing the Head-Of-Line (HOL) blocking
effect [2]. To solve that, it is necessary to
incorporate a set of additional buffers which will
harbor these packets when the mechanism detects
packets stopping the normal circulation into the
network. These packets can continue their trip
through some slow roads to their destinations, or
be reinstated again later if congestion disappears.
Although all the solutions seem effective, it is
necessary to look for simple techniques, easy to
implement and able to guarantee network
scalability.
190 Redes y Comunicación
3. Proposed strategy
In this section, we describe in detail the proposed
congestion management strategy for InfiniBand.
This strategy combines a packet
marking/validation mechanism together with
some corrective actions performed in the origin
hosts. The main goal of the packet marking
mechanism is to differentiate “hot flows” from
“cold flows”.
We define "hot flows" as flows which
generate congestion and expand the saturation tree
quickly. This congestion may be originated either
by packets destined to the same host or by packets
destined to different hosts but crossing some
common switches along their path. It is necessary
to act immediately and to take imminent actions
on these flows.
“Cold flows” are flows providing packets
toward other destinations that are not generating
congestion. However, these flows can pass near
the “hot flows” and even to share switches in
transit with them, which can give arise to new
branches of the saturation tree, spreading the
congestion quickly.
Fig. 1 shows different types of flows
meanwhile a saturation tree is in expansion
process. If the congestion is not stopped in time, it
will reach all the switches and involve all the
flows.
Figure 1. Types of flows in a network with a saturation
tree
3.1. Marking mechanism
In order to cope with congestion situations, some
approaches often mark immediately the waiting
packets in the input buffers to allow destination
host to inform about the congestion occurrence to
the origin hosts. However, notice that if we pay
attention only to the state of the input buffer,
switches could mark packets that belong to “cold
flows”. Therefore, the corrective actions in origin
hosts could penalize the "cold flows", diminishing
the overall network performance. This is the case
of the current packet marking proposals for
InfiniBand. To avoid penalizing “cold flows”, we
propose a packet marking mechanism which also
marks packets in the input buffers, but later it
must proceed to validate them in some output
buffers. Therefore, the mechanism operates in two
steps.
Firstly, packets arriving to an input buffer are
marked if the number of stored packets in the
buffer exceeds a certain threshold (possible
principle of a congestion tree). Marking is
performed by activating (=1) the Explicit
Congestion Notification Forward Bit (ECNFB) of
the incoming packets in the packet header. To this
end, we can use any of the header bits reserved by
the specs for vendor applications.
Secondly, when a marked packet is forwarded
through a saturated output link (maybe belonging
to a different switch from that in which it was
marked), we proceed to validate it by activating
(=1) a second bit in the packet header, namely
Validation Bit (VB). We assume that an output
link is saturated when the number of packets
stored in its buffer (output buffer) exceeds certain
threshold.
Fig. 2 shows the packet marking/validation
process in a switch with saturated input and output
buffers. Notice that it is not able to validate
(VB=1) a packet that has not been previously
marked (ECNFB=0). Moreover, marked packets
will never be unmarked. The same occurs with
validated packets.
Figure 2. Packet Marking in a switch
XVI Jornadas de Paralelismo, JP '2005 191
Once congestion has been detected by
identifying the existence of some “hot flows” in
the network, we must notify it to the origin host of
the flow to apply some corrective actions. For this
purpose, we take advantage of the ACK control
packets defined by the InfiniBand specs. In the
destination host, an ACK packet is sent back to
the origin host with its ECNFB and VB bits
activated with the same values as those of the
corresponding received data packet. In this way,
the origin host can identify the flows on which it
should apply corrective actions. Notice that this
notification mechanism does not overload the
network with additional control traffic, because it
only makes use of the ACK control packets used
by InfiniBand in reliable communications.
3.2. Corrective actions
To control the congestion, we propose two levels
of corrective actions in the hosts. The first level is
based on adjusting the packet injection rate by a
sliding window. This technique is already used
with success in other network protocols like TCP
[5]. It is based on the idea of limiting, for each
flow, the number of outstanding packets through
the network. The second level will reduce even
more the injection rate. It consists of introducing
waiting periods in the injection of those flows
responsible for the congestion.
ECNFB VB Actions
0 0 No actions
1 0 No actions now. Possible
moderate actions in the future
1 1 Imminent corrective actions
Table 1. Possible corrective actions
Table 1 shows the defined corrective actions
according to the values of the received marking
bits on ACK packets. By now, we only define
"imminent actions" on the flows with marked and
validated packets. For other possibilities, we take
no action at the moment. In future studies we will
analyze the convenience of taking moderate
actions (preventive actions) when the packet is
marked but not validated (ECNFB=1 and VB=0).
In what follows, we describe each of the stages
comprised in the proposed correction mechanism,
as can be observed in Fig. 3.
x Window size limitation:
For SANs, there are proposals with sliding
window fixed to 1 [4]. This solution is valid to
palliate the congestion in a general scenario.
However, it may strongly restrict network
throughput (this would be the case when a host
transmits to a single destination host). Therefore,
it is necessary to identify the optimum window
size for the network. For this, let us assume a
scenario with a uniform traffic distribution and an
injection rate near the network saturation. Initial
value of the window size is established according
to the round-trip delay of the packets. In our
scenario, the initial value of the window size is 3.
Once congestion is detected, window will be
progressively decreased until it reaches a value of
1. Reduction actions in the window size are
carried out per each validated ACK packet
received at destination. In the same way, if the
window size is lower than the initial value, each
ACK packet non-validated (VB=0) will cause an
action of increasing in the window size,
independently of the value of its ECNFB bit, as
shown in Fig. 3 (stage A). Therefore, our
mechanism takes actions immediately against
serious situations that could cause congestion in
the network, but if the contention takes place only
during a brief interval of time (few ACK packets
are received), the recovery is also immediate.
x Injection rate control:
If the reduction in the window size is not enough
to stop the growing of the saturation tree, it is
applied a second level of corrective actions
intended to reduce even more the injection rate of
the flows responsible for the congestion. This
second level starts when the window size becomes
1 and has two phases: a first phase of transition
and a second phase in which injection rate is
modified. The first phase (stage B in Fig. 3)
requires a counter which initial value is n. The
counter is decremented by one, each time that an
ACK packet with VB=1 arrives and incremented
otherwise. We remain in this phase while the
counter value is comprised between certain
threshold value n and zero. n is usually very small
due to our self-tuned mechanism. If the counter
value reaches the established threshold (zero), we
192 Redes y Comunicación
enter the second phase. On the contrary, if the
counter value reaches (n), we return to the first
level increasing the window size.
During the second phase (stage C in Fig. 3),
we decrement the packet injection rate. Reduction
is obtained by adding waiting periods between the
injection of two consecutive packets. The waiting
periods are calculated starting from the function
(1).
(1)
The value for tmin, can be based on the round-
trip delay of the packets. Initially, Rate starts with
a value of Rate=1 for each origin-destination pair
of hosts, and it is decreased per each validated
ACK packet received, until a minimum value
(estimated in Rate=0.001) is reached. This
reduction will take place dividing successively its
value by two (reduced by 50%). In this period, our
mechanism stops the expansion of the congestion
quickly.
Figure 3. Mechanism for rate and window reduction
Whenever the congestion ceases and non-
validated ACK packets arrive, mechanism reacts
increasing the value of Rate immediately, thus
diminishing the waiting periods. It is necessary to
recover the injection rate quickly, so not
penalizing network throughput. From the possible
algorithms, we have used one with a quick
recovery, multiplying the Rate by 1.5 (increased
by 50%).
In all the stages, the window size or Rate
reductions are carried out per each validated
ACK. The increment of each parameter is also
carried out per each non-validated ACK. These
phases have been defined to try that our
mechanism does not penalize the network
performance in a non congestion situation.
4. Performance evaluation
The proposed mechanism has been evaluated in an
InfiniBand simulator of general purpose,
assuming certain network configuration such as it
is specified below.
InfiniBand is a switch-based network
technology with point-to-point links and buffered
credit-based flow control. Links in InfiniBand are
serial. At the moment it has three different band-
widths. The band-width (1x) corresponds to an
only connection of 2.5 Gbps. Other allowed band-
widths are 10 Gbps (4x) and 30 Gbps (12x).
Packets are routed at each switch by accessing the
forwarding table, that contains the output port to
be used at the switch for each possible destination.
The IBA specification defines a credit-based flow
control scheme for each virtual lane with
independent buffer resources. A packet will be
transmitted over the link if there is enough buffer
space (measured in credits of 64 bytes) to store the
entire packet. IBA allows the definition of
different MTU values for packets, ranging from
256 to 4096 bytes.
With these specs, the following network
configuration has been selected:
x A multistage interconnection network (Butterfly
2-ary 6-fly) composed by 64 hosts connected by
192 4-port switches distributed in 6 stages.
x Packets have a payload of 256 Bytes. Hence:
Data packets, 256B+(LRH+BTH+LMT) = 278B
ACK packets, 0B+(LRH+BTH+LMT) = 22B
Counter = 0
W > 1
Rate = 1
W = 1
Rate = 1
W = 1
Rate = 1
W = 1
Rate = 0.001
W-1 W+1
Rate / 2 Rate * 1.5
(Validated ACK) (Non validated ACK)
(Non validated ACK)
A
B
C
Counter = n
Counter + 1
(Non validated ACK)
Counter - 1
(Validated ACK)
(Validated ACK)
XVI Jornadas de Paralelismo, JP '2005 193
x Switches have buffers associated both at their
input and output ports. The size of these buffers
is equal to 1KB, thus allowing the storage of 3
complete data packets plus some ACK packets.
x A Full Virtual Output Queuing (VOQ) is used at
source hosts. Thus, we eliminate the appearance
of HOL blocking at sources.
x A deterministic routing algorithm is used in the
network.
x Traffic load and message destination
distribution are shown in Table 2. Traffic
pattern is similar to that used in [2].
Src. Dest. Injec.
rate
Sart
traffic
End
traffic
Packets
48 Unif 100% Start
simul.
End
simul.
884,000
16 31 100% After
48,000
received
packets
After 1,000
individual
injected
packets
16,000
Table 2. Traffic Load and distribution
We first generate packets according to a
uniform distribution of message destinations.
Then, we create a hot-spot in the network and
analyze what happens with “cold” and “hot”
flows. In particular, 48 hosts inject traffic to
randomly selected destinations during the whole
simulation. The 16 remaining hosts, remain
inactive until the first 48,000 packets have been
received (48 hosts * 1,000 packets each one).
Then, they start injecting 1,000 messages each one
with the same injection rate that the 48 previous,
but to only one destination, host 31. They stop
injection packets when 1,000 messages have been
injected. This scenario has been simulated with
different injection rates: low, intermediate and
high rate (0.45, 0.95 and 1.6 bytes/cycle/switch).
However, due to space limitations, we only show
the results for the scenario with the high injection
rate.
5. Evaluation and preliminary results
Figs. 4 to 8 show the preliminary results of the
study. First of all, we will analyze the influence of
the sliding-window size on the network
throughput. In Fig. 4, results of different static
sliding-window sizes (1,3,5,’) without applying
any congestion management mechanism (curves
“no C.M.”) are compared with the performance of
the MVCM congestion management mechanism
(curve "C.M."). In the five cases, traffic load is the
one shown in Table 2. Moreover, results obtained
with a plain uniform traffic pattern are also
shown (curve “Uniform”) for comparison
purpose. As you can see network performance
substantially improves when MVCM is applied.
Both throughput and latency get better. Moreover,
MVCM does not penalize network performance at
all. Indeed, results with MVCM when a uniform
traffic pattern is applied (not shown) are similar to
the ones of the curve “Uniform”. Notice that the
initial window size used in the MVCM
mechanism is tuned using the uniform traffic
pattern and a injection rate near to the saturation
point. Because of that, the initial sliding-window
size is big enough to work with the uniform traffic
pattern without penalizing it. After starting with
this value, the MVCM mechanism self-tunes to
the proper window size.
Figure 4. Network performance
Figs. 5 and 6 present the performance of
“cold” and “hot” flows, without any control
mechanism and with the MVCM, respectively.
These results are obtained with an injection rate of
1.6 bytes/cycle/switch. Graphs are comparable per
pairs and types of flow. A significant reduction of
the latency is appreciated for the “cold flows”
(maximum values about 1.4x106
without
congestion management and about 18,000 cycles
with MVCM) and “cold+hot flows”, (maximum
values about 1.4x106
without congestion
management, and about 120,000 cycles with
MVCM).
194 Redes y Comunicación
Figure 5. Network performance with no C.M.
Figure 6. Network performance with C.M. mechanism
Figure 7. Network throughput with no C.M.
Figure 8. Network throughput with C.M. mechanism
XVI Jornadas de Paralelismo, JP '2005 195
For the “hot flows”, although average values
of latency get worse, packets arrive faster to their
destination when congestion management
mechanism is applied. For instance, compare the
results shown in Fig. 6-c, in the time 6x106
cycles,
where packets causing congestion have arrived to
their destination, with the same point in Fig 5-c.
We can confirm that there are still more than
2,000 packets belonging to “hot flows” pending to
reach their destinations, the majority of them
waiting at origins.
Figs. 7 and 8 represent the network throughput
along the whole simulation also with a injection
rate of 1.6 bytes/cycle/switch. When congestion
management is not applied on the “hot flows”,
“cold flows” (Fig. 7-b) are clearly penalized, but
when using MVCM, “cold flows” are not affected
by the hot-spot (Fig. 8-b).
6. Conclusions
In this paper, we have proposed a new mechanism
for congestion management in InfiniBand. This
mechanism uses the ACK packets to inform which
hosts are causing congestion and to take corrective
actions directly on them. Our mechanism bases its
actions on three basic points: an early detection of
the congestion produced by the "hot flows" of the
network, a packet marking in the input buffers and
their corresponding validation in the output
buffers and an answer in origin that by means of
adjusting the size of the sending window and
inserting waiting periods, reduces the injection
rate of the hosts responsible for the congestion.
By using this mechanism, packets belonging
to "hot flows" wait at their source hosts, instead of
remaining blocked in the network, avoiding HOL
blocking and therefore not penalizing to the "cold
flows". The mechanism is also able to improve
network performance when there is not congestion
in the network.
References
[1] http://www.infinibandta.org
[2] J.Duato, I.Johnson, J.Flich, F.Naven, P.Garcia
and T.Nachiondo, “A New Scalable and Cost-
Effective Congestion Management Strategy
for Loosless Multistage Interconnection
Networks”, in Proc. 11th Int’lSymposium
HPCA-2005, 2005.
[3] J.Renato, Y.Turner and G.Janakiraman,
“Evaluation of Congestion Detection
Mechaninms for InfiniBand Switches”, IEEE
GLOBECOM, 2002.
[4] J.Renato, Y.Turner and G.Janakiraman, “End-
to-End Congestion Control for InfiniBand”,
IEEE INFOCOM 2003.
[5] V.Jacobson, “Congestion Avoindance and
Control”, Proc. ACM SIGCOMM’88
Conf1988.
[6] Y.Turner, J.Renato and G.Janakiraman, “An
Approach For Congestion Control In
InfiniBand”, HPL-2001-277, May 2002.
196 Redes y Comunicación
Efficient collective communication in the Quadrics network∗
Salvador Coll Francisco J. Mora José Duato
Dept. de Ingeniería Electrónica Dept. de Informática de Sistemas y Computadores
Universidad Politécnica de Valencia
46022 Valencia
scoll@eln.upv.es fjmora@eln.upv.es jduato@gap.upv.es
Abstract
This paper presents and experimentally evaluates
an algorithm for implementing optimal hardware-
based multicast trees, on networks that provide
hardware support for collective communication.
Although the proposed methodology can be gen-
eralized to a wide class of networks, we apply our
methodology to the Quadrics network, a state-of-
the-art network that provides hardware-based mul-
ticast communication. The proposed mechanism
is intended to improve the performance of the col-
lective communication patterns on the network, in
those cases where the hardware support can not
be directly used, for instance, due to some faulty
nodes. This scheme provides significant reduction
on multicast latencies compared to the original sys-
tem primitives, which use multicast trees based on
unicast communication. Our experiments show that
the proposed multicast mechanism doubles barrier
synchronization and broadcasts performance when
compared to the production-level MPI library.
1 Introduction
High-performance and scalable collective commu-
nication is an important factor to achieve good per-
formance and improve resource utilization of a par-
allel computer. On the one hand, this becomes par-
ticularly important if it is considered that scientific
codes spend a considerable part of their run time,
in some cases up to 70%, executing collective com-
munication [9]. On the other hand, resource man-
agement greatly conditions the efficient utilization
∗
The work was supported by the Spanish CICYT through con-
tract TIC2000-1151-C07-05
of a parallel machine. In [5] it is shown that, us-
ing an optimized implementation of a small set of
mechanisms, typical resource management opera-
tions can be significantly improved (i.e. schedul-
ing two orders of magnitude faster than the best
previously reported results). Those mechanisms,
which are soon to be common in modern high-
performance interconnects, rely on a number of
hardware features provided by the underlying net-
work. Among them, high-performance hardware-
based collective communication primitives have
been proven to be particularly important [5].
The Quadrics interconnection network (QsNET)
[7], is being used by some of the most powerful
computers in the world (two among the top 10 in
the Top500 list1
). As shown in [8], although the
QsNET shows an outstanding collective communi-
cation performance, it is limited to the case where
the destination nodes are consecutive. A single gap
in the destination nodes for a collective commu-
nication, i.e. due to a single faulty node or to a
job scheduling decision, makes the hardware sup-
port for collective communication completely un-
usable. A unicast-based multicast is used instead,
with a significant performance penalty (two times
slower barrier, and eight times slower broadcast on
a 32-node cluster [2]). This effect increases with
the network size, since the hardware mechanisms
provide very good scalability while the software-
based primitives show a logarithmic performance
degradation.
The above limitation becomes particularly rel-
evant if we consider that clusters of workstations
with thousands of nodes are becoming increasingly
popular as high-performance computing platforms.
1
http://www.top500.org/list/2004/11/
Those systems, with so many components, have a
MTBF which is proportionally reduced as the num-
ber of components increases. As an example, in [6]
it is shown that fault-tolerance becomes a key factor
in systems such as BlueGene/L, with 64K proces-
sors.
The above scenario shows, on the one hand, that
high-performance and scalable collective commu-
nication support is becoming increasingly impor-
tant in the high-performance computing arena. On
the other hand, the network performance must not
degrade drastically when the nodes allocated to a
job are not consecutive; i.e. due to the presence
of faults or when the machine is fragmented after
having been allocated to multiple parallel jobs.
In order to overcome these constraints, a new
multicast mechanism, which is intended to enhance
multicast transmissions in those cases where the
hardware support is not directly usable, is presented
in this paper. This technique uses a multicast tree
to distribute the data among all the destinations, but
with the particular feature that each message is a
hardware multicast. On the other hand, it is shown
that our strategy is likely to provide performance
figures very close to those provided by the original
hardware mechanisms, significantly outperforming
the behavior of the unicast-based multicast when
the number of destinations is high.
The rest of the paper is organized as follows.
Section 2 describes the network support for col-
lective communication. Section 3 presents the
hardware-based multicast trees developed by us
and Section 4 briefly describes two algorithm im-
plementations to obtain multicast trees. Section
5 discusses the experimental results and provides
insight onto several aspects of the proposed algo-
rithms. Finally, in Section 6 some conclusions are
drawn and future directions are given.
2 Collective communication in the
Quadrics network
The Quadrics network is a butterfly bidirectional
multistage interconnection network based on 4 x 4
switches (called Elite), which can be viewed as a
quaternary fat-tree. A quaternary fat-tree belongs
to the more general class of the k -ary n -trees [10].
It uses wormhole switching, with two virtual chan-
nels per physical link, source-based routing, and
adaptive routing. Some of the most important as-
pects of this network are: the integration of the lo-
cal memory (either in the NIC or in the host) into
a distributed virtual shared memory, the support for
zero-copy remote DMA transactions and the hard-
ware support for collective communication.
The hardware multicast capability of the network
allows packets to be sent to multiple destinations.
The Elite switches can forward a packet to sev-
eral output ports, with the only restriction that these
ports must be contiguous. In this way, a group of
adjacent nodes can be reached by using a single
hardware multicast transaction.
The routing phases for multicast packets dif-
fer from those defined for unicast packets. With
multicast, during the ascending phase the nearest
common ancestor switch for the source node and
the destination group is reached. After that, the
turnaround routing step is performed and, during
the second routing phase, the packet spans the ap-
propriate links to reach all the destination nodes.
A situation where multiple multicast packets
proceed in parallel may lead to deadlock [4].
For this reason, in order to guarantee deadlock-
freedom, several limitations apply to the routing of
multicast packets. These restrictions are based on
the concept of Broadcast Tree and Root Switch:
Definition 1 A Broadcast Tree, in a fat-tree net-
work topology, is composed of the links and
switches that provide a descending path between
the top leftmost switch in the network and all the
nodes. It can also be defined as the links and
switches that provide an ascending path between
all the nodes and the top leftmost switch.
Figure 1(a) shows the default broadcast tree for a
16-node network (dashed lines).
Definition 2 A Root Switch for any given group of
nodes refers to the nearest common ancestor switch
which belongs to the broadcast tree for that group
of nodes.
Figure 1(c) shows the root switch (filled) for the
groups highlighted in gray and black.
The Elite switches serialize incoming multicast
packets if there is some overlap among the re-
quested output ports, otherwise they can proceed in
parallel. When sending a multicast packet, the root
switch is used to perform the turnaround routing.
198 Redes y Comunicación
Thus, at this point, the packet starts to be replicated
to several output ports. In the QsNET, a multicast
packet can only take paths included in the broadcast
tree. According to this, only switches that are in-
cluded in the broadcast tree are allowed to be used
as root switches by the system routing tables and
the switches configuration. In this way, simultane-
ous multicasts are serialized through the root switch
and, therefore, deadlocks are avoided.
A communication example which involves two
multicast groups is presented in Figure 1 (b). The
gray and black nodes represent two groups with a
partial overlap of destinations, the leftmost node
in each group being the source. Let’s assume that
both sources send a packet to its group, and both
packets arrive to the root switch (second stage left-
most switch) at the same time with the same pri-
ority. As there is overlap on the requested output
ports, the switch arbiter only allows one packet to
proceed (black packet, Figure 1(c)), while the other
one is blocked until its resources are available (gray
packet, Figure 1(d)).
(a) Broadcast tree (b) Two multicast
communication
groups
(c) Serialization
through the root
switch
(d) Final transaction
Figure 1: Hardware Multicast
For a multicast packet to be successfully deliv-
ered, a positive acknowledgement must be received
from all the recipients of the multicast group. The
Elite switches combine all the acknowledgements
into a single token, returning a positive ack only
when all the partners in the collective communica-
tion complete the distributed transaction with suc-
cess.
3 Hardware-based multicast trees
As stated in Section 2, the Quadrics network hard-
ware support for collective communication can
only be used when all the destination nodes are con-
tiguous. Otherwise, a software-based multicast al-
gorithm based on a balanced tree is used [8]. This
approach provides significantly lower performance
than the hardware-based multicast since it is based
on point-to-point messages.
In order to overcome the hardware multicast lim-
itations and provide high-performance collective
communication, a hardware-based multicast tree
technique has been presented in [3]. This technique
uses a multicast tree to distribute the data among
all the destinations, but with the particular issue
that each message is a hardware multicast. In this
way, the source node sends a multicast message to
a subset of contiguous destinations, each of which
forwards the message to another subset. Eventu-
ally, all destinations will receive the message. A
key factor to achieve the best possible performance
is the parallel transmission of as many multicast
transactions as possible, once a subgroup of adja-
cent destinations has received a copy of the mes-
sage. It is worth noting that, for the correct oper-
ation of this mechanism, deadlock-freedom has to
be guaranteed. This mechanism is likely to pro-
vide significant performance improvements when
the number of destinations is high and there are a
few gaps in the group allocation (e.g., due to some
faulty nodes).
Figure 2 shows an example comparing the be-
havior of the original software-based tree (Figure
2(a)), used by the Quadrics system software, and
the proposed hardware-based tree (Figure 2(b)).
The example considers a multicast group composed
of 13 non-adjacent nodes. In the software tree, once
each node receives the message from its parent, it
forwards one copy to each one of its children. In
XVI Jornadas de Paralelismo, JP '2005 199
the hardware tree, the source node sends a hard-
ware multicast to one subgroup of adjacent nodes
and, after that, each node in the subgroup forwards
the message to another subgroup. The sequence
of multicast steps for the hardware-based tree is
shown in Figure 3. Figure 3(a) shows the first step
and Figure 3(b) shows the second step. As can be
seen, the hardware tree provides, in general, lower
tree depth and thus lower latency. Nevertheless, the
performance of the hardware-based tree relies on
the possibility of parallelizing the hardware multi-
casts that are to be sent during the same tree step.
In order for several hardware multicast mes-
sages, with different sources, to proceed in paral-
lel without collisions among them, several routing
restrictions have to be taken into account:
• All multicast messages must follow the broad-
cast tree once the replication to several output
ports at some switch starts. In other words,
the root switch for any given multicast subset
must belong to the multicast tree. In this way
deadlocks are avoided. The root switches used
during the two multicast steps of the described
example are highlighted in Figure 3.
• Given two multicast operations with different
sources and destinations, they can proceed in
parallel (that is, with no serialization at any
switch or link) only if they do not share any
link. That is the case for the three parallel
hardware-based multicasts shown on Figure
3(b).
2
0
6
9
7
8 11
12
13
4
3
14
15
0
11 13 14 15
6 7
12
8 9 2 3 4
(a) (b)
time
Figure 2: (a) Software- and (b) hardware-based multicast
trees.
0 1 2 3 4 5 6 7 8 9 10 11 12 14 15
13
(a)
0 1 2 3 4 5 6 7 8 9 10 11 12 14 15
13
(b)
Figure 3: Hardware-based multicast tree: (a) first step; (b)
second step.
4 Hardware-based multicast tree algo-
rithm
Obtaining the optimal (minimum depth) hardware-
based multicast tree for any given problem is not
a simple task. There is no rule to select the set of
destination nodes, to be reached at each tree step,
that guarantees an optimal solution. For this rea-
son, two different algorithms have been developed:
a backtracking algorithm and a greedy algorithm.
The backtracking approach explores all the solu-
tions for any given problem in order to find the op-
timal one. The computational cost of such an al-
gorithm is exponential, and thus impractical for a
real implementation. On the other hand, the greedy
approach applies some heuristics to find a good so-
lution, but does not guarantee that the optimal tree
will be found. Nevertheless, the number of itera-
tions of the greedy algorithm is proportional to the
tree depth, leading to a practical implementation
with an extremely low computational cost.
As it has been described in Section 3, a
hardware-based multicast tree step consists, in gen-
eral, of a set of parallel hardware multicasts sent
by a number of nodes to disjoint sets of contiguous
destinations. After the necessary number of steps,
all the destinations will be reached. An optimal
tree, in terms of latency, has the minimum number
of steps, as shown in [1].
For an optimal solution to be found, all the alter-
native multicast trees should be explored. That is,
at each tree step, all the alternative destination sets
of contiguous nodes, reachable in parallel by the
nodes that have a copy of the message during that
200 Redes y Comunicación
1%
2%
3%
4%
5%
6%
7%
8%
9%
10%
16 64 128 256 512 1024 2048 4096
Nodes
4 steps
3 steps
2 steps
Figure 4: Maximum steps required by a hardware-based
multicast tree.
step, have to be checked. And from those destina-
tions, all the combinations of destinations that can
be reached during the next step, and so on. This
approach has an intrinsically exponential cost. A
preliminary analysis of the problem indicates that
there is no algorithm (or rule) that makes it pos-
sible to find, in general, an optimal multicast tree
with logarithmic cost, that is, proportional to the
tree depth. For this reason, two different algorithms
have been developed:
• a backtracking algorithm, that explores all the
solutions, providing an optimal solution to the
problem. This algorithm is optimized by stop-
ping and backtracking as soon as the current
partial solution cannot improve the best solu-
tion already found.
• a greedy algorithm, that takes a decision at
each tree step, providing an optimal or near-
optimal solution with small computational
cost. This algorithm uses an heuristic to se-
lect the appropriate sequence of groups to be
reached during each step of the multicast tree.
The computational cost of the greedy algorithm
is proportional to the multicast tree depth, and thus
to the logarithm of the number of groups of adja-
cent destination nodes. This provides an approach
that can be implemented in practice with low com-
putational cost, with the limitation that finding the
optimal solution is not guaranteed.
5 Results
As first step, the developed greedy algorithm has
been tested in order to verify the optimal solution
matching ratio. This has been done by comparing
the solutions the greedy algorithm obtains with the
optimal solution found using the backtracking al-
gorithm. Tests have been conducted on configura-
tions ranging from 16 to 4096-node networks, with
faulty node percentages ranging from 0.1% to 10%.
One thousand random faulty node mappings were
generated for each configuration. Our tests show
that the greedy algorithm finds an optimal solution
for 99% of the cases. This percentage increases as
the amount of faulty nodes decreases, being 100%
when less than 1% of the nodes are faulty. A sum-
mary of the results is shown on Figure 4. Each col-
ored area covers the configurations where the worst
case tree depth (2, 3 or 4) is the same. It has to be
mentioned that, as Figure 4 shows worst case val-
ues, the closer a given configuration is to its left
area limit, the higher the probabilities for that con-
figuration to be solved in one step less.
Detailed results of multicast trees on large-scale
QsNET clusters are shown in Table 1. These tests
have been designed to analyze the greedy algorithm
performance when a fraction of the nodes is not
operational. Networks with 1024, 2048 and 4096
nodes have been simulated. The number of nodes
not taking part in the multicast transaction has been
varied from 0.2% to 1% in 0.2% intervals. One
thousand random problems for each particular con-
figuration have been solved using the algorithms
presented in this report. The number of steps for the
optimal trees are summarized in the table, where
the notation x/y denotes a x-step tree with prob-
ability y. The results show that any practical sit-
uation, with a realistic amount of faulty nodes, is
likely to be solved using a hardware-based multi-
cast tree with only 2 steps. Only the largest config-
uration tested, 4096 nodes, will require 3 steps for
42% of the cases when 1% of the nodes are faulty.
On the one hand, these results indicate that the
proposed greedy algorithm provides an optimal so-
lution to most of the cases. On the other hand, since
the tree depth is very short (a maximum of 4 steps
are required in the worst case for the configurations
tested) the QsNET collective communication sup-
port can be significantly improved.
XVI Jornadas de Paralelismo, JP '2005 201
Faulty Nodes
Network Size 0.2% 0.4% 0.6% 0.8% 1%
1024 2 2 2 2 2
2048 2 2 2 2 2
4096 2 2 2
2/0.998
3/0.002
2/0.582
3/0.418
Table 1: Optimal hardware-based multicast tree steps for different configurations.
3
4
5
6
7
8
9
10
11
12
13
14
0 1 2 3 4
Latency
(µs)
Faulty Nodes
Barrier Test - 16 Nodes
SW tree
HW tree
(a)
4
6
8
10
12
14
16
18
0 1 2 3 4
Latency
(µs)
Faulty Nodes
Barrier Test - 32 Nodes
SW tree
HW tree
(b)
Figure 5: Barrier synchronization latencies.
In order to measure the impact of the proposed
mechanism on the QsNET collective communica-
tion, several experiments have been conducted. The
experimental evaluation has been performed on a
32-node cluster of Dell 1550, running Red Hat 7.1
Linux. Each node has two 1.13 GHz Pentium-
III with 1GB of ECC RAM, and a Quadrics QM-
400 Elan3 NIC attached to the network through a
66MHz/64-bit PCI bus.
Figure 5 shows the average time to perform a
barrier synchronization on an empty network. The
tree construction time is not taken into account,
since it is computed once for each configuration.
Results for 16- and 32-node network configurations
are shown versus the number of faulty nodes. As
expected, the latency of the software-based barrier
used by the QsNET is insensitive to the number of
nodes not taking part in the collective communica-
tion, when this is low. This is due to the fact that a
slight reduction on the destination nodes has no ef-
fect on the multicast tree depth [2]. For a 32-node
configuration with less than four faulty nodes, the
latency is constant at approximately 17µs; while it
slightly decreases when four faulty nodes are con-
sidered (15.9µs). On the other hand, it can be seen
that the synchronization based on the hardware tree
developed by us, significantly outperforms the soft-
ware tree used by the QsNET. The latency required
to barrier synchronize with no faulty nodes is 4µs
in both configurations tested, which corresponds to
a single multicast step. The time required to barrier
synchronize the network with four faulty nodes or
less is constant at 6.5µs for 16 nodes and 7µs for 32
nodes, since only two multicast steps are required.
As can be seen, when the number of faulty nodes is
low, our methodology provides between 50% and
60% faster synchronizations, for the configurations
tested. We expect this performance gap to broaden
with larger network configurations, since, as shown
in Table 1, the scalability of our multicast mecha-
nism is very good.
Figure 6 shows the results obtained with
software-based broadcasts over a 32-node network,
and buffers globally allocated in main memory
(that is, with the same virtual address in all pro-
cesses). As it has been shown for the barrier experi-
202 Redes y Comunicación
ments, the performance of the software-based mul-
ticast is insensitive to the number of faulty nodes
when there are only a few. Only the configuration
with four faulty nodes, as can be seen from Figure
6(b), shows a slight improvement in latency. The
peak bandwidth of 40MB/s is obtained for 32KB
messages, while messages shorter than 64 bytes are
delivered in less than 22µs.
0
5
10
15
20
25
30
35
40
1 4 16 64 256 1K 4K 16K 64K 256K
Bandwidth
(MB/s)
Message Size (bytes)
Broadcast Test - 32 Nodes
SW tree
SW tree, 1 faulty node
SW tree, 2 faulty nodes
SW tree, 3 faulty nodes
SW tree, 4 faulty nodes
(a)
15
20
25
30
35
40
1 4 16 64 256 1K 4K
Latency
(µs)
Message Size (bytes)
Broadcast Test - 32 Nodes
SW tree
SW tree, 1 faulty node
SW tree, 2 faulty nodes
SW tree, 3 faulty nodes
SW tree, 4 faulty nodes
(b)
Figure 6: Software-based broadcast.
When all 32 nodes in the network take part in the
collective communication, the hardware based mul-
ticast can be directly used. In this case a peak band-
width of 306MB/s has been measured for 256KB
messages (top curve on Figure 7(a)). On the other
hand, if several faulty nodes are considered, our
hardware-based multicast tree is used. The re-
sults obtained are shown on Figure 7. As can be
seen, the performance of the multicast tree devel-
oped by us is insensitive to the number of faulty
nodes for the configurations we tested, since the
destinations can always be reached in two multicast
steps. The measured bandwidth of the hardware-
based multicast tree reaches a peak of 124MB/s for
64KB messages. For the tested message sizes, the
bandwidth provided by the hardware-based multi-
cast tree, with faulty nodes, ranges between 60%
and 40% of the bandwidth obtained with no faulty
nodes. These results show that the hardware-
based multicast tree significantly outperforms the
software-based multicast tree, providing a collec-
tive communication that is twice as fast in the worst
case.
0
50
100
150
200
250
300
350
1 4 16 64 256 1K 4K 16K 64K 256K
Bandwidth
(MB/s)
Message Size (bytes)
Broadcast Test - 32 Nodes
HW tree
HW tree, 1 faulty node
HW tree, 2 faulty nodes
HW tree, 3 faulty nodes
HW tree, 4 faulty nodes
(a)
5
10
15
20
25
30
1 4 16 64 256 1K 4K
Latency
(µs)
Message Size (bytes)
Broadcast Test - 32 Nodes
HW tree
HW tree, 1 faulty node
HW tree, 2 faulty nodes
HW tree, 3 faulty nodes
HW tree, 4 faulty nodes
(b)
Figure 7: Hardware-based broadcast.
XVI Jornadas de Paralelismo, JP '2005 203
6 Conclusions
This paper presented hardware-based multicast
trees as an alternative to overcome the limitations
of the hardware support for multicast provided by
the Quadrics network. A backtracking algorithm to
calculate minimum latency hardware-based multi-
cast trees is presented. As an alternative with lower
computational cost, and, hence, suitable to be im-
plemented in the QsNET system libraries, a greedy
algorithm has been developed.
The proposed mechanism has been applied to
solve a number of random configurations for dif-
ferent network sizes. The greedy algorithm has
been shown to find optimal solutions for the ma-
jority of the tested configurations. In addition, on
systems where a realistic number of faulty nodes
is considered, any multicast transaction can be per-
formed using a hardware-based multicast tree with
only two steps. That means that the hardware-based
multicast tree mechanism would significantly out-
perform the behavior of the software-based multi-
cast, used by the QsNET, on a large-scale network.
Results for barrier synchronization and broad-
cast, obtained on a 32-node cluster, show that
the hardware-based multicast tree mechanism sig-
nificantly outperforms the QsNET software-based
multicast (barrier latencies are reduced to a half,
while broadcast bandwidths are doubled). This ef-
fect is likely to increase as the network size in-
creases due to the poor scalability of the software-
based multicast when compared to the hardware-
based multicast tree we propose. These results
show that hardware-based multicast trees provide
a scalable and fault-tolerant alternative to software-
based multicast trees, while overcoming the limi-
tations of the hardware support for collective com-
munication.
References
[1] Salvador Coll. A Parameterized Communica-
tion Model for QsNET. Technical report, Dig-
ital Systems Design Group, Technical Univer-
sity of Valencia, February 2002.
[2] Salvador Coll, José Duato, Francisco J. Mora,
Fabrizio Petrini, and Adolfy Hoisie. Collec-
tive Communication Patterns on the Quadrics
Network. In Proceedings of the Perfor-
mance Analyisis and Grid Computing Semi-
nar, Dagstuhl, Germany, August 2002.
[3] José Duato. Improved Multicast Support for
the Quadrics Network. Technical report, Par-
allel Architectures Group, Technical Univer-
sity of Valencia, August 2001.
[4] José Duato, Sudhakar Yalamanchili, and Li-
onel Ni. Interconnection Networks: an Engi-
neering Approach. Morgan Kaufmann, Au-
gust 2002.
[5] Eitan Frachtenberg, Fabrizio Petrini, Juan
Fernandez, Scott Pakin, and Salvador Coll.
Storm: Lightning-fast resource management.
In IEEE/ACM SC2001, Baltimore, MD,
November 2002.
[6] Manish Gupta. Challenges in Developing
Scalable Software for BlueGene/L. In Scal-
ing to New Heights Workshop, Pittsburgh, PA,
May 2002.
[7] Fabrizio Petrini, Wu chun Feng, Adolfy
Hoisie, Salvador Coll, and Eitan Fracht-
enberg. The Quadrics network: High-
performance clustering technology. IEEE Mi-
cro, 22(1):46–57, January/February 2002.
[8] Fabrizio Petrini, Salvador Coll, Eitan Fracht-
enberg, and Adolfy Hoisie. Hardware-
and software-based collective communication
on the Quadrics network. In Proceedings
of the 2001 IEEE International Symposium
on Network Computing and Applications
(NCA 2001), Cambridge, Massachusetts, Oc-
tober 8–10, 2001.
[9] Fabrizio Petrini, Darren Kerbyson, and Scott
Pakin. The Case of the Missing Supercom-
puter Performance: Achieving Optimal Per-
formance on the 8,192 Processors of ASCI Q.
In Proceedings of SC2003, Phoenix, Arizona,
November 10–16, 2003.
[10] Fabrizio Petrini and Marco Vanneschi. Per-
formance analysis of wormhole routed k-
ary n-trees. International Journal on Foun-
dations of Computer Science, 9(2):157–177,
June 1998.
204 Redes y Comunicación
   
               !

II
# % ' % * ,
 - .
, / 1 % 2

  4  6
7
/ 1 % 9 % * ,
 - .
, 2 % #

    
; < = > ? A B C E F B E I B K L N P Q Q S U W Y > A B [ I E F \
] B ` E > [ > F L N A B Q > b < d = N A > K B g h [ F > K I = i b g k C E l > K b N = I ` g
p E I q B K g I A N A A B Y d K ` I N t > g h [ N b > g u N = I > E N [ t N w ?
W x x y z Y d K ` I N \ S { h C u t > g h [ N b > g \ u Y ~ y  €  \ p S h
 ‚ ƒ „ … † ‡ „ ˆ ‰ Š „ ‹ Œ ˆ ‰  ƒ „ … † ‡ „ Ž   ‡ ‘ ’ † “ Š  “ ’ • Œ „ – … ‡ — ‡ ˜  ™ „ ‹ ™ “ ƒ ˜ ›
œ ž Ÿ   ¡ ¢ ¤  
¥ ¦ ¨ © ª « ¬ ª ­ ¨ ­ ® ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ° ª ¸ ª ¹ µ « µ ­ µ ¨ º
¦ » ° « ¬ º ­ ¨ ½ º ¾ ¿ ¨ ± ¬ º ­ ­ ª À ¨ µ ´ ­ ¦ ª ° ° ¦ ¬ ´ ­ ´ ¦ ­
¦ ´ « Ä ­ ® ¨ µ ´ ­ ¨ ½ ° ¦ ´ ´ ¨ ° ­ µ ¦ ´ ´ ¨ ­ ¿ ¦ ½ À ¹ ¬ ­ ª « º ¦ ­ ® ¨
º Ä º ­ ¨ ± º ¦ » ­ ¿ ª ½ ¨ É Ë ´ ­ ® µ º ¸ ª ¸ ¨ ½ ¾ ¿ ¨ ¨ © ª « ¬ Ì
ª ­ ¨ ­ ® ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ° ª ¸ ª ¹ µ « µ ­ µ ¨ º ¦ » ª ° « ¬ º Ì
­ ¨ ½ ¹ ª º ¨ Î ¦ ´ Î ¬ ª « Ì Ð ¸ ­ ¨ ½ ¦ ´ Ò Ó Ô ´ ¦ Î ¨ º µ ´ ­ ¨ ½ Ì
° ¦ ´ ´ ¨ ° ­ ¨ Î ¿ µ ­ ® Ö º × ¨ ­
II É Ë ´ ¸ ª ½ ­ µ ° ¬ « ª ½ ¾ ¿ ¨
º ­ ¬ Î Ä ­ ® ¨ ½ ª ¿ ´ ¨ ­ ¿ ¦ ½ À ¸ ¨ ½ » ¦ ½ ± ª ´ ° ¨ ¾ ­ ® ¨ ª ¹ µ « Ì
µ ­ Ä ¦ » Ó Ô Ë ­ ¦ ¦ © ¨ ½ « ª ¸ ° ¦ ± ¸ ¬ ­ ª ­ µ ¦ ´ ª ´ Î ° ¦ ± Ì
± ¬ ´ µ ° ª ­ µ ¦ ´ ¾ ª ´ Î ­ ® ¨ ª ¸ ¸ ½ ¦ ¸ ½ µ ª ­ ¨ ´ ¨ º º ¦ » ­ ® ¨ « ¦ Ì
° ª « ¦ ¸ ¨ ½ ª ­ µ ´ Ú º Ä º ­ ¨ ± º ­ ¦ º ¬ ¸ ¸ ¦ ½ ­ ¸ ª ½ ª « « ¨ « ¸ ½ ¦ Ì
° ¨ º º µ ´ Ú É Û Ü ¸ ¨ ½ µ ± ¨ ´ ­ ª « ½ ¨ º ¬ « ­ º º ® ¦ ¿ ª º ­ ª ¹ « ¨
º Ä º ­ ¨ ± ¿ µ ­ ® ª ½ ¨ ª « « Ä ¨ Þ ° µ ¨ ´ ­ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´
º ¬ ¹ º Ä º ­ ¨ ± ¿ ® µ ° ® µ º ª ¹ « ¨ ­ ¦ Î ¨ « µ © ¨ ½ à á â Ó ã ä º
¬ ´ µ Î µ ½ ¨ ° ­ µ ¦ ´ ª « ¹ ª ´ Î ¿ µ Î ­ ® ¾ æ É ç
µ
º ¨ ° ¬ ´ µ Î µ ½ ¨ ° Ì
­ µ ¦ ´ ª « « ª ­ ¨ ´ ° Ä ¾ ª ´ Î ¬ ¸ ­ ¦ é é É â ê ì Ô í ª © ª µ « Ì
ª ¹ µ « µ ­ Ä ¿ ® µ « ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ µ º µ ´ ¸ ½ ¦ Ú ½ ¨ º º É
ï ð ñ
  ¡ ò ô õ ¤   ö ò
ñ
ì « ¬ º ­ ¨ ½ º ® ª © ¨ ¹ ¨ ° ¦ ± ¨ ­ ® ¨ ± ¦ º ­ º ¬ ° ° ¨ º º » ¬ «
¸ « ª Ä ¨ ½ µ ´ ­ ® ¨ ® µ Ú ® Ì ¸ ¨ ½ » ¦ ½ ± ª ´ ° ¨ ° ¦ ± ¸ ¬ ­ µ ´ Ú
ª ½ ¨ ´ ª µ ´ ­ ® ¨ « ª º ­ Î ¨ ° ª Î ¨ É ü ­ ­ ® ¨ ­ µ ± ¨ ¦ »
­ ® µ º ¿ ½ µ ­ µ ´ Ú ¾ ± ª ´ Ä ¦ » ­ ® ¨ » ª º ­ ¨ º ­ º Ä º ­ ¨ ± º µ ´
­ ® ¨ ¥ ¦ ¸ â ý ý « µ º ­ þ ÿ æ
ª ½ ¨ ° « ¬ º ­ ¨ ½ º É ¥ ® ¨ º ¨ º Ä º Ì
­ ¨ ± º ª ½ ¨ ­ Ä ¸ µ ° ª « « Ä ª º º ¨ ± ¹ « ¨ Î » ½ ¦ ± ° ¦ ± ± ¦ Î µ ­ Ä
¦  Ì ­ ® ¨ Ì º ® ¨ « »  ì Ð ¥ Ò  ° ¦ ± ¸ ¦ ´ ¨ ´ ­ º É Ë ´ ¸ ª ½ ­ µ ° Ì
¬ « ª ½ ¾ ­ ® ¨ ½ ¨ µ º ª Ú ½ ¦ ¿ µ ´ Ú µ ´ ­ ¨ ½ ¨ º ­ µ ´ ­ ® ¦ º ¨ º Ä º Ì
­ ¨ ± º ª º º ¨ ± ¹ « ¨ Î ¿ µ ­ ® Ò Ó Ô ´ ¦ Î ¨ º ¹ ª º ¨ Î ¦ ´ ç  Ì
¹ µ ­ ¸ ½ ¦ ° ¨ º º ¦ ½ º
± ª µ ´ « Ä Ë ­ ª ´ µ ¬ ± ÿ ª ´ Î Ð ¸ ­ ¨ ½ ¦ ´

µ ´ ­ ¨ ½ ° ¦ ´ ´ ¨ ° ­ ¨ Î ¿ µ ­ ® ® µ Ú ® Ì ¸ ¨ ½ » ¦ ½ ± ª ´ ° ¨ ´ ¨ ­ Ì
¿ ¦ ½ À º ¾ º ¬ ° ® ª º Ë ´  ´ µ ¹ ª ´ Î þ æ à
¾ Ó Ä ½ µ ´ ¨ ­ þ æ é

¦ ½ Ö ¬ ª Î ½ µ ° º þ ÿ ý
É
Ô ¨ ½ » ¦ ½ ± ª ´ ° ¨ ¦ » « ª ½ Ú ¨ Ì º ° ª « ¨ ° « ¬ º ­ ¨ ½ º µ º Î ¨ ­ ¨ ½ Ì
± µ ´ ¨ Î ¹ Ä ­ ® ¨ ¸
ª ½ ª « « ¨ « ¨ Þ ° µ ¨ ´ ° Ä ¦ » ­ ® ¨ ¨ ´ ­ µ ½ ¨
º Ä º ­ ¨ ± ª º ª ¿ ® ¦ « ¨ ½ ª ­ ® ¨ ½ ­ ® ª ´ ¹ Ä ­ ® ¨ ¸ ¨ ª À
¸ ¨ ½ » ¦ ½ ± ª ´ ° ¨ ¦ » µ ´ Î µ © µ Î ¬ ª « ´ ¦ Î ¨ º É Ë ´ ¦ ½ Î ¨ ½
­ ¦ ª ° ® µ ¨ © ¨ ª ® µ Ú ® Î ¨ Ú ½ ¨ ¨ ¦ » ¸ ª ½ ª « « ¨ « ¨ Þ ° µ ¨ ´ ° Ä ¾
­ ® ¨ ½ ¨ ± ¬ º ­ ¹ ¨ ª ¸ ½ ¦ ¸ ¨ ½ ¹ ª « ª ´ ° ¨ ¦ © ¨ ½ ­ ® ¨ ¨ ´ ­ µ ½ ¨
º Ä º ­ ¨ ±  ¸ ½ ¦ ° ¨ º º ¦ ½ ¾ ± ¨ ± ¦ ½ Ä º ¬ ¹ º Ä º ­ ¨ ± ¾ µ ´ ­ ¨ ½ Ì
° ¦ ´ ´ ¨ ° ­ ¾ ª ´ Î º Ä º ­ ¨ ± º ¦ » ­ ¿ ª ½ ¨ É Ë » ¿ ¨ » ¦ ° ¬ º ¦ ´
­ ® ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ° ª ¸ ª ¹ µ « µ ­ µ ¨ º ¾ ¿ ¨ ± ¬ º ­ ¸ ª Ä
ª ­ ­ ¨ ´ ­ µ ¦ ´ ´ ¦ ­ ¦ ´ « Ä ­ ¦ ­ ® ¨ µ ´ ­ ¨ ½ ° ¦ ´ ´ ¨ ° ­ µ ¦ ´ ´ ¨ ­ Ì
¿ ¦ ½ À ¹ ¬ ­ ª « º ¦ ­ ¦ ­ ® ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ º Ä º ­ ¨ ±
º ¦ » ­ ¿ ª ½ ¨ É Ë ´ ­ ® µ º ° ª º ¨ ¾ ¿ ® µ « ¨ Ó Ä ½ µ ´ ¨ ­ ¾ Ë ´  ´ µ Ì
¹ ª ´ Î ª ´ Î Ö ¬ ª Î ½ µ ° º ª ½ ¨ ­ ® ¨ ¸ ½ ¨ » ¨ ½ ½ ¨ Î ° ® ¦ µ ° ¨ º
» ¦ ½ ­ ® ¨ ° « ¬ º ­ ¨ ½ µ ´ ­ ¨ ½ ° ¦ ´ ´ ¨ ° ­ ¾ Ó Ô Ë þ æ á
µ º ­ ® ¨
      
º ­ ª ´ Î ª ½ Î ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ « µ ¹ ½ ª ½ Ä » ¦ ½
± ¨ º º ª Ú ¨ Ì ¸ ª º º µ ´ Ú ¾ ª ´ Î  µ ´ ¬ Ü µ º ­ ® ¨ ± ¦ º ­ ¸ ¦ ¸ ¬ Ì
« ª ½ ° ® ¦ µ ° ¨ » ¦ ½ ¦ ¸ ¨ ½ ª ­ µ ´ Ú ­ ® ¨ ° « ¬ º ­ ¨ ½ ´ ¦ Î ¨ º É
¥ ® ¨ ­ ½ ª Î µ ­ µ ¦ ´ ª « ª ¸ ¸ ½ ¦ ª ° ® ­ ¦ ¨ © ª « ¬ ª ­ ¨ ­ ® ¨
° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ° ª ¸ ª ¹ µ « µ ­ µ ¨ º ¦ » ª ° « ¬ º ­ ¨ ½ ¸ ½ µ Ì
± ª ½ µ « Ä ½ ¨ « µ ¨ º ¦ ´ ¹ ª ´ Î ¿ µ Î ­ ® ª ´ Î « ª ­ ¨ ´ ° Ä ­ ¨ º ­ º É
Û © ¨ ´ ­ ® ¦ ¬ Ú ® ­ ® ¨ ¹ ª ´ Î ¿ µ Î ­ ® ª ´ Î « ª ­ ¨ ´ ° Ä  Ú Ì
¬ ½ ¨ º ª ½ ¨ º µ Ú ´ µ  ° ª ´ ­ ¾ ­ ® ¨ Ä ª ½ ¨ ´ ¦ ­ ¨ ´ ¦ ¬ Ú ® ­ ¦
° ® ª ½ ª ° ­ ¨ ½ µ " ¨ ­ ® ¨ º Ä º ­ ¨ ± ¹ ¨ ® ª © µ ¦ ½ ¿ ® ¨ ´ ½ ¬ ´ Ì
´ µ ´ Ú º ° µ ¨ ´ ­ µ  ° ª ´ Î ¨ ´ Ú µ ´ ¨ ¨ ½ µ ´ Ú ª ¸ ¸ « µ ° ª ­ µ ¦ ´ º µ ´
ª ° « ¬ º ­ ¨ ½ É ¥ ® ¨ ½ ¨ ª ½ ¨ ¦ ­ ® ¨ ½ ª º ¸ ¨ ° ­ º ­ ® ª ­ ® ª © ¨
ª Ú ½ ¨ ª ­ µ ± ¸ ª ° ­ µ ´ ­ ® ¨ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ¸ ¨ ½ » ¦ ½ Ì
± ª ´ ° ¨ ª º ¿ ¨ « « É Ð ´ ­ ® ¨ ¦ ´ ¨ ® ª ´ Î ¾ ­ ® ¨ ª ¹ µ « µ ­ Ä ¦ »
­ ® ¨ Ó Ô Ë « ª Ä ¨ ½ ­ ¦ ¦ © ¨ ½ « ª ¸ ° ¦ ± ± ¬ ´ µ ° ª ­ µ ¦ ´ ª ´ Î
° ¦ ± ¸ ¬ ­ ª ­ µ ¦ ´ ± ª Ä « µ ± µ ­ ­ ® ¨ ì Ô í ª © ª µ « ª ¹ µ « µ ­ Ä
» ¦ ½ ¬ º ¨ ½ ª ¸ ¸ « µ ° ª ­ µ ¦ ´ º É ü ´ ¨ Þ ° µ ¨ ´ ­ Ó Ô Ë µ ± Ì
¸ « ¨ ± ¨ ´ ­ ª ­ µ ¦ ´ º ® ¦ ¬ « Î « ¨ © ¨ ½ ª Ú ¨ ± ¦ Î ¨ ½ ´ ´ ¨ ­ ¿ ¦ ½ À
µ ´ ­ ¨ ½ » ª ° ¨ ° ª ½ Î º ­ ¦ ¦ # ¦ ª Î ¸ ½ ¦ ­ ¦ ° ¦ « ¸ ½ ¦ ° ¨ º º µ ´ Ú É
Ð ´ ­ ® ¨ ¦ ­ ® ¨ ½ ® ª ´ Î ¾ ­ ® ¨ ° ¦ ± ± ¦ Î µ ­ Ä Ð Ò ¨ º ½ ¬ ´ Ì
´ µ ´ Ú µ ´ ¨ © ¨ ½ Ä ´ ¦ Î ¨ ± ª Ä µ ´ ­ ¨ ½ » ¨ ½ ¨ ¿ µ ­ ® ¬ º ¨ ½ Ì
« ¨ © ¨ « ¸ ½ ¦ ° ¨ º º ¨ º É ¥ ® ¨ ´ ¦ Î ¨ º ¦ » ª ° « ¬ º ­ ¨ ½ º ® ¦ ¬ « Î
                           
  ! 
"      #     #     &         "    !  / 0 2   5
   #     !   & &         & 9 ;   !  &  #    >
?  A  "  &   #  # 
  D #    !  &  # &   "  &   #
"   &    # &       #  5 /       0 G H     &   5
   "     "    ?   ! L & M  
II A    L  #    " & 9
P !    &   A  !   #     &   D #  
  # & A     ? & 9
P !    W  &  "        &    &  !   #   A  #     &  A
L & M  
II 9 ;   #    "   #  >   !  !  [  #      5
?   2      A # "  " #   #    !  [      & ?   " ! #  
  & "     9 ;  0  "      >  
        A    #  " 
# &   "  &  A # L & M  
II 5 # &   "   &    # & &     
?   ! /           & #   #  # 
  9 0  "     
   f    &   #    & ?   ! &       #    &      & 9  5
 #   > ?  "   "     ?   ! &       #  2 & #   # 
        A A      ?   2 9
 
h   i
II
L & M   A    L  #    " & ! # f   "        A  ! 
   A      " !   "  &        "     "   #  D  5 & " #  
"   &    & &   "    & #    #  #  "    n o o p q r n  9 P !  &
&  " "  & &  &       !  A # "   ! #  L & M      f    &
  ? 5  #    " #   !  D ! 5 #   ?    !         "  & 5
&   "       " #      !    D ! # &  #   #        5
A # "  A   & &    & # &     "           "  & & 5
  D     & 9 P !   #   &  f   &    > L & M  
II > ? # &   5
  # &     r u u  9 0     #  D  5 & " #   & &    & # &  
  L & M  
II > &  " ! # &    
 "
q r n  > ! # f  #  5
  #            9 L & M  
II "   &  &  &  A  ? 
x 0 ; y & # [  #   #   [      9 [  #    &  !  "   
A    !  L & M  
II    ?   2      A # "  " #   % M ; y ' 9
P !  [  #   M ; y & "     "  "           "  & & 5
  D     &    !  L & M  
II    ?   2  !    D ! #
&  #   #        A # "  > H y ; 5 ) 9 ;      > [       &
" #  #    A    f   D   D !       "     #     2 & # 
n 9  + z { &  "  # " ! ? # 9 P !  [      & ?   " !  &
A    #      &  # D     ?   2        "     "   ! 
[  #   M ; y & #   # " !      !     "  & &   D     & 9
P !  &  #    !    &  & #      # &   "  &  A L & M  
II #
•
p  5   #  " !    "     9 z   !  !  [  #   #  
 !  [      "         & ! # f  #        # 
p  5   #  " !    "     #   A    &       # p  5
  f     #  #     & & &  # "  9
•
H y ; 5 )      A # "  9 [  #   M ; y &         
# p  5   > n   G /
> H y ; 5 )      A # "  ? !  " !
 & # f #   #       &  !  D ! 5      #  A    & 9
• 1
G x   D    9  &      "  & &  & " #     5
A      #  { ?     A    {             
  " #     & 2  &   & &    D 4     
1
G x
% 4
1
G x ' "    #   &    !  [  #   9
•
[ f      D    9 [ f    & #    &   A   &  5
" !    
#          &  & #   # f #   #    
 !  [  #      "  & &   & #    !   #   y H  9
[ f    & #      D D         "           A
"       " #         #     & %  9 D 9 4
1
G x
  #  & # "     & ' 9
• :
    #      #     9 L & M  
II  W     &  ! 
"   f       #  f     #         " ! #   & 
&   ! #   &      "  & &  & " #    #  & A    #  #
    "     ?     !    f     #  #     & &
&  # "  & 9
•
H   D  #   #     9 ;  #           ! 
      #  "    #      "  & &   >  !  [  #  
M ; y &    f    # p  5   4 ; 0 y    5
D  #   #    !   #     "  & &   9
•
0       A   "     "   f  & 9 L & M  
II    f    &
! #   ? #   5 &              " # &      #     &
 f   &     &  A     &   "     ?   !  &  5
" !    
#         9
•
4    #     9 L & M  
II          & #
 # " 2   5   f      2      "     ! #   ? #  
? !  " !  & #         "  A #    & >       # " 2 5
  & #      A #    #   # & > #    f       #  & 5
     &   # " 2   & 9 G     f   >  # " 2   & #  
y 4 y 5      "          "   #  # "          9
= > @ B D E F G
P !  [  #   M ; y & #     " ! #  D   A   2  "    D #  
  "   f   D  # " 2   &     #   A     !     ?   2 9
;  #        >  f   [  #   M ; y   "      #   &
#    D  #   #    !   #     "  & &      H  # 
!  D !   5   f        "      "  & &   D    !  M ; y 9
P !  [  #   M ; y A   "     #      & #        "   5
  "     &   D &  f   #  &   #  #   p  5    #  #  &  &
    "   # &  "   "      " #       "   #    "   5
  #     9 P !   #   [  #   I & A   "     #      & #  
 ! 
J K L L O

 Q " K J U U K "
>  ! 
W

" O  Q " K J U U K "
>
 !  Y [ \  ] ^  >  ! 
_

W
 ] ^  > #    ! 
b

K " W

" O

U O J W
^
K
 d  ] ^  % 0 P [ M ' 9 P ! 
J K L f
L O

 Q " K J U U K "
   "  & &  & "    #   & A      5
 !    !   #   y H      !   [  #   I & A   "     # 
    & 9       !  &      >  !     & # "    #  
206 Redes y Comunicación
   
              ! "     " "
"

   " " "

 ( *
     
      "     
 

   
   ! ! 3   ! "     " " "

         " " !           
  "  
  * 
  3     !  8 :     <      ( @     "
3
 D      
     " "   G  !  "    I

  " J          ! "     " " "      
M 
 J ( P  "  D      
     " "          "
    
    " "   D  

U P  X   D  
<    X  
    : Z * [ ( Z 

        
  
 "
^ _ _ U " D `  I M   % @ : b   X 
 
M 
  
    " "         3    "  
   "   !  I
    "   " !      X   3  X     
 " ( Z   "
  
    " "   
 M   X 
     b
 
 " ! "   
         
     J     ! I
  
      M 
  " 3     !  G          <     
J      
  b i j ( Z 
&

 
'
 
(
  
)

(
* ( , ) (

. : Z * [ 0  "    "      X 
  3     
   
     " "   ( Z   " "  
  "  J !   I
   
 !     "      "    
   "      " I
"
X " ( 3   J !      
  "
M  !  * 
  " n o _ 4 (
5 6 5 8 9 ; < = >
Z  *      "
  X   I       " " M
 D 3     3 
<    !
  
   "     q D  
 
    < 
o ( ? A s t " 
  3
 ( u " [ 
II       "  
*     " 3     "  
 !
  
  J
 I       I
 X  ( Z  *     " 3     " ! " "  !     !    X
       
 D
 E   H
(   !    X
 X      
3     
q "
 <
 
X  J    "      X  ( Z 
  !    X 
X " 
      J     
"   X   !  ! 
   q  
X   !  J    q " J    !    
"   
 " I
J  " ( Z    !    X
 X        "

  <  
  D


"
         "       
  H
(

" ( Z       
     J    "   !    X
 I
X        "   X    x    
        !  "
 I

  J
  G  
   ^ _
ns
 " 3     ( P   
   q  <  D
 q  "
   <        " 
   ? ^ I
M   I   "   ! " 3       I  3        ( * <  

 q   
 "   " "     
 "
<    !
     !  
M  3    "  !  
     "   
       (
Z  <    !
     !    "    " 
J      "   
I
      
 q   3   X "
 q        (
K L
M | N } | O ~

€ M R S ~ T  ~ ‚ ƒ }

@     " "      D 3  "      J   
 
 " !   "  M 
      !      
 <
 !
     J

  ! "   M
"     !
 I 8     : U i    "   I
Z
M  o U * G     
 :
 ! (
V X Y Z Y \ ] _ Z ` a ] ` \ c _ a \ Z ` d ] ` e f
g h i j k
l h i j o p r s t p u s t k v h u x z { | }  | } } |
€ u h  j k k h u | ‚ ƒ l „ † v x j u h t | ‰ ‰ Š ‹ } z  Ž
l h x  j u  h s u i p r s t p  ’ t i j u “ } • € u h
–
 — v k j x ƒ l „ ˜ } Š š Š  r v j u p u s t k v h u x
œ ž †  ’ k Ÿ ‰ ˜  — x €
–
œ ˜ {   Ÿ Ÿ ž Š ¡ ¡ ž Š š š l  Ž ¢
 œ † • ƒ l œ  œ † • ¡ } ‹ ¡ ¡ ‹ Š ¡
l j £ h u r Š ‚ Š z  „ „ ¥ ‰ ¡ ¡
–
h t t j  x — ¦ — x r §
x  j u t j x Š ¡ ž Š ¡ ¡ œ t x j o } | ¨ ¨ Š © l
z — ª
§
 u h s i  h £ £ 
–
l ¨ « ¡ ‰
–
• x h u s ª j • j s ª s x j  s u u s  ’ i s } ¡ z 
g j x ¬ h u ­
g œ
–
© l ¨ ¡ ¡  ƒ ¡ | €
–
œ ˜ {
§
o s t ‰
• ¬ — x   © • } ƒ  ¡ Š } ˜ v h u x
§
o — x j ‰
• h ° x ¬ s u j
“ j u t j o | ‹ ‰ ‹ | Š ˜ Š « } ‹ ‚ } Ÿ ± Ÿ ‰
l h i ’ o j | ‹ ‰ ‹ | Š ˜ ‰ ‹ Š Ÿ ² k t j x
† • • ’ •
§ ´
— t ’ ‚ µ ‹ ¡   ‚ } Ÿ ˜ Ÿ ‰ ¢
´
—  u s u — j k ² k t j x | o —  k ˜ Š ‹ Ÿ ‹ µ ˜ ¡
–
h £ v — o j u ª   ˜ š ‹ š ‹ Š ˜ | š
´
s ’ t   j u •
´ ¶
¥ l ¡ ‹ š ‹ } ˜ Š
l € œ ² k t j x £ v — ˜ Š ‹ | ‰ ˜ š «
         3    u " [ 
II J    u !
    " ( @ 

    ! 
 D 3 
<     !    G      "  

" !    M
"     3   q  J   
  D  

M       J u " [ 
II
" U i @    <  
   ! 
I
   
      !   
    D
     <   J   I
  ! "  <  " "  J     
 8 :   ! "  I  <     ! I

    ( Z
M  o " !  
  " "   G     

"  ! ! "   
    G      " (
¸ 6 ¹ » = < ¼ ½ ¾ ¿ À = ¾ Á ½ ¾ Â Ä Å Æ =
Z  G  "     3   q  J   
   J
u " [ 
II
" "  M 

  
  
    " D 3
3     !       M    
 q "
   U i @  <  (
Ç  J     3        G      "    
 I

    "     3   q      "  J 
   
 
M
  3     ( j          
 M
  3    
 

   
    !   ! "   X
"      I
   M    
 q 3    3     " " "  "     X  
 3           " G  
 X  " "
X " ( @ 
   " 
" D M       " " "   <  q
   
  <  
U i @ È :  
  U i @ È %   <  
    "  

   J          " "
X "  " " ( @   !   D M    I
     
 M
  3    
  
   
  M 
  
! "   X
"    
 G      3   M      I
 " " " "  
     <  " "
X " "   !  
 I
 ! "   ! "   X U i @ È @ "  
  U i @ È @   <  I

    " ( 3  X !  o .
0 "   3 "   U i @ !     I
     

  M         
 M
  3     ( Z 

q !          
 M
  3     D  M 
  
"

 J  J   
" !   M         
  
x  D  "
XVI Jornadas de Paralelismo, JP '2005 207
   
       
µ
               
 " $      & ' )  *   &  ,

    

      
  

" $  '
(
$ $ 

$ $ 
, . 0 2     2
  0  2               !
, . 0 2    " #   0  2       !  %   ! % % &
' * 2 ,  "           & &
/
 1  
II     % !  ! %
- / 1 " $  3    *             *     &         
- 1 / " $  , 5  < = *  >      &      A C =     D
*     &           *     &           ,   '    D
' = '      M              > , 1 -
µ
   N & * =     D
*     &     *  P     7 , 8 >
µ
   N & *     *     &   
 *  P  , S &            *   =               
V =   *        ' ) * & M          *        <  & N
V  S  
II & M  *    ) *  M  & =  M  *   &  & N V  S  
       &       <   9     <  )        =   D
  *     &           *     &    9 < = *   ` > 7 < ,   
 ' ) * & M  '       =   &    N        c    8   D
 & * ) & *       M  *     )  *    d 8 D         =   
` > e < , 5       3      & ' )  *    *     3 C  D
9       3    V  S  
II     * '  & N          
         =    < 9 < = *   *  ) & *             * D
  = *  ,
?
@ B C 4 5 D E F H I I J L 7 N O P I 9 Q H Q J O L H L ; N O P P 9 >
L J N H Q J O L
S    & * i     * N      *   N & * ' &   *    =  D
  *     *  &       3  =      *     ` < & *
V =   *    ` > 7 < 3 ) * & M    ) * & < *  ' '     ) * &    D
 & *      =          '  ' & *  ,     *   
& )         *   <  & N     <  ) &            N & *
 & ' ' =       &  ) * &  &  &                   D
)           &       &   ) * &     & *  &     <   
  *        i   &    S C s ` > d < ,    & T &     <
& N ) * &  &  &  ) * &       <      &   <   9        D
 9   , 5  *   3 ' & M   <  & ' ' =       &  ) * &  &  & 
) * &       <  &    S C s    *          M        D
   & N     &   ) * &     & * N & * =      ) )       & 
) * & < *  '  3       3  & & M  *   )  & ' ) =     &    
? @
2
# 0   B C 0 , . 0 2   E C 0 0   F C "  C I ,    L 2  M
, 
@
 N P Q ' R S  " #   0  2    " I ,   & L 2  M , 
@
N
P Q ' R Z   2
  0  2   
@
2
# 0   B C 0 ' * 2 ,  " E C 0 0  N
 F C "  C , ` a P ' Q d &     f L 2  M  L 2 " C L  2 i  C B
  f 0 # 2
C " #   '    R  C    & I d i C "   L 2  M
q
 0 r  0 s C 0 u  I Q E M 2 F     
 & ' ' =       &  , x   &   3 S C s D       &     D
  M     &   *  '         *   =             
   *      
&          & M  *  &   D      M  *   &  
    =        * <  D        =    *  ` > < , C     
     &  3   '    = *            & N V  S  
II [ 
A C  & & M  *   )  & ' ) =     &      & ' ' =     D
  &  ,      )            \ =       &  &     
      *     *       & N    =    *     <     & * i 3
 =     &      ] =      & N    A C  ' )   '     D
  &  , C  & *   *  &    *     *  ^     & M  *   ) )   <
& N  & ' ) =     &      & ' ' =       &  3   '   D
 = *     ) * &     & *  M           `  &  ' =     
) * &     & *    M         &  ) )       &  ) * & < *  '  `
      & ' ' =       &      ) * & < *    , &  &  & 3
  =        3   '   
a b c d e f b g a
h
d j e k m
n
d
    3
      & '       & ' ) =     &     A C  & ' D
' =       &  ,            '    *  &    &  
    =         s } "      '  * i  =    ` / < ,
  s } "      '  * i  =           =     &
& )   '  ^     )  * N & * '     & N    A C     * N & *
 x s C $ o   ` 7 < ,
w x z x { | } ~  €  } ‚ ƒ „  … € ‡ ˆ ‰   … ~  x
        &       & N 
k b p Πj p a p b f j c c
   
)  *    *
c
h
a a b p d a p b f j c c
* =     < &    &   ) D
 *     &    ,  
k b p Πj p a p b f j c c
) &    
 &  D   &  i   <         *     M    *       &
   )  *    * ) * &     3 )  * N & * '   & '  )  *  '   D
*    ' & =   & N  & ' ) =     &  3         N & *
   )      <        *     M        &  & ' D
)     ,  
c
h
a a b p d a p b f j c c
) &     '       <
       *     M  ,  
k b p Πj p a p b f j c c
 &  
      * = '       &   '      &  D   &  i   <    
)     3     & ' ) =   )     3           )     ,
   & ' ) =   )         = ' '   & & )     
i   )      &   ) * &     & *  =   N & *  ) *    D
9     ' & =   & N   '  ,     & & ) )  * N & * ' 
      * '  ' & *           & * C $ }   & *   *  &
 M &   & )  *    &        '  <      * &  =    &  D
    * '     '       „ )  *  '     , …    <    
    3     M   &   =       M  *    „ )  *  '    
  & *   *  & &            '  „  ' = '      M D
             <  M    )    9  '     <    ^  
    & ' ) =     &    < *   =   *               
s A …  M           9 < = *    9         *    &   D
         & ' ) =   )       '         &   
  '  ,
208 Redes y Comunicación
0
100
200
300
400
500
600
700
800
900
64 128 512 1k 2k 4k 8k 16k 64k 512k 2M 4M
Bandwidth
(MB/s)
Message Size (Bytes)
Unidirectional Bandwidth
Bidirectional Bandwidth
    
  
0
5
10
4 8 16 32 64 128 256 512 1k 2k 4k
Latency
(usec)
Message Size (Bytes)
Unidirectional Latency
Bidirectional Latency
       

                  !
 " " # % ' ) * ) - / ) 1 - / - 3 5 ) 8 : 1 ) 8 : = - : 3 ?
" $  & ( * + -  . 0 2 + 4 5 7 2 9 5 + : . = > : ( : . B 5 > + D F
. G H + G . $ J 2 > J 9 5 2 5 + $ 2 + > $ B * + . 4 + J 9 5 + B 7 : F
S ( 9 . 9 > 7 $ . H & * . $ ( H . * > 9 X ( S 9 7 Y : 4 ] 7 * ] 7 ( * J > ] F
] + * + $ 9 : + 4 4 . & + 4 >  + 4 a c 4 + = S + B 9 + J 0 2 5 + $ 9 5 +
B 7 : S ( 9 . 9 > 7 $ 9 > : + > 4 4 5 7 * 9 + * 9 5 . $ : + 4 4 . & + H . F
9 + $ B X 0 9 5 + 4 ( 4 9 . > $ + J G . $ J 2 > J 9 5 > 4 D + * X B H 7 4 +
9 7 9 5 + : . = > : ( : . B 5 > + D . G H + G . $ J 2 > J 9 5 . 4 J + F
S > B 9 + J > $  & ( * + Y  . a " $ 9 ( * $ 0  & ( * + -  G 4 5 7 2 4
9 5 + o p r . D . > H . G > H > 9 X ] 7 *  - B t : + 4 4 . & + 4 2 5 + $
2 + > $ B * + . 4 + 9 5 + B 7 : S ( 9 . 9 > 7 $ . H & * . $ ( H . * > 9 X ( S
9 7 Y : 4 a v 7 9 + 9 5 . 9 0 > $ 9 5 > 4 B . 4 + 0 . 4 4 7 7 $ . 4
9 5 + B 7 : S ( 9 . 9 > 7 $ 9 > : + + = B + + J 4 9 5 + * 7 ( $ J 9 * > S
: + 4 4 . & + H . 9 + $ B X 0 9 5 + o p r . D . > H . G > H > 9 X > 4 . G 7 ( 9
z { a z | . $ J & * 7 2 4 ( S 9 7 z z a { | a
 > $ . H H X 0 > 9 > 4 2 7 * 9 5 $ 7 9 > $ & 9 5 . 9 9 5 > 4 9 + 4 9 S * 7 F
D > J + 4 . $ . J J > 9 > 7 $ . H B 5 + B } 7 ] 2 5 + 9 5 + * 9 5 + ~ p "
H > G * . * X B 7 : S H > + 4 2 > 9 5 9 5 + S * 7 & * + 4 4 * ( H + 7 ] 9 5 +
~ p " 4 9 . $ J . * J a  5 > 4 * ( H + J + 9 + * : > $ + 4 9 5 . 9 9 5 +
$ 7 $ F G H 7 B } > $ & 4 + $ J . $ J * + B + > D + B . H H 4 : ( 4 9 B 7 : F
S H + 9 + > $ J + S + $ J + $ 9 H X 7 ] . S * 7 B + 4 4 : . } > $ & ~ p "
H > G * . * X B . H H 4 a c 4 2 + 5 . D + 4 5 7 2 $ 0 ‚ 4 v + 9
II  4
~ p " S + * ] + B 9 H X B 7 : S H > + 4 2 > 9 5 9 5 > 4 * ( H + a
   D    F    !  #  % &  ! G )
p + * ] 7 * : . $ B + 7 ] : . $ X S . * . H H + H . S S H > B . 9 > 7 $ 4 > 4
H > : > 9 + J G X 9 5 + . G > H > 9 X 7 ] 9 5 + + $ 9 > * + 4 X 4 9 + : 9 7
& H 7 G . H H X 4 X $ B 5 * 7 $ >  + . H H $ 7 J + 4 a * 7 2 + D + * 0 H 7 F
B . H 7 S + * . 9 > $ & 4 X 4 9 + : 4 * ( $ $ > $ & 7 $ 9 5 + B H ( 4 9 + *
$ 7 J + 4 H . B } & H 7 G . H . 2 . * + $ + 4 4 . G 7 ( 9 S . * . H H + H . S F
S H > B . 9 > 7 $ 4 a + 7 B . H „ … } + * $ + H 4 . $ J 4 X 4 9 + : J , F
: 7 $ 4 . * + * . $ J 7 : H X 4
B 5 + J ( H + J . B * 7 4 4 B H ( 4 9 + *
$ 7 J + 4 a  5 > 4 ( $ S * + J > B 9 . G H + G + 5 . D > 7 * 5 . 4 . 4 > & F
$ >  B . $ 9 > : S . B 9 7 $ 9 > & 5 9 H X F B 7 ( S H + J . S S H > B . 9 > 7 $ 4
> $ 2 5 > B 5 . B 9 > D > 9 > + 4 7 $ 9 5 + B 7 : S ( 9 + $ 7 J + 4 . * +
5 > & 5 H X 4 X $ B 5 * 7 $ >  + J a ~ 7 * + 7 D + * 0 9 5 > 4 S + * ] 7 * F
: . $ B + G 7 9 9 H + $ + B } & + 9 2 7 * 4 + . 4 B H ( 4 9 + * 4 >  + > $ F
B * + . 4 + 4 † Y { / a
… + D + * . H 9 + B 5 $ > 0 ( + 4 5 . D + G + + $ S * 7 S 7 4 + J > $
9 5 + H > 9 + * . 9 ( * + 9 7 : > $ > : >  + 9 5 + > : S . B 9 7 ] 4 X 4 F
9 + : . B 9 > D > 9 > + 4 7 $ 9 5 + 7 D + * . H H S + * ] 7 * : . $ B + 7 ]
. S . * . H H + H . S S H > B . 9 > 7 $ a „ $ 9 5 + 7 $ + 5 . $ J 0
4 + D + * . H . ( 9 5 7 * 4 5 . D + S * 7 S 7 4 + J J > 1 + * + $ 9 B 7 F
4 B 5 + J ( H > $ & 4 B 5 + : + 4 9 7 4 X $ B 5 * 7 $ >  + 4 X 4 9 + : . B F
9 > D > 9 > + 4 . B * 7 4 4 B H ( 4 9 + * $ 7 J + 4 † { 0 ‹ / a „ $ 9 5 +
7 9 5 + * 5 . $ J 0 S + * ] 7 * : . $ B + : . X G + > : S * 7 D + J G X
3 ( 4 9 : + . 4 ( * > $ & 9 5 + B 7 : S ( 9 . 9 > 7 $ . H $ 7 > 4 + J ( +
9 7 S + * > 7 J > B 4 X 4 9 + : . B 9 > D > 9 > + 4 2 5 > B 5 : . X 5 . * :
S + * ] 7 * : . $ B + > $ 7 * J + * 9 7 * + : 7 D + 9 5 + : 7 * . : + F
H > 7 * . 9 + 9 5 + > * > : S . B 9 † Y { / a  5 + ( 4 + 7 ] 9 5 + . G 7 D +
: + $ 9 > 7 $ + J B 7 4 B 5 + J ( H > $ & 9 + B 5 $ > 0 ( + 4 > 4 $ 7 9 B 7 : F
: 7 $ H X ( 4 + J 0 4 > $ B + > 9 * + 0 ( > * + 4 } + * $ + H F H + D + H : 7 J F
>  B . 9 > 7 $ 4 a  5 + * + ] 7 * + 0 > $ 9 5 > 4 4 + B 9 > 7 $ 0 2 + ] 7 H F
H 7 2 9 5 + 4 + B 7 $ J . S S * 7 . B 5 a 5 + ( 4 + . 4 > : S H + : > F
B * 7 G + $ B 5 : . * } 2 5 > B 5 0 ( . $ 9 >  + 4 B 7 : S ( 9 . 9 > 7 $ . H
$ 7 > 4 + J ( + 9 7 4 X 4 9 + : . B 9 > D > 9 > + 4 a " $ 9 5 > 4 : > F
B * 7 G + $ B 5 : . * } 0 + . B 5 $ 7 J + S + * ] 7 * : 4 Y : > H H > 7 $
> 9 + * . 9 > 7 $ 4 7 ] . 4 X $ 9 5 + 9 > B B 7 : S ( 9 . 9 > 7 $ 2 5 > B 5
S + * ] 7 * : 4 $ + > 9 5 + * : + : 7 * X . B B + 4 4 + 4 $ 7 * "  „ a
XVI Jornadas de Paralelismo, JP '2005 209
0
100
200
300
400
500
600
700
800
900
0 200 400 600 800 1000
Bandwidth
(MB/s)
Computation Time (usec)
4k
32k
64k
128k
    
  
0
0.2
0.4
0.6
0.8
1
0 200 400 600 800 1000
CPU
availability
(%)
Computation Time (usec)
32k
       
  

 

   ! #           % 
    
" $ % ' ) + - % / - 1 $ $ 4 5 7 9 - " - 1 4 + % " ' = / / + $ " > / ? 9 A A )
$ " A 1 = > " - / C - 4 - " F / G 5 ' 1 + - % / " = ' / + $ / 4 ? + 4 1 ' / J
- % " - 1 ' J - % / > 9 + - 1 5 / ? 4 > / " $ % 1 - / > " - 1 4 + ' % 4 9 A C
" A Q " ) ' = / G 5 ' 1 + " + 4 1 ' / A / ' ' 5 " $ % 1 + / U
V +  W 9 > / ' 
"  " + C 
=  J Q / ' % 4 Q - % / > / ]
' 9 A - ' ? 4 > - % /  > ' - " + C - % / ' / $ 4 + C 7 > 4 $ / ' ' 4 > 4 +
- % / 5 " ' - / > + 4 C / J > / ' 7 / $ - 1 a / A )

U  > 4 5 - % / ' / > / ]
' 9 A - ' Q / $ " + C / > 1 a / - Q 4 1 + - / > / ' - 1 + W $ 4 + $ A 9 ' 1 4 + ' U
 1 > ' - J - % / + 4 C / ' 4 ? 4 9 > $ A 9 ' - / > " > / + 4 1 ' / A / ' '
/ a / + 1 + - % / Q 4 > ' / $ " ' / Q % 1 $ % $ 4 > > / ' 7 4 + C ' - 4
- % / 5 " ' - / > + 4 C / U k / $ 4 + C J - % / C 1 ' - > 1 = 9 - 1 4 + ? 4 >
- % / ' / $ 4 + C 7 > 4 $ / ' ' 4 > % " ' - % / a / > ) ' " 5 / ' % " 7 /
= 9 - 1 - 1 ' ' A 1 W % - A ) C 1 ' 7 A " $ / C - 4 - % / > 1 W % - 4 + = 4 - %
+ 4 C / ' U n % 1 ' 1 + C 1 $ " - / ' - % " - ' 4 5 / F 1 + C 4 ? ' ) ' ]
- / 5 " $ - 1 a 1 - ) 1 ' - " F 1 + W 7 A " $ / 4 + A ) 1 + - % / ' / $ 4 + C
7 > 4 $ / ' ' 4 > U V + - % 1 ' $ " ' / J - % / 4 + A ) $ " + C 1 C " - /
1 ' - % / F / > + / A Q % 1 $ % 5 1 W % - = / C / ' $ % / C 9 A 1 + W - % /
5 1 $ > 4 = / + $ % 5 " > F 7 > 4 $ / ' ' 1 + - % / ' / $ 4 + C 7 > 4 $ / ' ]
' 4 > 5 4 > / 4 ? - / + U
& '
  s t  u ) w x *
y 9 A A / >
   + ,
z   $ % " > " $ - / > 1  / " > " + W / 4 ? + / - Q 4 > F
1 + - / > ? " $ / C / ' 1 W + '  V + - / A { " > " W 4 + J } / 1 F 4 y k ] ~
" + C } ) > 1 + / -  9 ' 1 + W " ? / Q ' 1 5 7 A / 7 / > ? 4 > 5 " + $ /
7 " > " 5 / - / > ' ? > 4 5 - % / 4 W { 5 4 C / A U V + z G G  J - % /
" 9 - % 4 > ' 7 > 4 a 1 C / " ' ) ' - / 5 " - 1 $ ' - 9 C ) 4 ? - % / 1 5 ]
7 " $ - 4 ? $ 4 5 5 9 + 1 $ " - 1 4 + 7 / > ? 4 > 5 " + $ / 4 + 7 " > ]
- .
/ 0 2   0 4 5 " 0    / 5  / 0  " / 0
:
  "   / 5 :

  / :
  / 0  = / 5 4  " / 
  A
" A A / A " 7 7 A 1 $ " - 1 4 + ' 1 + " % 1 W % ] 7 / > ? 4 > 5 " + $ / + /
- ]
Q 4 > F ' 4 ? Q 4 > F ' - " - 1 4 + ' 9 ' 1 + W - % / 4 W { 5 4 C / A
" ' Q / A A U ƒ ' / - 4 ? } { V J " + C A 4 Q / > ] A / a / A 5 1 ]
$ > 4 = / + $ % 5 " > F ' 1 ' 9 ' / C 1 + z G  - 4 ) 9 " + - 1 ? ) ' 4 ? - ]
Q " > / 4 a / > % / " C J A " - / + $ ) J " + C = " + C Q 1 C - % 4 +  a /
$ 4 + - / 5 7 4 > " > ) + / - Q 4 > F '  y > " ) n  J V … } k {
k Q 1 - $ % ~ J † ' ‡ / - J } ) > 1 + / - ~ ˆ ˆ ˆ " + C , 1 W " ]
= 1 - - % / > + / -  U V + $ 4 + - > " ' - J V +  + 1 = " + C ‰
-
ƒ { V J
} ) > 1 + / - ‰ , } " + C † ' ‡ / - ‰ / A " + A 1 = " > / ' - 9 C 1 / C
1 + z ‹  9 ' 1 + W ' / a / > " A 5 1 $ > 4 = / + $ % 5 " > F ' U n % /
' " 5 / 1 + - / > $ 4 + + / $ - ' " > / / a " A 9 " - / C 1 + z   " - } { V
A / a / A 9 ' 1 + W 5 1 $ > 4 = / + $ % 5 " > F ' " ' Q / A A U n % / 7 > / ]
a 1 4 9 ' > / A / " ' / 4 ? † ' ‡ / - 1 ' C / ' $ > 1 = / C " + C " + ]
" A )  / C 1 + z G   1 + - / > 5 ' 4 ? 9 + 1 C 1 > / $ - 1 4 + " A " + C
= 1 C 1 > / $ - 1 4 + " A A " - / + $ ) " + C = " + C Q 1 C - % U  9 > ]
- % / > 5 4 > / J † ' ‡ / - 0 ' a 9 A + / > " = 1 A 1 - ) - 4 > / " C " + C
Q > 1 - / % 4 - ' 7 4 - ' 1 ' $ % " > " $ - / > 1  / C U 1 " > C Q " > / ]
" + C ' 4 ? - Q " > / ] = " ' / C $ 4 A A / $ - 1 a / $ 4 5 5 9 + 1 $ " - 1 4 +
4 + † ' ‡ / - " > / ' - 9 C 1 / C 1 + z G   U
B C
w
‘
’  “ ” • w
‘
” s
‘
u E “ t “ x  ) w x *
V + - % 1 ' 7 " 7 / > J Q / % " a / 7 > / ' / + - / C 4 9 > 1 + 1 - 1 " A
" + " A ) ' 1 ' 4 ? - % / $ 4 5 5 9 + 1 $ " - 1 4 + $ " 7 " = 1 A 1 - 1 / ' ? 4 >
" $ A 9 ' - / > = " ' / C 4 + C 9 " A ] – 7 - / > 4 + k } { + 4 C / '
1 + - / > $ 4 + + / $ - / C Q 1 - % † ' ‡ / -
II U – 9 > / — 7 / > 1 5 / + ]
- " A > / ' 9 A - ' ' % 4 Q - % " - - % 1 ' 7 A " - ? 4 > 5 % " ' " +
/ — - > " 4 > C 1 + " > ) 7 4 - / + - 1 " A ? 4 > % 1 W % ] 7 / > ? 4 > 5 " + $ /
$ A 9 ' - / > $ 4 5 7 9 - 1 + W U n % / $ 4 5 5 9 + 1 $ " - 1 4 + ' 9 = ]
' ) ' - / 5 7 > 4 a 1 C / ' $ " + > / A ) 4 + " + / — - > / 5 / A ) / ˜ ]
210 Redes y Comunicación
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0 500 1000 1500 2000
Iterations
Computation Time (usec)
   
   
     

0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0 500 1000 1500 2000
Iterations
Computation Time (usec)
   
   
     


           
     
    "
# $ & ' ( ' & ( * , . 0 1 3 5 $ 7 5 9 & 7 . & & , : , ; & . < 3 > > $ ' 7 @ & B
( * & & ' # , E > G ( 3 ( $ , ' 3 ' 9 # , E E G ' $ # 3 ( $ , ' 1 3 ' 9 3
. & 3 < < L < , * < & ; & < , : # , E > G ( 3 ( $ , ' 3 < ' , $ Q & 9 G & ( ,
Q L Q ( & E Q , : ( * 3 . & $ ' ( & . : & . & ' # & X
 G ( G . & * , . 0 $ ' # < G 9 & Q # 3 < 3 @ $ < $ ( L 3 ' 3 < L Q $ Q : , .
< 3 . 7 & . # , '  7 G . 3 ( $ , ' Q 1 > & . : , . E 3 ' # & 3 ' 3 < L Q $ Q : , .
9 $  & . & ' ( ( . 3 ^ # > 3 ( ( & . ' Q 1 3 ' 9 Q ( G 9 L , : 9 $  & . & ' (
Q # & ' 3 . $ , Q ( , , , 3 9 > . , ( , # , < > . , # & Q Q $ ' 7 ( , ( 5 &
b < 3 '
c d e X
f g 
h
i    j !   
h
k l
m 5 & 3 G ( 5 , . Q * , G < 9 < $ 0 & ( , ( 5 3 ' 0

3 ' # $ 9 7 & .
3 ' 9

3 ; $ 9 q 9 9 $ Q , ' : . , E r G 3 9 . $ # Q : , . ( 5 & $ .
7 & ' & . , G Q Q G > > , . ( X m 5 $ Q * , . 0 $ Q > 3 . ( $ 3 < < L Q G > B
> , . ( & 9 @ L ( 5 & w > 3 ' $ Q 5 y e $ m G ' 9 & . 7 . 3 ' (
m d e { | |  B | } ~ 
B e | € B |  3 ' 9 ( 5 & ƒ X w X

& > 3 . ( B
E & ' ( , : b ' & . 7 L ( 5 . , G 7 5  , Q q < 3 E , Q c 3 ( $ , ' 3 <
 3 @ , . 3 ( , . L # , ' ( . 3 # (  B „
|  B b c  B  € X
%
   † 
h
g  l
‡ ~ e 5 . $ Q ( $ 3 ' ˆ & < < 1

3 ' ˆ , ' 3 # 5 & 3 1 $ 3 ' ' $ # 0
e , ( & 1 ' 3 Q , '

G & < < 1 ‹ 3 G < " 3 . 7 . , ; & 1 ‹ 3 . . L
" G Q @ 3 ' 9 Q 1 e , Q ( $ ' d 3 ' # G 1 y $ # 5 3 & <  & < B
# , E & 1 3 ' 9 # 3 ( 5 & . $ ' & $ & < $ # 0 X q ' b ; 3 < G B
3 ( $ , ' , : e G . . & ' ( " $ 7 5 B ‹ & . : , . E 3 ' # & c & ( B
* , . 0 Q X d ' +
% ' ) + + -
. 0 2
3 ' 6 ,
0
7 + %
0
9 7
.
'
0
9 -
+
9 % 9 - - + - 9
0
-
< .
3 7 %
. 0 >
7 + -
+
% ' ) + 3 3
. 0 2
? 2
@ B
C ' 3
. >
@
1 c $ # & 1  . 3 ' # & 1 q > . $ < { | |  X
‡ { c 3 ' & (
( & ' X ˆ , 9 & ' 1

3 ' ' L e , 5 & ' 1
F , @ & . ( b X  & < 9 & . E 3 ' 1 q < 3 ' b X # G < 3 * $ 0 1
e 5 3 . < & Q  X w & $ ( H 1 ' 3 0 , ; c X w & $ H , ; $ # 1 3 ' 9
 & ' B # $ ' 7 w G X y L . $ ' & ( J q  $ 7 3 @ $ ( B
> & . B w & # , ' 9  , # 3 < q . & 3 c & ( * , . 0 X
,
K K K
M .
) % '
1 ~  O ~ P J { ‘ Q  € 1  & @ . G 3 . L ~ ‘ ‘  X
‡  F , ' ˆ . $ 7 5 ( * & < < 1  $ < < $ 3 E  3 * . L 1
q . ( 5 G . ˆ X y 3 # # 3 @ & 1 3 ' 9 e 5 . $ Q ( , B
> 5 & .  $ < Q , ' X d E > . , ; $ ' 7 ‹ . , # & Q Q , .
q ; 3 $ < 3 @ $ < $ ( L $ ' ( 5 & y ‹ d d E > < & E & ' ( 3 ( $ , '
: , . ( 5 & q w e d – F & 9 w G > & . # , E > G ( & . X d '
+
% ' ) + + -
. 0 2
3 ' 6 ,
K K K 8
'
0
6 + % +
0
) + '
0 :
' ) 9 -
8
' @ C
>
7 + % < + 7 U ' % = 3
1 m 3 E > 3 1   O ƒ w q P 1
c , ; & E @ & . { | | { X
‡


3 ; $ 9 b X e G < < & . 1  , 0 m $ '  $ G 1 F $ # 5 3 . 9 ‹ X
y 3 . ( $ ' 1 3 ' 9 e 5 3 9 ˜ X $ , Q 5 $ 0 3 * 3 X q Q Q & Q Q B
$ ' 7  3 Q ( c & ( * , . 0 d ' ( & . : 3 # & Q X
,
K K K M .
) % '
1
~ € O ~ P J   Q
 1  & @ . G 3 . L ~ ‘ ‘ € X
‡  ' G 3 '  & . ' @ ' 9 & H 1 b $ ( 3 '  . 3 # 5 ( & ' @ & . 7 1 3 ' 9
 3 @ . $ H $ , ‹ & ( . $ ' $ X ˆ e w B y ‹ d J q c & * q > B
> . , 3 # 5 $ ' ( 5 & w L Q ( & E w , : ( * 3 . &

& Q $ 7 ' : , .
 3 . 7 & B w # 3 < & ‹ 3 . 3 < < & < e , E > G ( & . Q X d ' +
% ' B
) + + -
. 0 2
3 ' 6 ,
K K K
Z
[ 8 M 8
'
0
6 + % +
0
) + '
0
?
>
C + %
8
' @ C
>
7
. 0 2 1 ‹ 5 , & ' $ š 1 q E O ƒ w q P 1
c , ; & E @ & . { | |  X
‡ € m & . . L ' , ' & Q 1  $ < < $ 3 E m G & < 1 3 ' 9 ˆ . $ 3 '
y 3 Q 0 & < < X d E > . , ; $ ' 7 ( 5 & w # 3 < 3 @ $ < $ ( L , : ‹ 3 . B
3 < < & < ' , @ Q @ L 3 9 9 $ ' 7 ‹ 3 . 3 < < & < q * 3 . & ' & Q Q
XVI Jornadas de Paralelismo, JP '2005 211
   
           ! 

    


  
  

   


  

  



 

  !


"
 $ %      * $ ,  $ .  , & $ 2  3   6 
7 9 9 ( 
; < * ,  = =    -  @  $ C    
  ,  =    $   F
,  H J  K  L L  6   C  K J / , %   6 = 
J   L    P  H   Q  ,         K % !
 3  = 
 ! 

    

   
  


" 

2 !
"



2 



  

  
 


 " 

  

"
 $
C   L    $ ! - $ .  , & $  
  6  7 9 9 7 
; V *   H *    -  H $ J  =   H 6        C    X
F    P    $         , H $ ,            $
 H           $ ,   P H    H $
8
 X
 H  J H      $ %   ,  L P  9 $   F
8
  X
6  =   @    %   F   %  Q     L  C   X

      Q K % ! ! 
=           3  !  X
:   6   F $ K       F h H  F  L   ! 

 !
   

   
  

   


  

  



 

  

"
 $ %      * $ ,  $ .  , & $
2  3   6  7 9 9 ( 
; l *   H *    -  H $ J  =   H 6        C    X
F    P    $ ,   P H    H $         , H $
8
  H  J H      $  H           $
8
  X
6  =   @    %   F  $   F %   ,  L P X
 9  K  L  6   L    P %  Q     L  C   X

      Q =    X 
  F C = H   !   L   X
  L  

   
 
$ 7 @ $ r & / @ 7 B s r $    X
H   t C  6 H   7 9 9 @ 
; r 9 * h H  F  L   H
 L  
H   ,  = F - F 

 2
  
   

 

2
 
2 

; r r * E  L   F %  K    $ ,    K 
F
  F  $
8
 3  F x  C H = =  $   F y      x  ,  X
F      x 9  L  Q C    H   L     -  X
  L  $  3     F $   F J   F @  F    
C = H   , L    L H   ! 

    

  

  

   


  

  



 

  !


"
 $ %  L   F      Q ! x x x t , C K C   X
Q    L     H
 C  
H    $ 2  3   6 
r l l < 
; r 7 * , F   K   F  $  H   C   !  F  J $ C  6 X
 J   %     $   F
8
  6  =   @    %   F  
 L  =  6 =  2 ! C X J    F E  F H L      -    X
 L  =  C = H     ! 

    

  

  

   


  

  



 

  !


"

 $ %      * $ ,  $ .  , & $ 2  3   6 
7 9 9 ( 
; r ( * C  6  J   %     $ , H L  H  C    $ , F  = Q 
=      $   = 3  F  C  = = $   F x   
C  L    6    y   h H  F  L  2  X
@  P / =    X %  Q     L  C = H     
y  L    =    

   
 
$ 7 7 $ r & / @ € B s < $
   H   t C  6 H   7 9 9 7 
; r @ * C  6  J   %     $  H   C   !  F  J $ x   
C  L    6   $   F   = 3  F  C  = =   L  =  6 = 
C  = =  L  3  C    H   L         ,  C !
h K  L      ! 

    

  
 &
   !


 
 ( S

    2

  

"   
 
  " 
$
   Q  F $ C , $ .  , & $ , H  H  7 9 9 ( 
; r s * C  6  J   %     $
8
       6     $   F
 L  %  P    y   C     Q   K      
 H
 L  
H  %  Q     L  / , L    3   

   = %  Q     L      V r l 7 %  X
L       Q ,  C ! h  ! 

    

  
  
 
   


  

  



 

  !


"
 $ %      * $ ,  $ .  , & $ 2  3   6 
7 9 9 ( 
; r € * %   H      3   $ %   ,  L P  9 $   F
8
  X
6  =   @    %   F   x K % /    X L 

  X 6 
   2 ! C X F  3   U    6  x    
K       %        ! 

    

  

  

   


  

  



 

  !


"
 $
8
  3  $ C  $ .  , & $ 2  3   6 
7 9 9 r 
; r < * K  L    $   3    $   3   = H   X
-  F     $
8
 3  F ,  = P  $   F   L P
8
  X
    

 1
W S


     " 

   

 

K ! y %    $ r l l € 
; r V * @ @ @    :   6   F      !  :   6   F y  F 
,    L      
; r l * @ @ @      L    K   L   $ !  L 
; 7 9 * @ @ @  Z H  F  L   L    h H  F  L   H
 L   X

H   ,  = F - F 
; 7 r * @ @ @  
s 9 9     y 
s 9 9  H
 L  
H X
       
212 Redes y Comunicación
ANÁLISIS DE LA EXTERNALIZACIÓN DE PROTOCOLOS
MEDIANTE SIMULACIÓN HDL
Antonio F. Díaz, Julio Ortega, Alberto Prieto
Departamento de Arquitectura y Tecnología de Computadores
ETS Ingeniería Informática
Universidad de Granada
18071 Granada
Andrés Ortiz
Departamento de Ingeniería de Comunicaciones
ETS Ingeniería de Telecomunicación
Universidad de Málaga
29071 Málaga
Resumen
En este trabajo se ilustran las posibilidades de los
modelos basados en lenguajes de descripción de
hardware (modelos HDL, Hardware Description
Language) en el estudio experimental del sistema
de comunicación. Concretamente, se analiza el
efecto en las prestaciones de comunicación de la
externalización de protocolos (offloading) en las
tarjetas de red con procesadores a partir de los
resultados de simulación de un modelo del sistema
realizado en el HDL Verilog.
1. Introducción
Con la disponibilidad de enlaces de anchos de
banda elevados (Gigabit Ethernet, GigaNet, SCI,
Myrinet, Hippi-6400), el cuello de botella de la
comunicación está pasando de los enlaces a los
nodos de la red. Así, las características de las
interfaces de red (NI) son cada vez más
determinantes en las prestaciones de
comunicación y es más importante reducir el
overhead asociado al procesamiento de los
protocolos de comunicación, cuyas causas
fundamentales se encuentran en los cambios de
contextos, las copias múltiples de datos, y los
mecanismos de interrupción. Así, el elevado
overhead de protocolos genéricos como TCP/IP
ha motivado un trabajo de investigación muy
activo en dos vertientes complementarias. Por una
parte se busca reducir el overhead software
asociado al procesamiento de los protocolos de
comunicación, bien optimizando las capas
TCP/IP, bien proponiendo nuevos protocolos. A
su vez, dentro de esta última opción se pueden
distinguir dos alternativas: los protocolos que
optimizan el soporte que el sistema operativo
proporciona para la comunicación (GAMMA
[11], CLIC [12]), y las interfaces de comunicación
a nivel de usuario [13], para las cuales incluso se
ha propuesto el estándar VIA (Virtual Interface
Arquitecture) [14].
La otra vertiente de investigación en esta área
busca mejorar las prestaciones que ofrece el
hardware de la interfaz. Así, hay una tendencia
cada vez más clara hacia las interfaces de red
programables (PNI, Programmable Network
Interfaces) o interfaces de red inteligentes
(Intelligent NIC, INIC), incluso con varios
procesadores, para proporcionar la funcionalidad
y alcanzar los requisitos de prestaciones de
comunicación en las aplicaciones actuales y en las
emergentes, liberando a la CPU del trabajo
relacionado con la comunicación, y
proporcionando la flexibilidad y reducción en los
tiempos de desarrollo de los sistemas de
comunicación. Dentro de esta línea se puede
incluir el uso de procesadores de red (Network
Processors, NP). Los NP son circuitos
programables optimizados para el procesamiento
de funciones de comunicación a velocidades
elevadas que juegan un papel muy importante en
el diseño de los encaminadores actuales. Además,
estos procesadores suelen incluir componentes
hardware para acelerar operaciones comunes en
esas funciones de comunicación (procesamiento
de CRC, etc.) [15].
La implementación de todas las funciones de
comunicación en la interfaz de red, estrategia que
se denomina offloading (traducida como
externalización de protocolos), en principio tiene
una serie de ventajas que afectan muy
directamente a las prestaciones de las
aplicaciones:
1. La CPU no tiene que procesar los protocolos
de comunicación, con lo que aumenta su
disponibilidad para las aplicaciones y el
solapamiento entre comunicación y
computación.
2. La tarjeta de red, al implementar los
protocolos de comunicación, puede
interaccionar con la red sin la intervención de
la CPU, con dos consecuencias importantes:
(a) se reduce la latencia del protocolo de
comunicación correspondiente ya que
mensajes cortos como los ACK no tienen que
atravesar el bus de E/S; y (b) la CPU no tiene
que procesar interrupciones para cambiar de
contexto y atender la llegada de mensajes.
3. Se puede mejorar la eficiencia de las
transferencias de DMA de mensajes cortos
desde la NIC si ésta los ensambla para
realizar una única transferencia de DMA.
4. Puesto que, a medida que los anchos de
banda que ofrecen las redes sigue creciendo,
el cuello de botella en la comunicación está
pasando a ser el bus de E/S, evitar su uso
puede contribuir de forma decisiva al
aprovechamiento de las mejoras que ofrecen
las redes.
5. La utilización de una NIC inteligente con
recursos que permitan aprovechar distintos
niveles de paralelismo mejora las
prestaciones en el procesamiento de los
protocolos de comunicación y ofrece la
posibilidad de gestionar dinámicamente los
protocolos, utilizando el protocolo más
adecuado para construir el mensaje a enviar
según los datos a comunicar y el destino.
Sin embargo, existen trabajos [5] que ponen en
duda que la externalización de protocolos (en
concreto la externalización de TCP) produzca
beneficios claramente visibles en las prestaciones
de comunicación. Las razones que se aducen para
este escepticismo se refieren, por un lado, a las
dificultades que surgen en la implementación, el
test, y el mantenimiento de la externalización [5].
Estos aspectos no constituyen argumentos
definitivos respecto de las mejoras que puede
aportar la externalización, pero deben
contrapesarse con los posibles beneficios que
aporte.
En cualquier caso, hay factores de carácter
fundamental que afectan a la mejora de
prestaciones que puede alcanzarse con la
externalización. Entre estos factores se encuentra
el efecto del aumento de prestaciones de los
microprocesadores según la ley de Moore, que
hace que las prestaciones de las CPU queden
bastante por encima de las de los procesadores de
propósito específico que se utilizan en la NIC.
Así, estos procesadores pasarían a ser el cuello de
botella del sistema de comunicación y limitarían
la velocidad a la que se procesa el protocolo. La
utilización de procesadores de propósito general
en las NIC puede significar un compromiso
bastante malo entre coste y prestaciones según
algunos autores que incluso consideran que el
coste de procesamiento de un protocolo como
TCP no justifica la externalización [8]. Además,
las limitaciones en los recursos (memoria)
disponibles en la NIC pueden suponer
restricciones en la escalabilidad del sistema
(limites en el tamaño de la tabla de enrutamiento
IP).
Por otra parte, en [9] (citado en [5]) se indica
que la comunicación entre la NIC donde se
implementa el protocolo y el procesador y la API
puede ser bastante compleja ya que prácticamente
habría que recrear un protocolo similar al que se
externaliza sobre el bus de E/S.
Si el protocolo de transporte reside en la NIC,
debe existir una coordinación entre el OS y la NIC
para gestionar correctamente recursos como los
buffers, los números de puerto, etc. En el caso de
protocolos como TCP el control de los buffers
TCP es bastante complicado, reduciendo los
posibles beneficios de la externalización (por
ejemplo, los buffers TCP deben mantenerse hasta
que se produzca el reconocimiento). Por otro lado,
la ineficiencia de las conexiones TCP cortas se
deben, en gran medida, a la gestión de los eventos
visibles para la aplicación, y éstos no se pueden
evitar por una externalización del protocolo.
Estos problemas se ponen más claramente de
manifiesto en el uso que se hace del protocolo
TCP en aplicaciones WAN (FTP, correo
electrónico, etc.) o en aplicaciones LAN que
requieren bajo ancho de banda (Telnet). En esos
casos los costes asociados a la gestión de las
conexiones son los más importantes y éstos son
los más difíciles de abordar correctamente con la
externalización. Por eso, en [5] se concluye que la
externalización está más indicada en aplicaciones
que implican anchos de banda elevados, baja
latencia y conexiones de larga duración. Un
ejemplo donde la externalización resultaría
eficiente es el RDMA (Remote Direct Access
Memory). El RDMA es un protocolo que permite
la transferencia de un paquete al buffer de
memoria correcto proporcionando una solución
adecuada para conseguir la 0-copia. Este
214 Redes y Comunicación
protocolo tiene un componente denominado DDP
(Direct Data Placement) que, al requerir una
temprana demultiplexación de los paquetes
entrantes debe implementarse en la interfaz de red
(igual que los protocolos TCP que hay debajo).
No obstante, también hay trabajos que
proporcionan resultados prometedores para la
externalización de los protocolos TCP. En [4] se
realiza un estudio experimental basado en una
emulación de una NIC conectada al bus de E/S
que se controla a través de uno de los
procesadores de un SMP. Los resultados muestran
mejoras entre un 600 y un 900% en la
externalización de TCP emulada.
En este trabajo se realiza un estudio de las
condiciones en las que la externalización de
protocolos puede aportar mejoras en las
prestaciones de comunicación. Para ello se ha
elaborado un modelo de simulación HDL del
sistema de comunicación (Sección 2). Los
modelos HDL tienen características interesantes
desde el punto de vista de la investigación y la
docencia en arquitectura de computadores [16,17]
ya que permiten tener una idea de la complejidad
de implementación de nuevas propuestas,
aumentar la confianza en los resultados de
simulación, e incluso obtener estimaciones de la
velocidad de reloj que puede alcanzar el hardware
(si se sintetiza el modelo HDL). Hacen posible la
identificación de caminos críticos y aspectos
mejorables del diseño [16].
Los resultados experimentales se muestran en
la Sección 3 y, finalmente, la Sección 4
proporciona las conclusiones del trabajo.
2. Modelo para la simulación
El modelo HDL del camino de comunicación
realizado permite estudiar, a un nivel próximo al
hardware del sistema, el efecto de los retardos en
las distintas etapas del camino de comunicación.
En cambio, la simulación de códigos realistas y su
interacción con el Sistema Operativo y con el
hardware, si bien puede llevarse a cabo, generaría
modelos de simulación más pesados. De todas
formas, como nuestro propósito es analizar el
efecto de los distintos elementos que concurren en
el camino crítico de la comunicación, el software
se simula mediante retardos de diferente magnitud
según se considere un overhead mayor o menor
para el procesamiento de los protocolos, los
drivers, etc.
La Figura 1 muestra el sistema simulado,
indicando los módulos en que se ha organizado el
modelo de simulación HDL. El módulo red
produce paquetes que llegan al módulo NIC. En
este módulo los paquetes se almacenan en una
cola de buffers y se transfieren por DMA a la
memoria del computador a través del bus de E/S.
Los módulos correspondientes a la NIC y al
conjunto procesdor/memoria se implementan de
forma distinta según el protocolo de comunicación
esté o no externalizado. Si el protocolo y el driver
se ejecutan en la CPU, cuando llega un paquete al
NIC éste genera una interrupción y empieza a
ejecutarse el driver, se inicializa la transferencia
de DMA y se transfiere el paquete a la memoria
principal del nodo a través del bus de E/S.
Después, el procesador ejecuta el código que
implementa el protocolo para extraer los datos del
paquete y pasarlos a la zona de memoria de
usuario. Si el protocolo está externalizado, el NIC
ejecuta el código correspondiente al protocolo,
inicializa y controla la transferencia de DMA de
los datos a la memoria principal del nodo.
Figura 1. Módulos HDL que constituyen el modelo de
simulación: CPU/Memoria, Bus de E/S, NIC, y Red. La
flechas indican el sentido de la transferencia que se
evalúa.
El módulo Red implementa el enlace y actúa
como un productor de datos, el que implementa la
NIC es un módulo consumidor de los datos de red
y productor de datos que pasan a través del
módulo correspondiente al Bus de E/S, que se
encarga de introducir el correspondiente retardo
CPU
+
Cache
Chipset
Memoria NIC
Bus E/S
Red
CPU
+
Cache
Chipset
Memoria NIC
Bus E/S
Red
XVI Jornadas de Paralelismo, JP '2005 215
en la información que se transfiere. Finalmente, el
módulo correspondiente al procesador, la
memoria y el chipset actúa como consumidor de
datos. En la Figura 2 se muestran algunos detalles
de los módulos correspondientes a la NIC y al
conjunto procesador/memoria/chipset.
(a)
(b)
Figura 2. Detalles de lo módulos HDL correspondientes
al NIC (a) y al conjunto procesador/memoria/chipset (b).
El modelo HDL realizado permite controlar la
velocidad a la que la red genera los paquetes, y
variar los retardos del bus de E/S, de los accesos a
memoria, y de las transferencias entre los distintos
buffers y registros entre los que se transfiere la
información. Los tiempos de procesamiento de los
programas se modelan mediante los
correspondientes retardos. El procesador del nodo
ejecuta una instrucción correspondiente a la
aplicación de usuario por ciclo, a no ser que se
esté produciendo una transferencia de DMA. En
este caso se considera que pueden ocasionarse
colisiones que ralentizan al procesador si éste
genera accesos a memoria que no están en cache y
el número de ciclos necesarios para completar una
instrucción se incrementa. En el caso de que el
procesador tenga que ejecutar código
correspondiente al driver o al protocolo de
comunicación, deja de procesar instrucciones de la
aplicación de usuario durante el tiempo
correspondiente. De esta forma, contabilizando el
número de instrucciones de la aplicación
ejecutadas se tiene una idea de los ciclos que el
procesador ha podido dedicar a la aplicación y
contabilizar también el efecto de las transferencias
de DMA.
Entre los parámetros que pueden modificarse
en el modelo HDL, en este trabajo se consideran
(para cada caso de protocolo externalizado y no
externalizado) cambios en los retardos entre
llegada de paquetes (control del ancho de banda
de la red), el retardo del bus de E/S (cambios en el
ancho de banda del bus), los tiempos de
procesamiento del driver de los protocolos de
comunicación, y los correspondientes a los
cambios de contexto. También se puede cambiar
la memoria disponible en el NIC para guardar
paquetes y el tamaño de los paquetes.
3. Análisis de resultados experimentales
Los experimentos realizados corresponden a las
prestaciones en la recepción de paquetes con/sin
externalización de protocolos y para distintas
situaciones de ancho de banda de red y bus de
E/S, y tiempos de procesamiento de drivers y
protocolos.
La Figura 3 se refiere al caso en el que los
protocolos de comunicación no están
externalizados. En ella se pone de manifiesto la
variación en el ancho de banda efectivo con el que
se reciben los datos desde enlaces de 1 Gbps
(Figura 3.a) y 10 Gbps (Figura 3.b) para distintos
anchos de banda del bus de E/S (o incluso cuando
se considera la conexión directa del NIC al bus de
sistema) y distintos tiempos de procesamiento de
los drivers y protocolos. Como se puede
comprobar, el comportamiento es similar en
ambas gráficas. A medida que el bus de E/S tiene
un ancho de banda menor, el ancho de banda
efectivo de la comunicación se va reduciendo.
Además, a medida que disminuye el ancho de
banda de E/S, van desapareciendo las diferencias
en el ancho de banda efectivo ocasionadas por los
distintos tiempos de procesamiento de los
protocolos, dejando patente que el bus de E/S se
va convirtiendo en el cuello de botella de la
comunicación. Por otra parte, la diferencia entre
los anchos de banda efectivos para enlaces de 1
inter
driver
dma
intrack
intr
dIn
pReady
cReady
CPU
Memoria
inter
driver
dma
intrack
intr
dIn
pReady
cReady
CPU
Memoria
comienzo
final
dOut dIn
cReady
pReady pReady
cReady
intr
intrack
estado
+1 +1
leido
leer escribir
escrito
comienzo
final
dOut dIn
cReady
pReady pReady
cReady
intr
intrack
estado
+1 +1
leido
leer escribir
escrito
216 Redes y Comunicación
Gbps y 10 Gbps son de únicamente un 1.3% en el
mejor de los casos. En los experimentos a que se
refieren las gráficas de la Figura 3 el procesador
funciona a una frecuencia del orden del GHz, los
paquetes son de ocho palabras y hay espacio para
almacenar 16 palabras en el NIC. De los
resultados se deduce que, en esta situación y para
los anchos de banda considerados en el bus de
E/S, hay que mejorar bastante las características
del nodo para poder aprovechar el aumento de
ancho de banda en la red.
(a)
(b)
Figura 3. Ancho de banda efectivo en la recepción para
diferentes anchos de banda del bus de E/S (en MB/s),
tiempos de procesamiento de protocolo y enlaces de
1Gbps (a) y 10 Gbps.
En la Figura 4 se muestra la mejora que se
consigue con la externalización del protocolo en el
número de ciclos que quedan disponibles para la
aplicación. La Figura 4.a corresponde a un enlace
de ancho de banda igual a 1 Gbps y la Figura 4.b a
un enlace de 10 Gbps. Para los anchos de banda
del enlace considerados, las ganancias son
prácticamente iguales en cada combinación de
ancho de banda del bus de E/S y tiempo de
procesamiento de drivers y protocolos de
comunicación. Como se puede ver, para un ancho
de banda dado en el bus de E/S, lógicamente las
ganancias son mayores a medida que aumenta el
tiempo de procesamiento de los protocolos.
También se puede observar que las mayores
ganancias se producen a medida que crece el
ancho de banda del bus de E/S. Así, cuanto más
pequeño se hace este ancho de banda y se va
convirtiendo en el cuello de botella de la
comunicación, se reduce la mejora en el número
de ciclos disponibles que proporciona la
externalización del protocolo. Esto se debe a que
también aumenta el número de ciclos disponibles
para la aplicación que se produce en el caso del
protocolo ejecutado por la CPU.
(a)
(b)
Figura 4. Mejora en el número de ciclos disponibles por
la aplicación en el protocolo externalizado para (a) un
enlace de Gbps, y (b) un enlace de 10 Gbps.
En la Figura 5 se pone de manifiesto que el
número de ciclos por unidad de tiempo
disponibles para la aplicación en el caso de un
protocolo externalizado se mantiene en niveles
parecidos para distintos anchos de banda del bus
de E/S, salvo en los tiempos más elevados para el
BW (1Gbps)
0,1
1
10
100
1000
no 100 10 1
Bus de E/S (Ancho de banda)
10ns
100ns
us
BW (10Gbps)
0,1
1
10
100
1000
no 100 10 1
Bus de E/S (Ancho de banda)
10ns
100ns
us
Ganancia (1Gbps)
1
10
100
1000
no 100 10 1
Bus de E/S (Ancho de banda)
10ns
100ns
us
Ganancia (10Gbps)
1
10
100
1000
no 100 10 1
Bus de E/S (Ancho de banda)
10ns
100ns
us
XVI Jornadas de Paralelismo, JP '2005 217
procesamiento del protocolo. En estos casos, a lo
largo del mayor tiempo de comunicación, el
número de ciclos disponibles es
comparativamente bastante mayor que en los otros
casos.
Figura 5. Ciclos por unidad de tiempo (ciclos por
microsegundo) disponibles (el máximo es 1000) para la
aplicación para distintos anchos de banda en el bus de
E/S y tiempos de procesamiento de protocolo
externalizado.
A continuación presentamos algunos resultados
relativos a la reducción en la latencia que ponen
de manifiesto los beneficios de la externalización
descritos en el punto 2 de la Introducción (Sección
1). En la Figura 6 se muestran la mejoras
(reducción de latencia) para envíos de 128
palabras (Figura 6.a) y 256 palabras (Figura 6.b).
Los porcentajes que aparecen en la figura se
refieren a los tiempos consumidos en los cambios
de contexto con respecto al tiempo de
procesamiento del protocolo. Así, un 0% indica
que se utilizan los mismos tiempos para el
protocolo externalizado y no externalizado, un
20% significa que el protocolo no externalizado
consume un 10% de tiempo más que el
externalizado debido a los cambios de contexto, y
así sucesivamente. Los datos de la Figura 6
corresponden a un enlace de 1 Gbps. Como se
puede observar, y como es lógico, la mejora se
incrementa al aumentar el tiempo de
procesamiento del protocolo y al aumentar el
porcentaje de tiempo consumido en los cambios
de contexto. En los datos que se muestran en la
Figura 6 se alcanzan mejoras de hasta un 30%.
Estas mejoras aumentan con el tamaño del envío.
(a)
(b)
Figura 6. Reducción en el tiempo de latencia con la
externalización para distintos tiempos de cambio de
contexto, tiempos procesamiento de protocolo y tiempos
y envíos de 128 (a) y 256 (palabras)
Figura 7. Reducción en el tiempo de latencia con la
externalización para distintos tamaños de envío y
tiempos de cambio de contexto.
Esta tendencia se pone de manifiesto más
claramente en la Figura 7, en la que se
proporcionan las mejoras en las latencias a medida
que aumenta el tamaño del envío, para tiempos de
Ciclos disponibles (1Gbps)
0
100
200
300
400
no 100 10 1
Bus de E/S (Ancho de banda)
10ns
100ns
us
Mejora de Latencia (1Gbps, 128 pal)
0
0,2
0,4
0,6
0,8
1
1,2
1,4
10ns 100ns
Tiempo proc. protocolo
0%
10%
20%
30%
Mejora de Latencia (1Gbps, 256 pal)
0
0,5
1
1,5
10ns 100ns
Tiempo proc. protocolo
0%
10%
20%
30%
Mejora de Latencia (1Gbps, 100ns)
0
0,5
1
1,5
2
2,5
128 256 512 1024 2048
Tamaño envío (palabras)
0%
20%
218 Redes y Comunicación
cambio de contexto del 0% y del 20% del tiempo
de procesamiento de protocolo. En este caso se
alcanzan mejoras de más del doble para envíos de
1024 y 2048 palabras.
En la Figura 8 se muestra la reducción en los
tiempos de latencia con la externalización para
envíos de 128 palabras y distintos tiempos de
procesamiento de protocolo con distintos tamaños
de memoria para almacenar temporalmente
palabras de los paquetes entrantes (distintos
tamaños de la cola de buffers). Las mejoras son
mayores para tiempos de procesamiento de
protocolo mayores y, aunque siempre se produce
una reducción de la latencia con la
externalización, no se observan mejoras
espectaculares en todos los casos. En la figura
aparecen mejoras entre un 1% y un 22%.
El efecto de aumentar el tamaño de la
memoria disponible en el NIC para
alamcenamiento temporal se observa más
claramente en la Figura 9. En ella se pone de
manifiesto la reducción en los tiempos de latencia
a medida que aumenta el tamaño de los buffers.
Figura 8. Reducción en la latencias con los protocolos
externalizados para distintos tiempos de procesamiento
de protocolo y tamaño de buffers
Lo que ocurre es que esa reducción se produce a
ritmos parecidos en el caso de protocolos
externalizados y no externalizados: la reducción
en los protocolos externalizados es algo mayor al
aumentar el tamaño de los buffers (de ahí el ligero
aumento en las mejoras de los protocolos
externalizados con respecto a los no
externalizados).
También se ha estudiado experimentalmente
la posible mejora del rendimiento del DMA al
fundir las transferencias de paquetes de tamaño
pequeño (punto 3 en la Introducción). En este caso
se observa una ganancia en el número de ciclos
libres para la aplicación. Este es el efecto que se
puede considerar más relevante de la
externalización, según el análisis que hemos
realizado.
(a)
(b)
Figura 9. Variación en las latencias con el tamaño de los
buffers para ditintos tiempos de procesamiento de
protocolos.
4. Conclusiones
El modelo HDL que se ha siulado permite poner
de manifiesto la influencia de los distintos
elementos que intervienen en el camino crítico de
comunicación. Así, los resultados experimentales
preliminares que se han obtenido muestran el
efecto del ancho de banda del bus de E/S en el
ancho de banda efectivo que se alcanza en la
recepción de paquetes. El aumento del ancho de
banda del enlace no da lugar a un incremento del
mismo orden en el ancho de banda efectivo a no
ser que se mejoren las características del nodo.
En las situaciones que se han evaluado
experimentalmente, la externalización muestra
Mejora de Latencia (1Gbps, 128 pal)
0,5
0,75
1
1,25
10ns 100ns
Tiempo proc. protocolo
16
32
64
Latencia (us) [1Gbps, 100ns, 128]
0
1
2
3
4
5
6
7
16 32 64
Tamaño de Buffer en NIC
No ext.
Extern.
Latencia (us) [1Gbps, 10ns, 128]
0
1
2
3
4
5
16 32 64
Tamaño de Buffer en NIC
No ext.
Extern.
XVI Jornadas de Paralelismo, JP '2005 219
una reducción en los tiempos de latencia de la
recepción no demasiado elevada, siendo más
elevada a medida que aumenta el tiempo de
procesamiento de los protocolos de comunicación
y los drivers, y crecen los overheads asociados a
los cambios de contexto en el caso no
externalizado. El efecto beneficioso de la
externalización que más claramente se ha
observado es el incremento en el número de ciclos
disponibles para la aplicación. Esta situación es
más ostensible en los casos en los que el bus de
E/S no es el cuello de botella de la comunicación.
Así pues, los resultados obtenidos ponen de
manifiesto que la externalización de protocolos
tiene efectos beneficiosos en las prestaciones de
comunicación en determinadas condiciones
(algunas de las cuales se han identificado aquí)
que se refieren tanto a las características de la
aplicación como del sistema hardware/software.
Estas circunstancias deben contrapesarse con las
dificultades de implementación y mantenimiento
que plantea la externalización, tal y como se
plantea en [5]. Como trabajo futuro, además de
completar la exploración del espacio de diseño del
sistema de comunicación que define el modelo de
simulación HDL realizado, nos proponemos
actuar en dos frentes. Por un lado se pretende
estudiar el modelado de los sistemas de
comunicación partiendo de una aproximación
analítica a la evaluación de las prestaciones a
partir del modelo descrito en [1,2], y que se basa
en las curvas de servicio y de llegada [3] para
evaluar las arquitecturas de procesadores de red.
La otra línea de trabajo abordará la
externalización y comparación de prestaciones de
protocolos de comunicación (CLIC versus
TCP/IP) y la validación de los modelos de
simulación realizados, tanto mediante lenguajes
HDL como los correspondientes a simuladores de
más alto nivel (por ejemplo SIMICS).
Agradecimientos. Este trabajo ha sido financiado por el
proyecto TIN2004-01419 del Ministerio de Ciencia y
Tecnología.
Referencias
[1] Chakraborty, S. et al.:”Permance evaluation of network
processor architectures: combining simulation with
analytical estimation”. Computer Networks, 41, pp.641-
645, 2003.
[2] Thiele, L. et al.:”Design space exploration of network
processor architectures”. Proc. 1st
Workshop on Network
Processors (en el 8th
Int. Symp. on High Performance
Computer Architecture). Febrero, 2002.
[3] Cruz, R.L.:”A calculus for network delay”. IEEE Trans. on
Information Theory, Vol.37, No.1, pp.114-141, 1991.
[4] Westrelin, R.; et al.:”Studying network protocol offload
with emulation: approach and preliminary results”, 2004.
[5] Mogul, J.C.:”TCP offload is a dumb idea whose time has
come”. 9th
Workshop on Hot Topics in Operating Systems
(HotOS IX), 2003.
[6] Reginier, G. et al.:”TCP onloading for data center servers”.
IEEE Computer, pp.48-58. Noviembre, 2004.
[7] Nahum, E.M., et al:”Performance Issues in Parallelized
Network Protocols”. Proc. of the 1st
Symp. on Operating
Syst. Design and Implementation. Noviembre, 1994.
[8] Clark, D.D. et al.:”An analysis of TCP processing
overhead”. IEEE Communications Magazine, Vol. 7, No. 6,
pp.23-29. Junio, 1989.
[9] O’Dell, M. :”Re: how bad an idea is this?”. Message on
TSV mailing list. Noviembre, 2002.
[10] IETF RDDP working group documents:
http://www.ietf.org/ids.by.wg/rddp.html
[11] Ciaccio, G.: ”Messaging on Gigabit Ethernet: Some
experiments with GAMMA and other systems”. Workshop
on Communication Architecture for Clusters, IPDPS, 2001.
[12] Díaz, A. F.; Ortega, J.; Cañas, A.; Fernández, F.J.;
Anguita, M.; Prieto, A.: ”A Light Weight Protocol for
Gigabit Ethernet”. Workshop on Communication
Architecture for Clusters (CAC’03) (IPDPS’03). April,
2003.
[13] Bhoedjang, R.A.F.; Rühl, T.; Bal, H.E.: "User-level
Network Interface Protocols". IEEE Computer, pp.53-60.
Noviembre, 1998.
[14] http://www.vidf.org/ (Virtual Interface Developer Forum,
VIDF, 2001).
[15] Papaefstathiou, I.; et al.: ”Network Processors for Future
High-End Systems and Applications”. IEEE Micro.
Septiembre-Octubre, 2004.
[16] Pirvu, M.; Bhuyan, L.; Mahapatra, R.:”Hierarchical
Simulation of a Multiprocessor Architecture”. Int.
Conference of Circuit Design, ICCD’2000, 2000.
[17] Hyde, D.C.:”Teaching design in a Computer Architecture
Course”. IEEE Micro, pp.23-27, Mayo_junio, 2000.
220 Redes y Comunicación
Un nuevo algoritmo de CAC para redes multimedia de altas
prestaciones *
Agustín C. Caminero Blanca Caminero Carmen Carrión
Dept. de Informática. Escuela Politécnica Superior
Univ. de Castilla-La Mancha. 02071 - Albacete
{agustin blanca carmen}@info-ab.uclm.es
Resumen
En los últimos años, se han desarrollado nue-
vas aplicaciones con unos requerimientos ca-
da vez más importantes, y estos requerimien-
tos han estimulado la búsqueda de lo que se
conoce como Calidad de Servicio, QoS. Para
proporcionar QoS, se han estudiado diversas
fórmulas. Entre ellas, están los algoritmos de
control de admisión de conexiones (CAC) y de
control de parámetros de uso (UPC).
En redes que soportan QoS, un algoritmo de
control de admisión de conexiones (CAC) de-
termina si un nuevo ujo de tráco se puede
admitir en la red de forma que todos los usua-
rios de la red mantengan sus prestaciones in-
tactas. Tales algoritmos son un concepto clave
de las redes multiservicio debido a que deter-
mina hasta qué punto se pueden utilizar los
recursos de la red y si se cumplirán los reque-
rimiento de QoS prometidos.
En este trabajo, presentamos un nuevo algorit-
mo de CAC, el algoritmo de los Dos Tests. Es-
ta nueva propuesta no requiere ni uso intensivo
de CPU para tomar sus decisiones ni tampo-
co una compleja caracterización del tráco, al
contrario que otros algoritmos conocidos, co-
mo el algoritmo de la Capacidad Equivalente.
*Este trabajo ha sido parcialmente subvencionado
por la CICYT bajo el proyecto TIC2003-08154-C06-
02, y por una ayuda de la Universidad de Castilla La
Mancha.
1. Introducción
Durante los últimos años, se han desarrollado
nuevas aplicaciones que tienen unos requeri-
mientos de la red que las aplicaciones tradi-
cionales no tenían. Estamos hablando de, por
ejemplo, las comunicaciones de datos conti-
nuos (audio/vídeo) [3][11].
Estos nuevos requerimientos afectan a lo que
se denomina Calidad de Servicio, QoS. Este
término hace referencia a la capacidad de un
proveedor de servicios (un operador de red)
para soportar los requerimientos de las apli-
caciones de los usuarios en lo que respecta a
cuatro parámetros de uso: ancho de banda, la-
tencia, jitter o variación de las latencias y ta-
sa de pérdida de datos [1]. Estos parámetros
reejan cómo el usuario percibe un servicio de
red. La red es responsable de mantener el nivel
de QoS que sus usuarios esperan. Para lograr
esto, se han desarrollado algunas técnicas de
control de tráco.
Las técnicas de control de tráco (también
conocido como control de la congestión) se
pueden clasicar en dos grupos: control pre-
ventivo y control reactivo. El primer grupo,
control preventivo, incluye mecanismos que
previenen la ocurrencia de congestión. En el
segundo grupo, control reactivo, tratamos de
recuperarnos de la congestión utilizando infor-
mación de realimentación.
Entre los esquemas de control de tráco pre-
ventivo, los algoritmos de control de admisión
de conexiones (CAC) se usan para reservar los
recursos necesarios en los routers/switches in-
termedios para cada nueva conexión que se va
a establecer. El control de admisión de cone-
xiones se plantea la pregunta de si un rou-
ter/switch puede aceptar una nueva conexión
o no, basándose en los recursos disponibles
(buers, ancho de banda del enlace) en los rou-
ters/switches del camino que los datos deben
seguir.
El objetivo de un algoritmo de CAC es ob-
tener una alta ganancia a través de multiple-
xación estadística que nos permita maximizar
la productividad de la red, a la vez que se ga-
rantizan los requerimientos de QoS de las apli-
caciones. Una dicultad a la hora de diseñar
algoritmos de CAC es que estas decisiones de-
ben tomarse al vuelo, es decir, sin pérdida de
tiempo. Por lo tanto los algoritmos de CAC no
deberían requerir un uso intensivo de CPU.
En la literatura podemos encontrar una
gran variedad de algoritmos de reserva estadís-
tica [6][7][9]. Mientras que explicar tales esque-
mas queda fuera de los objetivos de este traba-
jo, debemos hacer notar que muchos de estos
esquemas están construidos sobre teoría de co-
las y complejas técnicas que no son apropiadas
para ser implementadas en un switch compac-
to de una red de altas prestaciones. También
debemos observar que estos algoritmos nor-
malmente los ejecuta un gestor de recursos,
que suele ser típicamente una workstation vin-
culada al switch. Lo que tenemos en mente es
un elemento de interconexión compacto, con
un gestor de recursos incrustado en él. Por lo
tanto, en este trabajo introduciremos un nuevo
algoritmo de CAC que no requiere un gran es-
fuerzo de computación, llamado algoritmo de
los Dos Tests., que sólo necesita el ratio pi-
co y medio de paquetes de cada conexión para
decidir si se acepta una nueva conexión o no.
Los resultados de la evaluación mostrarán esta
habilidad para desarrollar un control de admi-
sión efectivo, manteniendo la carga de la red
lejos de la saturación, y que por lo tanto pro-
porcionan a cada aplicación la QoS adecuada
a la vez que se hace un uso eciente del ancho
de banda del enlace.
Lo que resta de este trabajo está organiza-
do de la siguiente forma. Primero, describire-
mos cómo trabaja este nuevo algoritmo y el
modelo de red. A continuación, presentaremos
algunos resultados de la evaluación de pres-
taciones, comparando el algoritmo de los Dos
Tests con el conocido algoritmo de la Capa-
cidad Equivalente, de acuerdo a una serie de
parámetros, como por ejemplo la carga inyec-
tada o los paquetes descartados. Y, para na-
lizar, expondremos las conclusiones que hemos
obtenido en nuestra investigación.
2. Un nuevo algoritmo de CAC: el
algoritmo de los Dos Tests
Como ya hemos comentado antes, este algo-
ritmo está destinado a ser implementado en
los elementos de interconexión compactos de
nuestra red. De este modo, los objetivos de
su diseño son que no debe requerir ni una
compleja caracterización del tráco ni tampo-
co cómputo intenso. Este algoritmo solamente
necesita el ratio de paquetes pico y medio para
tomar una decisión.
Consideramos dos tipos de tráco diferen-
tes: CBR y VBR. Para las fuentes CBR, los
ratios de paquetes pico y medio son los mis-
mos, porque estas fuentes generan paquetes
a un ratio de bits constante. Para las fuen-
tes VBR, implementadas como secuencias de
tráco MPEG-2, el ratio de paquetes medio es
el ancho de banda requerido para transmitir el
fotograma de tamaño medio de la secuencia, y
el ratio de paquetes pico se reere al ancho de
banda necesario para transmitir el fotograma
más grande.
El algoritmo de los Dos Tests se esbozó ori-
ginalmente en el marco del encaminador multi-
media MMR [4]. Como su nombre sugiere, es-
te algoritmo implica la realización de dos tests
para decidir si una nueva conexión se admite
o no.
El primero de esos tests se reere al ancho
de banda medio de la nueva conexión, y con-
siste en añadirlo a la suma de los anchos de
banda medios de las conexiones que ya han si-
do aceptadas (incluyendo conexiones CBR y
VBR) y comprobar si el ancho de banda resul-
tante es menor que el ancho de banda máximo
que el enlace puede ofrecer. En caso de que
se cumpla este test, procederemos a aplicar la
segunda comprobación; en caso contrario, la
222 Redes y Comunicación
petición de conexión se rechaza.
El segundo de los tests se reere al ancho de
banda pico de las conexiones. Hay que recor-
dar que el ancho de banda pico es el mismo
que el medio para las conexiones CBR. Este
test consiste en añadir el ancho de banda pico
de la nueva conexión a la suma de los anchos
de banda pico de las conexiones que ya han
sido aceptadas y comparar si la suma excede
un cierto límite. En este caso, al contrario que
en el primer test, la suma se compara con el
ancho de banda del enlace multiplicado por un
término nuevo llamado factor de concurrencia.
El factor de concurrencia (FC ) está destinado
a mejorar el uso del ancho de banda del enla-
ce porque permite que la suma de los anchos
de banda picos de las conexiones excedan el
ancho de banda pico del enlace. Esto se ba-
sa en la suposición de que las conexiones rara
vez alcanzarán simultáneamente el ancho de
banda pico. Sin embargo, es más probable que
esto suceda conforme incrementamos el valor
de FC.
El algoritmo de los Dos Tests se puede re-
sumir de la siguiente forma:
si (BWn
m +

i
BWi
m <= BWL)
si (BWn
p +

i
BWi
p <= BWL × FC)
conexión aceptada
sino
conexión rechazada
sino
conexión rechazada
Algoritmo 1: Algoritmo de los Dos Tests
donde:
• BWn
m es el ancho de banda medio de la
petición de conexión,
•

i
BWi
m es la suma de los anchos de ban-
da medios de las conexiones que ya han
sido aceptadas,
• BWL es el ancho de banda del enlace,
• BWn
p es el ancho de banda pico de la pe-
tición de conexión, y
•

i
BWi
p es la suma de los anchos de ban-
da pico de las conexiones ya aceptadas.
Cuando FC = 1, estamos reservando el an-
cho de banda pico para cada conexión, por lo
que el ancho de banda del enlace estará in-
frautilizado. Esto signica que hacemos una
reserva no estadística. Conforme incrementa-
mos el valor de FC, le estamos dando menos
importancia al ancho de banda pico de la co-
nexión, ya que las conexiones raras veces al-
canzarán ese ancho de banda pico, como se ha
explicado anteriormente. Esto implica que po-
demos aceptar más conexiones y, al hacer eso,
incrementamos el uso del ancho de banda del
enlace, a costa de incrementar la probabilidad
de que dos picos se solapen en el tiempo y el
enlace se sature. Por lo tanto, el valor óptimo
de FC es el que produce un equilibrio entre la
utilización de la red y las garantías de servicio
dadas a las conexiones.
3. Modelado de la red usando OP-
NET
En esta sección explicaremos las implementa-
ciones realizadas durante el desarrollo del pre-
sente trabajo. La red está compuesta de no-
dos periféricos y switches. Estos switches pre-
sentan una organización interna denominada
buered-crossbar [8]. La red es conmutada por
paquetes, y no aplica ningún control de ujo a
nivel de enlace. Los nodos han sido colocados
siguiendo topologías arbitrarias.
Los nodos periféricos inyectan el tráco en
la red, y reciben el tráco generado por otros
nodos dirigido a ellos. Además, también reco-
gen datos estadísticos. Cada nodo periférico
puede crear dos tipos de conexiones: CBR y
VBR.
Para poder evaluar las prestaciones obteni-
das por este tipo de conexiones, y para com-
probar si están de acuerdo con las garantías
necesarias para cada tipo, en las simulacio-
nes que incluyen tráco CBR, se han utiliza-
do mezclas aleatorias de 3 tipos de conexio-
nes CBR: 64Kbps, 1.5Mbps y 55Mbps. De esta
forma, podemos analizar las prestaciones de la
red obtenidos por conexiones con requerimien-
tos de ancho de banda altos, medios y bajos.
Las fuentes de tráco VBR se han imple-
mentado como fuentes de tráco MPEG-2 [5].
XVI Jornadas de Paralelismo, JP '2005 223
Figura 1: Esquema de colas del modelo de switch.
Éste es un ejemplo típico de tráco multime-
dia. En el vídeo MPEG-2, se inyecta en la
red un nuevo fotograma compuesto de un cier-
to número de paquetes cada 33 milisegundos
(Frame Time, FT).
Este modelo también realiza el proceso de
recogida de datos estadísticos. Los nodos peri-
féricos esperan hasta que todas las conexiones
están enviando datos antes de iniciar la reco-
gida de estadísticas.
La arquitectura del modelo de switch que ha
sido diseñada para este trabajo combina co-
las a la entrada y a la salida, habiendo una
cola por cada par <puerto de entrada, puerto
de salida> (ver Figura 1). Se ha elegido esta
arquitectura de colas debido a su buen rendi-
miento y bajas latencias. Además, permite que
cada puerto de entrada y de salida trabaje in-
dependientemente del resto, lo que simplica
mucho las tareas de planicación. En general,
esta organización es similar a la organización
CICQ propuesta por Manolis Katevenis [8].
El algoritmo de encaminamiento que usan
los switches es Up*/Down* [10]. Por lo tanto,
es determinista y libre de ciclos.
La aplicación de los algoritmos de CAC tie-
ne lugar en los puertos de salida de los swit-
ches. Éstos reciben todos los datos necesarios
desde los nodos periféricos que inician las cone-
xiones a través de los paquetes de petición de
conexión. Dependiendo del algoritmo de CAC
usado en cada simulación, los switches necesi-
tarán diferente información, de modo que los
nodos periféricos deberán usar un paquete de
petición de conexión distinto para proporcio-
narle a los switches toda esta información.
4. Evaluación de prestaciones
En esta sección evaluaremos las prestaciones
del algoritmo de CAC propuesto, comparando
los resultados obtenidos con una red sin CAC,
y con una red con el algoritmo de la Capacidad
Equivalente [7]. Veremos cuánta carga se intro-
duce en la red cuando se aplica cada algoritmo
de CAC, y qué prestaciones obtiene cada tipo
de tráco en cada caso. Hay que tener siempre
en mente que debemos llegar a un equilibrio
entre la carga de la red y las prestaciones del
tráco.
Los parámetros que han sido modicados en
las simulaciones son el algoritmo de CAC, el
tamaño de los buers (16 y 32 Kb), la carga
solicitada (CBR y VBR por separado, 50% pa-
ra cada uno). Además, para el algoritmo de la
Capacidad Equivalente, se ha variado la pro-
babilidad de pérdida de paquetes
, y para el
algoritmo de los Dos Tests, se han utilizado
distintos valores para el factor de concurren-
cia, FC. Sin embargo, ni el tamaño de los buf-
fers ni
afectan signicativamente a los resul-
tados. Por lo tanto, sólo se mostrarán las grá-
cas para buers de tamaño 32Kb y
= 10−6
.
Además, solamente mostraremos las guras
que muestran las clases de tráco CBR ALTO
y VBR, debido a que en ellas podemos apreciar
resultados más interesantes. Para una explica-
ción más detallada, vean [2].
Para que sea más fácil entender nuestros re-
sultados, nuestras grácas muestran la carga y
la productividad como porcentaje del ancho de
banda del enlace, y los paquetes descartados
como porcentaje de los paquetes inyectados.
Lo primero de todo, se estudiará la carga in-
yectada en función de la carga solicitada (Fi-
gura 2). La carga solicitada se reere a la can-
tidad de datos que los nodos periféricos tra-
tan de generar. Incluye todas las peticiones
de conexión que los nodos generan. La car-
ga inyectada es la cantidad de datos que los
nodos periféricos inyectan efectivamente en la
red, después de que el algoritmo de CAC haya
sido aplicado. Obviamente, la carga inyectada
es más alta cuando no hay ningún algoritmo de
CAC ejecutándose. En este caso, no se rechaza
ninguna conexión y no hay límite en la canti-
224 Redes y Comunicación
dad de paquetes inyectados en la red, por lo
que la carga inyectada es igual a la solicitada.
Cuando se aplica el algoritmo de la Capa-
cidad Equivalente, apenas se rechaza ninguna
conexión, de forma que la carga inyectada es
casi la misma que para las simulaciones sin
CAC. Por otro lado, el algoritmo de los Dos
Tests rechaza muchas más conexiones que el
algoritmo de la Capacidad Equivalente. Esto
hará que las prestaciones de la red sean mejo-
res, debido a que hay menos paquetes atrave-
sándola al mismo tiempo.
También se puede ver que cuanto más alto es
el valor de FC, más carga se inyecta en la red,
es decir, se aceptan más conexiones debido a
que aceptamos que se solapen algunos anchos
de banda picos.
La productividad de la red se muestra en la
Figura 3. Las simulaciones sin CAC y con el
algoritmo de la Capacidad Equivalente devol-
vieron resultados similares, es decir, una pro-
ductividad muy baja en comparación con la
carga inyectada. Esto implica que se han des-
cartado muchos paquetes, debido al hecho de
que se han aceptado demasiadas conexiones.
Por otro lado, la productividad del algoritmo
de los Dos Tests es muy similar a la carga
inyectada, lo que signica que se han descar-
tado pocos paquetes. La razón por la que esto
sucede es que muchas peticiones de conexión
han sido rechazadas, y debido a eso, la carga
de la red es menor. Si bien la productividad
máxima obtenida por el algoritmo de la Ca-
pacidad Equivalente es mayor que la obtenida
por el de los Dos Tests, al compararlas con
las cargas inyectadas vemos que el algoritmo
de los Dos Tests se comporta mejor, pues hay
menos diferencia entre la carga inyectada y la
productividad.
Las Figuras 4 y 5 muestran los paquetes des-
cartados para fuentes de tráco CBR ALTO y
VBR. Como se aprecia, no hay diferencia entre
los tipos de tráco. Esto es debido a que los
switches no tienen ningún esquema de priori-
dades, por lo que no diferencian entre los pa-
quetes de un tipo de tráco y los de otro a
la hora de descartar los paquetes. Cualquier
paquete que entra en un switch que tiene sus
colas llenas se descarta, no importa a qué tipo
45
50
55
60
65
70
75
80
85
90
95
100
65 70 75 80 85 90 95 100
Carga
inyectada
(%)
Carga solicitada (%)
Carga solicitada - Carga inyectada
Sin CAC
Cap. Eq.
2 Tests, FC=1
2 Tests, FC=1.5
Figura 2: Carga solicitada vs. Carga inyectada.
45
50
55
60
65
70
75
80
85
90
95
100
65 70 75 80 85 90 95 100
Productividad
(%)
Carga solicitada (%)
Carga solicitada - Productividad
Sin CAC
Cap. Eq.
2 Tests, FC=1
2 Tests, FC=1.5
Figura 3: Carga solicitada vs. Productividad.
de tráco pertenezca.
El mayor porcentaje de paquetes descarta-
dos se obtiene cuando no se aplica ningún al-
goritmo de CAC. Este porcentaje se reduce
ligeramente cuando aplicamos el algoritmo de
la Capacidad Equivalente. Estos resultados se
explican porque dicho algoritmo rechaza pocas
conexiones.
Otro parámetro que afecta a la cantidad de
paquetes descartados es el tamaño de buer,
pero su inuencia es menor que lo esperado, y
solamente se nota cuando la carga solicitada se
acerca al 100%. Además, el valor del FC sí que
afecta de forma signicativa a los resultados.
Esto es debido a que cuanto mayor es el valor
del FC, más conexiones se aceptan y es más
probable que los buers se llenen.
A continuación, vamos a presentar los re-
sultados relacionados con las latencias experi-
mentadas por los paquetes. Como podemos ver
en la Figura 6, el tamaño de los buers afec-
XVI Jornadas de Paralelismo, JP '2005 225
45
50
55
60
65
70
75
80
85
90
95
100
65 70 75 80 85 90 95 100
Productividad
(%)
Carga solicitada (%)
Carga solicitada - Productividad
Sin CAC
Cap. Eq.
2 Tests, FC=1
2 Tests, FC=1.5
Figura 4: Carga solicitada vs. Paquetes descarta-
dos CBR ALTO.
0
10
20
30
40
50
60
70
80
90
100
65 70 75 80 85 90 95 100
Paquetes
descartados
(%)
Carga solicitada (%)
Carga solicitada - Paquetes descartados VBR
Sin CAC
Cap. Eq.
2 Tests, FC=1
2 Tests, FC=1.5
Figura 5: Carga solicitada vs. Paquetes descarta-
dos VBR.
ta a las latencias de la siguiente forma: cuanto
más grandes son los buers, mayores son las
latencias, para los valores de los parámetros
utilizados en las simulaciones. Esto es debi-
do a que cuanto más grandes son los buers,
los paquetes tienen que esperar más tiempo
en ellos antes de ser retransmitidos. Además,
para las simulaciones que no tienen ningún al-
goritmo de CAC y las que tienen el algoritmo
de la Capacidad Equivalente, las latencias son
similares, debido a que el algoritmo de la Ca-
pacidad Equivalente no rechaza muchas co-
nexiones, de forma que el número de paquetes
atravesando la red es casi el mismo que cuando
no hay ningún algoritmo de CAC. Para el al-
goritmo de los Dos Tests, el valor de FC afecta
a las latencias, como habíamos supuesto, por-
que cuanto mayor es el valor de FC, se inyecta
más carga en la red.
0.0001
0.0002
0.0003
0.0004
0.0005
0.0006
0.0007
0.0008
0.0009
65 70 75 80 85 90 95 100
Latencia
(seg)
Carga solicitada (%)
Carga solicitada - Latencia CBR ALTO (seg)
Sin CAC
Cap. Eq.
2 Tests, FC=1
2 Tests, FC=1.5
Figura 6: Carga solicitada vs. Latencia CBR AL-
TO (seg.).
Cuando la carga solicitada es menor que el
90 %, las latencias se mantienen estables, con
cambios prácticamente imperceptibles. Pero
cuando se acerca al 100 %, las latencias expe-
rimentan una crecida súbita. Esto solamente
sucede cuando estamos usando el algoritmo de
la Capacidad Equivalente o bien cuando no
aplicamos ningún algoritmo de CAC. Por lo
que respecta al algoritmo de los Dos Tests, las
latencias no sufren esa subida, se mantienen
con pocas diferencias para todas las cargas so-
licitadas. Esto se debe a que el algoritmo de
los Dos Tests es capaz de mantener la carga
de la red a unos niveles razonables, por lo que
proporciona mejores prestaciones a las cone-
xiones. Todo esto sucede tanto para conexio-
nes de tipo CBR ALTO como VBR, aunque
las grácas para estas últimas no se muestran
por ser similares a las de CBR ALTO.
Para tener una percepción mejor sobre las
latencias de los paquetes, hemos calculado el
porcentaje de paquetes cuyas latencias se en-
cuentran dentro de unos determinados umbra-
les. Estos umbrales son diferentes para cone-
xiones CBR y VBR. Son múltiplos y submúl-
tiplos del IAT (Inter-Arrival Time, tiempo en-
tre llegadas de dos paquetes consecutivos de la
misma conexión) y el FT (Frame Time, tiem-
po de fotograma, 33 mseg.), respectivamente.
Nuestro propósito es obtener resultados tem-
porales de cada conexión de forma relativa a
sus requerimientos. Esto es, para conexiones
CBR, cuando más ancho de banda requieren,
el IAT será más pequeño, por lo tanto ten-
226 Redes y Comunicación
drán umbrales más restrictivos. Para conexio-
nes VBR, los umbrales son relativos a las uni-
dades de datos de la aplicación, que son foto-
gramas de vídeo.
Como podemos ver en la Figura 7, ninguno
de los paquetes de tipo CBR ALTO cumple
con los umbrales más restrictivos, en ningu-
na de las simulaciones (con o sin algoritmo de
CAC), cuando la carga solicitada es del 90%.
Los grados de cumplimiento de umbrales más
altos son los obtenidos por el algoritmo de los
Dos Tests, debido al hecho de que es éste el
algoritmo que mejor limita la carga inyectada
en la red. Usando este algoritmo, el parámetro
FC es bastante importante, porque hay una
gran diferencia entre los resultados obtenidos
variando su valor. Usando las valores menores
de FC, casi el 100% de los paquetes cumplen
los límites menos restrictivos. Por lo que res-
pecta al algoritmo de la Capacidad Equivalen-
te, los resultados son similares a los obtenidos
sin ningún algoritmo de CAC.
Cuando la carga solicitada alcanza el 100%
(Figura 8), el algoritmo de los Dos Tests mues-
tra los mismos resultados que para 90%. Esto
signica que este algoritmo puede efectivamen-
te limitar la carga inyectada en la red. Por otro
lado, tanto los resultados del algoritmo de la
Capacidad Equivalente como los de sin CAC
han empeorado signicativamente. En este ca-
so, el número de paquetes que se inyectan en
la red y llegan a sus destinos es mínimo (co-
mo podíamos imaginar desde que explicamos
las tasas de paquetes descartados, ver Figu-
ras 4 y 5), y las latencias son enormes (ver
Figura 6), de forma que casi ninguno de los
paquetes cumplen ningún umbral.
Por lo que respecta a tráco VBR, con carga
solicitada del 90%, todos los paquetes alcan-
zan sus destinos cumpliendo los umbrales más
restrictivos en todos los casos. Los resultados
son independientes de los valores que tome el
parámetro FC. La razón de que esto suceda
es que los umbrales del tráco VBR son más
amplios que los de CBR.
Cuando la carga solicitada alcanza el 100 %,
entonces los resultados de las simulaciones con
el algoritmo de la Capacidad Equivalente y sin
CAC empeoran, pero no los de las simulacio-
0
10
20
30
40
50
60
70
80
90
100
61.68
30.84
15.42
7.71
3.85
1.93
0.96
0.48
Numero
de
paquetes
(%)
Umbrales (microseg)
CBR ALTO - Carga = 90%
IAT
Sin CAC
Cap. Eq.
2 Test, FC 1
2 Test, FC 1.5
Figura 7: Grado de cumplimiento de umbrales para
CBR ALTO (carga solicitada 90%).
0
10
20
30
40
50
60
70
80
90
100
61.68
30.84
15.42
7.71
3.85
1.93
0.96
0.48
Numero
de
paquetes
(%)
Umbrales (microseg)
CBR ALTO - Carga = 100%
IAT
Sin CAC
Cap. Eq.
2 Test, FC 1
2 Test, FC 1.5
Figura 8: Grado de cumplimiento de umbrales para
CBR ALTO (carga solicitada 100%).
nes con el algoritmo de los Dos Tests. Esto es
consecuencia otra vez del hecho de que el al-
goritmo de los Dos Tests tiene éxito al tratar
de mantener la carga de la red bajo unos lími-
tes razonables, lejos de una sobrecarga. Por lo
tanto, las prestaciones de las distintas clases
de tráco se ven mejoradas. De todos modos,
todos los paquetes cumplen los umbrales más
amplios para todos los parámetros estudiados.
5. Conclusiones
Después de observar los resultados mostrados
en las secciones anteriores, hemos obtenido las
siguientes conclusiones. Cuando no se aplica
ningún algoritmo de CAC, la red admite una
mayor carga inyectada, sin embargo esto causa
una fuerte degradación de las prestaciones de
la red (altas latencias y porcentajes de paque-
XVI Jornadas de Paralelismo, JP '2005 227
tes descartados).
El algoritmo de los Dos Tests controla la car-
ga inyectada rechazando más conexiones que
el algoritmo de la Capacidad Equivalente, pa-
ra los parámetros usados en las simulaciones,
y debido a eso, las prestaciones de la red se ven
ampliamente mejoradas. Los resultados del al-
goritmo de la Capacidad Equivalente son simi-
lares a los obtenidos sin ningún algoritmo de
CAC, no siendo un algoritmo de CAC eciente
para la red estudiada.
En el algoritmo de los Dos Tests, conforme
incrementamos FC, se incrementa tanto la car-
ga inyectada como la productividad. Mientras
tanto, la latencia se mantiene acotada al igual
que el porcentaje de paquetes descartados. Es-
to nos permite obtener garantías de QoS para
los trácos multimedia.
El algoritmo que mejor grado de cumpli-
miento de umbrales presenta es el algoritmo
de los Dos Tests, porque permite alcanzar un
mejor compromiso entre utilización de la red
y la QoS que reciben los ujos de datos.
Referencias
[1] Black, U.: QOS in Wide Area Networks.
Prentice Hall (2000).
[2] Caminero Herráez, Agustín.: Estudio de
la inuencia del sistema de control de ad-
misión de conexiones sobre las prestaciones
del tráco multimedia en una red de altas
prestaciones sin soporte de QoS. Proyecto
Final de Carrera, Universidad de Castilla-
La Mancha, 2004.
[3] Chien, A. A. y Kim, J. H.: Approaches
to quality of service in high-performance
networks. Proceedings de Parallel Compu-
ter Routing y Communications Workshop
(PCRCW) (1997).
[4] Duato, J., Yalamanchili, S., Caminero,
M. B., Love D. y Quiles, F. J.: A high-
performance multimedia router- Architectu-
re y design trade-os. Proceedings del In-
ternational Symposium on High Performan-
ce Computer Architecture (HPCA-5). IEEE
Computer Society (1999).
[5] Generic coding of moving pictures and as-
sociated audio. Recommendation H 262,.
Draft International Standard ISO / IEC
13818 - 2 (1994).
[6] Gelenbe, E., Mang, X. y Onvural, R.: Dif-
fusion based statistical call admission con-
trol in ATM. Performance evaluation, vol
27, páginas 360-411, 1996.
[7] Guerin, R., Ahmadi, H. y Naghshineh,
M.: Equivalent capacity and its applica-
tion to bandwidth allocation in high-speed
networks. IEEE Journal on Selected Areas
in Communications, vol 9, páginas 968-981,
1991.
[8] Katevenis, M., Chrysos, N., Passas,
G. y Simos, D.: Buered Cross-
bar (CICQ) Switch Architecture.
http://archvlsi.ics.forth.gr/bufxbar/
[9] Perros, H.G. y Elsayed,K. H.: Call
Admission Control Schemes: A Review.
IEEE Communications Magazine, Noviem-
bre, 1996.
[10] Schroeder, M. D. et al.: Autonet: A high
speed, self-conguring local area network
using point-to-point links. IEEE Journal on
Sel. Areas in Comm.. (1991)
[11] Towsley, D.: Providing Quality of Service
in packet switched networks. Joint Tutorial
Papers de Performance'93 y Sigmetrics'93
(L. Donatiello y R. Nelson, Eds.). Lecture
Notes in computer Science (729). páginas
560-586.
228 Redes y Comunicación
Transmisión Multicast en Tiempo Real de Vídeo MPEG-4
J. M. Dana, V. G. Ruiz, M. F. López, S. G. Rodríguez, J. P. Ortiz y I. García
Departamento de Arquitectura de Computadores y Electrónica
Universidad de Almería
Resumen
En este trabajo se presenta una solución al
problema de la transmisión de vídeo en tiempo
real en redes no ables, como es el caso de In-
ternet. Para ello hemos utilizado comunicacio-
nes multicast, así como una modicación (rea-
lizada por nosotros mismos) de la implementa-
ción de dominio público de MPEG-4 realizada
por FFMPEG [5]. Los resultados visuales obte-
nidos y las pruebas realizadas demuestran que
nuestro sistema es capaz de proporcionar una
solución válida al problema de la transmisión
de vídeo en tiempo real en redes de comunica-
ción con un ancho de banda variable y limita-
do, como es Internet.
1. Motivación
Desde la creación de las llamadas redes de di-
fusión (como por ejemplo, el MBone) y la tre-
menda popularidad de la que hoy goza Inter-
net nos encontramos con una serie de necesida-
des, anteriormente inexistentes, que ahora se
deben cubrir (información, comunicación, en-
tretenimiento, etc.). Aquí es donde podemos
encontrar la unión entre las redes de comuni-
cación y los servicios multimedia: emisión de
radio por Internet, retransmisión de conciertos
en directo, charlas virtuales, etc. Todos estos
servicios tienen una mayor demanda cada día
y es misión de los sistemas informáticos hacer-
los posibles.
El rendimiento de los procesadores crece de
forma exponencial desde hace varias décadas,
lo que permite realizar operaciones complejas
en un menor espacio de tiempo, permitiendo
sistemas en tiempo real como el que nos ocupa.
Desgraciadamente, las redes de comunicación
no crecen al mismo ritmo, de ahí que las téc-
nicas de compresión hayan avanzado tanto en
los últimos años y se hayan convertido en una
herramienta de uso diario. Cuando la cantidad
de datos a transmitir crece mucho más rápido
que el ancho de banda de nuestro enlace nos
vemos obligados a utilizar técnicas alternati-
vas que nos permitan realizar la transmisión
en el menor tiempo posible.
Los sistemas de transmisión de vídeo actua-
les suelen tener limitaciones importantes en
cuanto al ancho de banda se reere. Los equi-
pos que sirven las secuencias (en adelante, ser-
vidores de vídeo) deben conectarse a la red a
través de enlaces con una alta capacidad trans-
misión. De esta forma, el número de clientes
capaces de acomodar se encuentra íntimamen-
te ligado al ancho de banda disponible.
Esta limitación es muy importante cuando
hablamos de transmisiones de eventos multitu-
dinarios (conciertos, eventos deportivos, etc.)
o de sistemas en tiempo real, donde la informa-
ción no sólo debe llegar, sino que debe hacerlo
en el menor tiempo posible.
Por todo lo anterior, hemos diseñado un sis-
tema de transmisión que, utilizando comuni-
caciones multicast IP, es capaz de acomodar a
una cantidad de clientes ilimitada, permitien-
do emitir con un ancho de banda limitado por
parte del servidor.
2. Las transmisiones multicast
En redes de computadoras podemos distinguir
dos tipos básicos de transmisión de datos: (1)
las transmisiones unicast y (2) las transmisio-
nes multicast. La diferencia fundamental entre
Receptores
Emisor
Figura 1: Transmisión unicast en una red conmutada.
ambos modelos es que en el primero la comu-
nicación es punto a punto (típicamente entre
un servidor y un cliente) mientras que en el
segundo la comunicación es de uno a muchos
(un servidor envía datos a muchos clientes).
Es este segundo tipo en el que estamos intere-
sados porque permite enviar una secuencia de
vídeo a muchos receptores.
A la hora de implementar el modelo multi-
cast podemos usar dos estrategias diferentes:
(1) simularlo mediante transmisiones unicast
o (2) utilizar la infraestructura multicast que
Internet actualmente ofrece. La primera apro-
ximación se ha descrito en la Figura 1 y como
en ella se aprecia, el emisor (servidor de vídeo)
debe introducir en la red tantos ujos de datos
como posibles receptores existen. Esto plantea
dos grandes inconvenientes: (1) los enlaces pró-
ximos al servidor se congestionan ineciente-
mente porque deben soportar la retransmisión
de los mismos datos, una vez por cada recep-
tor, y (2) el servidor debe saber cuáles son los
receptores. Por tanto, debe de existir un ujo
de información desde los clientes hacia el ser-
Cabecera UDP
Cabecera IP
Multicast
Cabecera IP
Unicast
Figura 3: Encapsulamiento IP-in-IP.
vidor, lo que incrementa aún más la posible
congestión de los enlaces de este último. En la
otra alternativa (vésase la Figura 2), es la red
la encargada de replicar ecientemente tantas
veces como sea nececesario el ujo de vídeo
para que éste alcance a todos los clientes po-
tenciales, cuya situación en la red y número
puede cambiar a lo largo del tiempo.
Una de las limitaciones de una comunicación
multicast es que ésta precisa de redes IPv6 o,
en su defecto, redes IPv4 con routers multicast
capaces de hacer encapsulado IP-in-IP (ver Fi-
gura 3). El encapsulado IP-in-IP permite en-
230 Redes y Comunicación
Receptores
Emisor
Figura 2: Transmisión multicast en una red conmutada.
viar paquetes de emisor a receptor por medio
de routers que no entiedan protocolos de rou-
ting multicast como DVMRP o PIM.
3. El estándar MPEG-4
Los principales motivos que nos han llevado
a utilizador el estándar MPEG-4 son: (1) es
un estándar, (2) posee una tasa de compre-
sión excelente, (3) posee mecanismos tanto en
la capa de transporte como en la de codica-
ción que lo hacen ideal para aplicaciones de
streaming (acceso aleatorio a los GOVs, resis-
tencia a errores, códigos de sincronismo, etc.)
y (4) existe al menos una implementación de
dominio público potente que es la FFMPEG.
El estándar MPEG-4 [1], como sus antece-
sores, utiliza un sistema de codicación que re-
laciona los distintos Video Plane Objects (en
adelante VOP) entre sí según el esquema de
la Figura 4. De esta forma, los I-VOPs (o in-
traframes) son codicados independientemen-
te, los P-VOPs dependen del I-VOP anterior
y los B-VOPs dependen del I-VOP o P-VOP
Figura 4: Relación entre VOPs de una secuencia
MPEG-4.
XVI Jornadas de Paralelismo, JP '2005 231
anterior y posterior (de ahí que tanto a los P-
VOPs como a los B-VOPs se les conozca tam-
bién como interframes). A partir de lo ante-
rior, podemos denir el Group of VOPs (en
adelante, GOV), que es el grupo de VOPs
inter-relacionados, es decir, un grupo donde
sólo encontramos un I-VOP del que, directa
o indirectamente, dependen todos los demás.
Por tanto, cuanto mayor sea el GOV, ma-
yor será la tasa de compresión y menor la re-
sistencia a errores del sistema, ya que estos se
propagaran por los VOPs debido a la depen-
dencia entre ellos, hasta encontrar el siguiente
intraframe. Esto último, es de especial impor-
tancia en nuestro trabajo. Un GOV excesiva-
mente largo podría deteriorar la imagen sig-
nicativamente durante un periodo de tiempo
excesivo, mientras que uno demasiado corto re-
queriría de un ancho de banda extra para su
transmisión.
4. Descripción de nuestro esquema
de transmisión
Teniendo en cuenta las descripciones anterior-
mente presentadas, hemos desarrollado un es-
quema de transmisión donde:
• El servidor emite utilizando un canal mul-
ticast por secuencia de vídeo.
• Los clientes realizan la recogida de datos,
descodican las secuencias de vídeo y las
muestran por pantalla.
• El servidor no recibe información de los
clientes, es decir, no tiene información so-
bre el ancho de banda disponible o el nú-
mero de los mismos.
• El cliente no recibe información por par-
te del servidor, salvo la referente estricta-
mente al vídeo, de forma que desconoce la
situación del mismo en cuanto a recursos
disponibles.
Por otra parte, el cliente contará con tres
procesos ejecutándose concurrentemente (re-
cepción de datos, descodicación y visualiza-
ción) que nunca deberán sincronizarse median-
te semáforos o mutex, dada la necesidad de un
sistema en tiempo real. Por tanto, para mante-
ner la sincronía entre los procesos y controlar
el acceso a elementos comunes (buers circu-
lares para la recogida de datos y la descodi-
cación) se han utilizado interrupciones del sis-
tema (que dada su naturaleza no suponen una
latencia extra para el sistema global) y punte-
ros a memoria comunes.
Tras la precarga de una cierta cantidad de
vídeo (buering de N segundos), se lanzan los
procesos concurrentes de recepción y de des-
codicación. El primero es básicamente una
operación de entrada/salida y el segundo de
cálculo. Por tanto, compiten por recursos dife-
rentes del sistema y se multiplexan en el tiem-
po de forma adecuada. El último proceso, el
de visualización, se gestiona mediante las inte-
rrupciones del sistema. Se trata también bási-
camente de un proceso de entrada/salida, es-
pecialemente cuando existe soporte gráco con
aceleración hardware.
4.1. Recepción de datos
Dadas las premisas anteriores, cada clien-
te debe controlar el buer de datos de forma
independiente, utilizando sistemas de control
internos y sin realizar especulaciones sobre la
velocidad de transmisión o la capacidad com-
putacional del sistema (dado que, por otra par-
te, carece de esa información).
Además, el buer de recogida de datos es
dinámico, es decir, su tamaño se modica en
tiempo real según la situación del cliente (an-
cho de banda disponible, capacidad computa-
cional, etc.).
4.2. Descodicación de datos
En cuanto al proceso de descodicación, se
han realizado modicaciones sobre la bibliote-
ca FFMPEG, sobre todo en lo referente a las eta-
pa de cuanticación y descuanticación, donde
la biblioteca retornaba valores inválidos cuan-
do la cantidad de datos perdida era excesiva y
no podía reconstruir convenientemente el u-
jo de datos. Podríamos decir que los cambios
realizados sobre la biblioteca persiguen pro-
porcionar mayor resistencia a errores que el
estándar.
232 Redes y Comunicación
Estamos, por supuesto, ante el proceso con
mayor carga de trabajo del sistema global. La
descodicación de vídeo MPEG-4 no es ex-
cesivamente costosa, pero sí signicativa para
equipos de baja potencia computacional, don-
de éste será el cuello de botella del sistema.
4.3. Visualización
Para la visualización de los datos descodi-
cados se han utilizado bibliotecas que son ca-
paces de aprovechar las características del co-
procesador gráco (aceleración 3D, instruccio-
nes especiales, etc.), con lo que el rendimiento
es óptimo y en ningún caso supone un cue-
llo de botella o implica una disminución del
rendimiento de las etapas anteriormente cita-
das. Además, los fotogramas se van presen-
tando utilizando interrupciones del sistema, es
decir, no se utilizan temporizadores que, nor-
malmente, producen una latencia en el sistema
completo.
Las bibliotecas elegidas han sido las del pro-
yecto XFree86 [6] y las SDL [7].
5. Evaluación
Para evaluar el rendimiento del sistema, se han
utilizado distintas conguraciones de sistemas
actuando como clientes, tal y como vemos en
la Tabla 1.
Tabla 1: Algunos de los equipos utilizados para
evaluar el rendimiento.
Frec. de reloj Mem. RAM Mem. de la GPU C.I.E.
Centrino 1.6 GHz 512 MB 32 MB DDR MMX y SSE2
Pent. 4 1.7 GHz 256 MB 64 MB DDR MMX y SSE2
Pent. III 450 MHz 128 MB 32 MB MMX y SSE
Cel. PIII 800 MHz 128 MB 32 MB (sin acel. 3D) MMX y SSE
Como vídeos de ejemplo se han utilizado se-
cuencias clásicas dentro del panorama de la co-
dicación y transmisión de vídeo (Akiyo, Flo-
wergarden, Tempete, etc.), así como todo ti-
po de secuencias menos conocidas (películas,
eventos deportivos, etc.). De esta forma, he-
mos usado un grupo totalmente heterogéneo
de vídeos, a n de demostrar la funcionalidad
del sistema.
Debido a que nuestro sistema explota el con-
junto de instrucciones especiales de los distin-
tos procesadores, así como la aceleración 3D
de los coprocesadores grácos, hemos obtenido
resultados satisfactorios para las cuatro con-
guraciones, siendo quizás la última algo li-
mitada al carecer de aceleración 3D en el co-
procesador gráco (el proceso de visualización
actuaba como cuello de botella del sistema al
completo, en lugar de la descodicación, como
era de esperar).
El sistema responde correctamente ante po-
sibles fallos de transmisión, llegando a detener
la visualización en caso de caída del enlace,
por ejemplo, y continuando el proceso en el
momento adecuado cuando la situación se es-
tabiliza. Además, gracias a las modicaciones
del descodicador de MPEG-4, la resistencia a
errores es mayor y los paquetes UDP perdidos
no alteran signicativamente la calidad nal
de la reproducción.
En las Figuras 5(a) y 5(b) se pueden ver dos
fotogramas afectados por errores en la trans-
misión. Se ha simulado una caída total del en-
lace y, tras unos instantes en donde la repro-
ducción se ha encontrado detenida, se ha rea-
nudado el vídeo encontrando afectada sólo una
parte de los fotogramas (correspondiente a los
paquetes perdidos). Esto es debido a la pro-
pia naturaleza del estándar MPEG-4 [1] y a
ciertas mejoras realizadas por nosotros.
6. Conclusiones
En este trabajo se ha pretendido dar una so-
lución efectiva a la transmisión en tiempo real
de vídeo, obteniendo un sistema que consuma
la menor cantidad de recursos tanto por parte
del cliente como del servidor.
Tal y como hemos destacado en la evalua-
ción, consideramos que los objetivos iniciales
han sido cumplidos y que el resultado obteni-
do es correcto. Hemos realizado el diseño e im-
plementación de un sistema de transmisión de
vídeo en tiempo real, con unos requerimientos
computacionales escasos y utilizando para ello
un estándar de vídeo actual como es MPEG-4.
XVI Jornadas de Paralelismo, JP '2005 233
(a) Foreman (b) Flowegarden
Figura 5: Fotogramas de las secuencias Foreman y Flowergarden afectados por un fallo en la transmisión.
Referencias
[1] Fernando Pereira, and Touradj Ebrahimi,
The MPEG-4 Book, Prentice Hall PTR,
2002.
[2] Douglas E. Comer, Internetworking with
TCP/IP. Principles, Protocols,and Archi-
tectures, Prentice Hall, 2000.
[3] Steven Gringeri, Roman Egorov, Khaled
Shuaib, Arianne Lewis, and Bert Basch,
Robust Compression and Transmission of
MPEG-4 Video, Technical report, GTE
Laboratories Incorporated, 2003.
[4] Touradj Ebrahimi and Caspar Horne,
MPEG-4 Natural Video Coding - An over-
view, Technical report, Swiss Federal Ins-
titute of Technology, 2003.
[5] FFMPEG Multimedia System,
http://mpeg.sourceforge.net.
[6] XFree86, http://xfree86.org.
[7] Simple DirectMedia Layer (SDL),
http://www.libsdl.org.
234 Redes y Comunicación
     
     
        

  "       & (
*  ,
. /
0 2 4 5 6 2 9 ; = ? @ A B C 9 2 ? E G I E J K M N 5 P 2 9 J B K J I Q R M S T ? E V @ A
W @ X ; M [ @ ] ? P J 9 a T ; G E 2 M c I E d @ 5 2 g J 5 G ; Q E ? G E 2 S d X @ 9 G J 9
j ? G k @ 9 I G [ 2 [ [ @ n 2 I ; G 5 5 2 p R 2 6 2 ? E V 2
s t s u v
p N 5 x 2 E @ ; @ B c I X 2 z 2
{ | }  € ‚ ‚ „ … } € … } | ‰ „ Š ‹ } Œ  Ž   ’ “ ” Œ … ‰ • } — ˜   € ‚ ˜  ‹
™ š › œ  š ž
Ÿ   ¡ ¢ £ ¤ ¥   ¦ ¨ © ª ¤ « © £ ­ ® £ ª ¥ ¯ ¤ ° £ £ ¥ ¤ ª ± Ÿ ¦ ® ´ ¥ µ ¶ £ ¢
£ ¶ ¥ ¡ ¢ ª ¥ ¤ £ ° · ° ­ ¸ ¢ » ¢ µ ¢   ¢ ¥ £ ¼ ½ ® ¾ ¿ À ¯ ¥ µ µ   © µ ¥ Á
Â
¢   ¢ À ¢ ¯ ¢ À ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ ¥ £ ¶ £ ¥ µ ª Ã £   ¢ ¯ ¢ » © ¥ ¯ ª °
· ¢ Å ¶ £ ¤ © ° £ ¢ · ©   ¢     ¥ · ° µ µ © µ ª ¥ Æ ¢ µ   ¥ © £ ª ¥ ¯ ¤ ° £ ¥ Á
¿ © Ç £ À ¯ ° À © ¥ ª ¢ ¯ © ° µ É ¶ ¥ « ¢ £ ¥ µ ª ¢   ° ¥ £ ¥ · £ Ë ¤ · ¥ °
  ¥ µ © µ ª ¥ Æ ¢ µ ¥ Æ À ° ª ¯ ¢   ° µ Ì   ¥ ¢ · Æ ¢ ¤ ¥ £ ¢ Æ © ¥ £ ª ° Í
¤ ° Æ ¶ £ © ¤ ¢ ¤ © ° £ ¥ µ Î
¼ ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ ¤ ¢ · ©   ¢     ¥ µ ¥ ¯ ¡ © ¤ © ° ± Ñ ° ¦ ´ ¥ £
¥ £ ª ° ¯ £ ° µ   ¥ ¤ ° Æ À ¶ ª ¢ ¤ © Ç £ Í ¤ ° Æ ¶ £ © ¤ ¢ ¤ © ° £ ¥ µ ¥ µ
¢ ¤ ª ¶ ¢ · Æ ¥ £ ª ¥ ¥ · ¤ ¥ £ ª ¯ °   ¥ Æ ¶ ¤ « ° µ ¥ µ Å ¶ ¥ ¯ Ô ° µ ¥ £
© £ ¡ ¥ µ ª © ­ ¢ ¤ © Ç £ À ° ¯ À ¢ ¯ ª ¥   ¥ · ¢ © £   ¶ µ ª ¯ © ¢ Í ¥ ·
Ã Æ » © ª ° ¢ ¤ ¢   × Æ © ¤ ° Î Ÿ ¦ ® © £ ¤ ° ¯ À ° ¯ ¢ Æ ¥ ¤ ¢ £ © µ Æ ° µ
É ¶ ¥ ¢ À ¯ ° À © ¢   ¢ Æ ¥ £ ª ¥ ¶ µ ¢   ° µ µ ¥ ¥ µ À ¥ ¯ ¢ É ¶ ¥ À ¯ ° Á
À ° ¯ ¤ © ° £ ¥ £ Ñ ° ¦ Î ¾ £ ¥ µ ª ¥ ª ¯ ¢ » ¢ Ø ° ¥ ¿ ¢ Æ © £ ¢ Æ ° µ
¥ µ ª ° µ Æ ¥ ¤ ¢ £ © µ Æ ° µ Í Æ ° µ ª ¯ ¢ Æ ° µ ¤ Ç Æ ° À ¯ ° À ° ¯ Á
¤ © ° £ ¢ ¯ ­ ¢ ¯ ¢ £ ª ¸ ¢ µ   ¥ Ñ ° ¦ » ¢ µ ¢   ¢ µ ¥ £ ¯ ¥ É ¶ © µ © Á
ª ° µ   ¥ ¢ £ ¤ « °   ¥ » ¢ £   ¢ Í · ¢ ª ¥ £ ¤ © ¢ Î Ÿ   ¥ Æ Ã µ ¥ ¿ Á
À · © ¤ ¢ Æ ° µ ¤ Ç Æ ° À ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ µ © Æ À · ¥ Æ ¥ £ ª ¥ ¶ £
ª ¯ ¢ ª ¢ Æ © ¥ £ ª °   © Å ¥ ¯ ¥ £ ¤ © ¢   ° Ì À ¥ ¯ ° µ © £ À ¯ ° À ° ¯ ¤ © ° Á
£ ¢ ¯ ­ ¢ ¯ ¢ £ ª ¸ ¢ µ Î Ÿ µ ¸ Æ © µ Æ ° Ì µ ¥ À ¯ ° À ° £ ¥ ¶ £ £ ¶ ¥ Á
¡ ° ¢ · ­ ° ¯ © ª Æ ° Ì ¥ · Û ¥ © ­ « ª ¥   Ü ¢ © ¯ Ñ ¶ ¥ ¶ © £ ­ ½ ¯ ¥   © ª
Ÿ ¨ ¢ ¯ ¥ Ì ¤ ° Æ ° ¶ £ ¢ © Æ À · ¥ Æ ¥ £ ª ¢ ¤ © Ç £ ¤ ° £ ¤ ¯ ¥ ª ¢   ¥
¶ £ °   ¥ · ° µ À · ¢ £ © Ý ¤ ¢   ° ¯ ¥ µ   ¥ µ ¢ · ©   ¢ É ¶ ¥ µ ¶ ­ © ¥ ¯ ¥
Ÿ ¦ ® Î
Þ ß á
ž â ã ä å œ æ æ ç è ž
¾ · » ¶ µ ¼ ½ ® « ¢ µ ¥ ¯ ¡ ©   ° » © ¥ £ ¢ · ¢ © £   ¶ µ ª ¯ © ¢   ¶ Á
¯ ¢ £ ª ¥ · ° µ Ë · ª © Æ ° µ é ê ¢
Â
° µ Í ª °   ¢ ¡ ¸ ¢ µ ¥ ¶ µ ¢ « ° Í
¥ £   ¸ ¢ ¢ Æ À · © ¢ Æ ¥ £ ª ¥ ¥ £ ­ ¯ ¢ £ ¡ ¢ ¯ © ¥   ¢     ¥ µ © µ ª ¥ Á
ë ì í î ï î ð ñ ò ñ ó ô õ ñ í ö ÷ ô ø ñ ð ù ö ñ ú û ï ü î ï ý ü ñ ü ù ö ñ ÷ ô ø ô ð
ú ñ þ ÿ þ
 ù ô ü ï ú ø ð ô  ï ù î ô  ÿ þ 

 
     þ
  ø ô ð
ï ú  ö ü ö í î ï ð ö ô ÷ ï ì ÷  ù ñ ù ö  ü  þ ö ï ü ù ö ñ ù ô ü  ü ñ ò ï ù ñ
" # %
Æ ¢ µ ª ¢ £ ª ° À ¥ ¯ µ ° £ ¢ · ¥ µ ¤ ° Æ ° ¤ ° ¯ À ° ¯ ¢ ª © ¡ ° µ Î ¦ © £
¥ Æ » ¢ ¯ ­ ° Ì · ° µ À ¯ ° ¤ ¥ µ ¢   ° ¯ ¥ µ Í   © µ À ° µ © ª © ¡ ° µ
  ¥ ¥ £ Á
ª ¯ ¢   ¢ ' µ ¢ · ©   ¢ ¢ ¤ ª ¶ ¢ · ¥ µ Í Å ¶ ª ¶ ¯ ° µ   ¥ Æ ¢ £   ¢ £ Æ ¶ Á
¤ « ° Æ Ã µ ¢ £ ¤ « °   ¥ » ¢ £   ¢   ¥ · É ¶ ¥ ¼ ½ ® À ¶ ¥   ¥
À ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ Î ) ¢ ¯ ¢ Ô Ç £   ¥ ¥ µ ª ¢ · © Æ © ª ¢ ¤ © Ç £ ¥ µ
À ¯ ¥ ¤ © µ ¢ Æ ¥ £ ª ¥ · ¢ ¢ ¯ É ¶ © ª ¥ ¤ ª ¶ ¯ ¢   ¥ » ¶ µ   ¥ ¼ ½ ® Î
¼ ½ ® ¾ ¿ À ¯ ¥ µ µ ¥ µ ¶ £ ¢ £ ¶ ¥ ¡ ¢ ­ ¥ £ ¥ ¯ ¢ ¤ © Ç £   ¥ ¼ ½ ®
É ¶ ¥ µ ¶ µ ª © ª ¶ Í ¥ ¥ · ª ¯ ¢   © ¤ © ° £ ¢ · » ¶ µ À ° ¯ ¶ £ ¢ ¯ ¥  
¤ ° £ Æ ¶ ª ¢   ¢ Ì Æ ¢ £ ª ¥ £ © ¥ £   ° · ° µ Æ °   ¥ · ° µ   ¥ ¶ µ °
Í · ¢ µ © £ ª ¥ ¯ Å ¢ ¤ ¥ µ µ ° Å ª ¨ ¢ ¯ ¥ Î
Ÿ   ¡ ¢ £ ¤ ¥   ¦ ¨ © ª ¤ « © £ ­ ® £ ª ¥ ¯ ¤ ° £ £ ¥ ¤ ª ° µ © Æ À · ¥ Á
Æ ¥ £ ª ¥ Ÿ   ¡ ¢ £ ¤ ¥   ¦ ¨ © ª ¤ « © £ ­ ± Ÿ ¦ ´ ¥ µ ¶ £ ¢ £ ¶ ¥ ¡ ¢
ª ¥ ¤ £ ° · ° ­ ¸ ¢   ¥ © £ ª ¥ ¯ ¤ ° £ ¥ ¿ © Ç £   ¥ ¢ · ª ¢ µ À ¯ ¥ µ ª ¢ ¤ © ° Á
£ ¥ µ É ¶ ¥ ¤ ¶ ¥ £ ª ¢ ¤ ° Æ ° ­ ¯ ¢ £ ¡ ¥ £ ª ¢ Ø ¢ ¥ · « ¥ ¤ « °   ¥
µ ¥ ¯ · ¢ ¥ ¿ À ¢ £ µ © Ç £ £ ¢ ª ¶ ¯ ¢ ·   ¥ ¼ ½ ® ¾ ¿ À ¯ ¥ µ µ Ì ¢ ·
¥ µ ª ¢ ¯ ¤ ° £ µ ª ¯ ¶ ©   ¢ µ ° » ¯ ¥ · ¢ µ ¤ ¢ À ¢ µ Å ¸ µ © ¤ ¢ µ Í   ¥
¥ £ · ¢ ¤ ¥   ¥   © ¤ « ¢ ª ¥ ¤ £ ° · ° ­ ¸ ¢ Î ¾ £ · ° µ Ë · ª © Æ ° µ   ¸ ¢ µ
  ¥ + ê ê , Ì µ ¥ À ¶ » · © ¤ Ç · ¢ ¡ ¥ ¯ µ © Ç £ é Î ê   ¥ · ¢ ¥ µ À ¥ ¤ © Á
Ý ¤ ¢ ¤ © Ç £   ¥ Ÿ ¦ . é / Î
¼ ° ¯ ° ª ¯ ¢ À ¢ ¯ ª ¥ Ì À ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ Ñ ° ¦ ¥ £ ¥ £ ª ° ¯ Á
£ ° µ   ¥ ¤ ° Æ À ¶ ª ¢ ¤ © Ç £ Í ¤ ° Æ ¶ £ © ¤ ¢ ¤ © ° £ ¥ µ ¥ µ ¢ ¤ Á
ª ¶ ¢ · Æ ¥ £ ª ¥ ¥ · ¤ ¥ £ ª ¯ °   ¥ Æ ¶ ¤ « ° µ ¥ µ Å ¶ ¥ ¯ Ô ° µ   ¥
© £ ¡ ¥ µ ª © ­ ¢ ¤ © Ç £ À ° ¯ À ¢ ¯ ª ¥   ¥ · ¢ © £   ¶ µ ª ¯ © ¢ Í ¥ £
¥ · Ã Æ » © ª ° ¢ ¤ ¢   × Æ © ¤ ° Î ¼ ° ¯ ¥ Ø ¥ Æ À · ° Ì · ¢ ® £ ª ¥ ¯ £ ¥ ª
¾ £ ­ © £ ¥ ¥ ¯ © £ ­ 0 ¢ µ 1 Ü ° ¯ ¤ ¥ ± ® ¾ 0 Ü ´ ª © ¥ £ ¥   ° µ À ¯ ° Á
À ¶ ¥ µ ª ¢ µ À ¢ ¯ ¢ À ¯ ° À ° ¯ ¤ © ° £ ¢ ¯ Ñ ° ¦ ¥ £ ® £ ª ¥ ¯ £ ¥ ª Î ) ¢
À ¯ © Æ ¥ ¯ ¢ Ì   ¥ £ ° Æ © £ ¢   ¢ ¦ ¥ ¯ ¡ © ¤ © ° µ 5 © Å ¥ ¯ ¥ £ ¤ © ¢   ° µ
. , / Ì   © µ ª © £ ­ ¶ ¥ ¥ £ ª ¯ ¥   © Å ¥ ¯ ¥ £ ª ¥ µ ¤ · ¢ µ ¥ µ   ¥ ª ¯ Ã Ý ¤ °
Í À ¯ ° À ° ¯ ¤ © ° £ ¢ ¶ £ ª ¯ ¢ ª ¢ Æ © ¥ £ ª °   © Å ¥ ¯ ¥ £ ¤ © ¢   ° ¢
¥ µ ª ¢ µ ¤ ¢ ª ¥ ­ ° ¯ ¸ ¢ µ Î ) ¢ µ ¥ ­ ¶ £   ¢ µ ¥   ¥ £ ° Æ © £ ¢ ¦ ¥ ¯ Á
¡ © ¤ © ° µ ® £ ª ¥ ­ ¯ ¢   ° µ . 6 / Ì Í À ¯ ° À ° ¯ ¤ © ° £ ¢ ­ ¢ ¯ ¢ £ ª ¸ ¢ µ
  ¥ Ñ ° ¦ ¢ · ° µ   © µ ª © £ ª ° µ 9 ¶ Ø ° µ » ¢ µ ¢   ° µ ¥ £ · ° µ
¯ ¥ É ¶ © µ © ª ° µ µ ° · © ¤ © ª ¢   ° µ   ¶ ¯ ¢ £ ª ¥ · ¢ Å ¢ µ ¥   ¥ ¥ µ ª ¢ Á
» · ¥ ¤ © Æ © ¥ £ ª °   ¥ · ¢ ¤ ° £ ¥ ¿ © Ç £ Î
Ÿ ¦ © £ ¤ ° ¯ À ° ¯ ¢ Æ ¥ ¤ ¢ £ © µ Æ ° µ É ¶ ¥ ¢ À ¯ ° À © ¢   ¢ Á
Æ ¥ £ ª ¥ ¶ µ ¢   ° µ µ ¥ ¥ µ À ¥ ¯ ¢ É ¶ ¥ À ¯ ° À ° ¯ ¤ © ° £ ¥ £ Ñ ° ¦ Î
    
      
       
    % ' 
*
   %    %  % . 
0 2   
4 
5      %   
*
 % .  %   . ;  =
      %  4    . . .   %

       %   .    
  .  .   %  E  G   % 

4 5   J      %  %  %      %   % ;   % *

  %  E   
  
   
 %          %

 P   %   % 4 % .  %     S  .  4  . ;    *
  G  % V   %    %  
          '   Y 
 *
     Z   Y S  . [ 
\      Y ^
 .   `
 
                E     
 .     . 
  % 0
4 
 % .  %   . P   %  Y  
   G
 %
  
.   % 
V      %  %  Y     

     E 

 %    
 %     .    % %    *
 % Y   
  % .    %     2    E  .          *
;   .    %      %   %  0 %    
  % P     *
 
 
  

  
   
\   G      *
  E   
 %     %    %

    % .   E  
    
  %   .  %      %   % G  % .     %
.     = 
  J  
     ;   '     E 
.   % 
 %      % %     %
         E   G
f 
g      %     %
  Y   %       %     %
; %  
    
4 5  =  
 G
 i 
j   k l m j
 n p l  n k 

P     
   % 0    %
  . %  4
  %
  % .       ; = V %   % .  f ^ r J 
 % % G
  = V %      %  %      
 5 .      %
   . 
        %         .  %        *

 5    % 

    
G   .  2    E       *
. %  Y      % P     4  s t 4 G =
       . 
  %      %  % . 
   4  % G    S  .  4  .
.    %      %    .  % 
          %   . 
u
.    .    
    '
  % .   %  %     %
% 
  G   .        %
 %    % 4   .  
   Y
 . . .    % .  % ;
u
.     g  
 . 
%        ;   ^  ^    . 
 %    E  


 %      .     0         %  P   *
 %  

   % P   % 
   4  G   .      
%    
Y .   0 % .         
    
 
.    5  4 % .    
x .   %  P   %  Y 
P  
  %  P    % % E   %  
 %    .  %    .   
4   
    
  J
   %     . 
   4 
*
  % G
  %   

0 2       % ;      % G f

  
  
     . 
 %    E  .    
 *
 
               =     G       %  *
   %  P    % .  .  % ;   % Y
 Y    4  *
 
P    
   %            
' x %
.  
 .
 %      

  = 
  
 Y    .  
 P    G    %    .      
V     P   


      .   %   % . 
 %  
 
 .    *
   .  .  %    .  % 
      .     
 .
  G      .     %
 
   P   
     Y V   *
   %
   %  0
4    %     %       Y V % 

 *
Y  
 % G x     .         E  P       
   % ' 
    * S
  Y S G
    ! # ! $ & ( * ( , # / $ / 1 !
  
  
         %   % P    

     *
  % .  %  
    %   

\   G %    V 2 *
           
 
    % ' 
   %   
 .    2  . 
.     . 
0 2   ;
4 
5 
 %   . .    %        % . 
 .  % V   %   
          %  .      
  .  .   %  E  . 
    J     % } ^  ^ ~ G
 %     % ' 
   % } ^ 3 % ~ 
  
      
     %   
.
%   
  g      %    *
  % .  .  %   .     .     % %  4
     %  
   G   %   
S %
t ^ 3 %   %  2  .  %  

 %    % .  = 
   %
S %  ^ 3 %     %   
  
    . . .  .         } 7 3 ^ % ~ 
S %  ^ 3 %     % 
.   .  % } 9 3 ^ % ~ ; S % *
 ^ 3 %      % } ; 3 ^ % ~ G
 4   
.    P              
    . 
 % 4  % 
   .    2  . 
.   *
  . 
0 2    P    
    %     2 
  S    *
%  4   %    % . 
0 2   G   .    2  . 
.    
. 
0 2   % 
 %     %     .  2 
%   .  % *
.   =     S %   .  %   
' x % .  
 .
  G   . %     
 .       .    2  . 

.     . 
0 2   %       
%        
 
^ 3  %    V 2   P   %    %  Y  G f 
 .   
.  ^ 3 %   % 4        

 %    .      

 .    2  . 
.     . 
0 2   ; ^ 3  P   .  *
   .  .    g  
 .  ^ 3 %         .  %  
 .        .  
 . G
  .  2   .  % 0
4 
 % .  %   . 

 %   *
' 
  %        %  
   % S %
t ^ 3 %      *
   .   
    S  .  4  . .        .  % *
  . G %  % 0
4 
 % %         2  . 
4 % . 
  4  . 
4 
5  .  ^ 3 % ;       2  . 

.       .  %   . .    S  .  4  .  V    
 %          ;   7 Z G ?            E 
   
    .     Y 
   P   
.    % .  % 
       
%  
         %   
   
  G
     2  . 
4 % .    4        
4  . 
4 
5  
%        
   P   *
236 Redes y Comunicación
                    !         (
)     ,  !           /  !      0     
!            !         ,     7 !    
8
      !    = 8
    ?      ,   0     
            B      (    ,      !    
  !    !   ,     C    , 8
   !   B   ,    G
    !   ,       B       B            K
            ,  ( ) ,  M            
,    ,  B      
 K
 K P   K  
K  P  Q P S   (
) , B ,    7 !       T   U   
V
  B   
      0   !  Q   U  B   !     ,   ! X      
        !      ,   
V
  B      ( 
    !        B ,    7 !    !       
B     (  B             !       B    B   G
B   !         M   !  8
K  , 8    , 
   Q 
 ,    K B       B     !     !   ,     
   8
K B    !       ! X       ,     G
 B       
    
 ( )   !    ,  0    Q 
!      B     ,
8    C   ?   !    B ,  G
       !    ,         (    0   
B          !       B             ,   G
! X            ,      8
   !    
     B           !    ,   ! X      
  ,   /     ,  !      B     !   8
( b c  
B   B   !        , 0        B  ! ? 7 !     B ,  G
    !  Q  B     , U         T K B    =  
      B    !      B   B       P
(
b   U  K  ,   g i     0    Q   ,    B   G
 , ,  /    !      !     ,       Q  K B   G
       ,      /     j             
,     Q ,    X  C   7 !        !        B    G
 ,   (    B  !  7 !  !  Q   b c   ,      !   , 
B      ,             !       K B     
    !  !       ! Q     B ,       ,  (
 k 
l m  m l n o m p  l  m  q m  l r


)       ! !  Q                B   B    
 ! Q     ,  s   ,     !         b c !   G
             B    B   B   !      t  c ( 
B           B  !  7 !     !   j     ! ,     
   /  !   u c   /  !  8 ,      K c 8  v !           G
       ( 8   g     ,           j    ! !   
 ,       U   0   0      ,         c 8 
 B           !    !   ?   !   ( )  b c B  G
        0    X    P
c 8  K       ,  M G
     U x     8
    !   ( )  B ,       
   c 8 B     ,  U 7 !   !     ,  ,    K  , G
0     B     U 7 !  !             t  c C  ,
    B       G     ( )         j  !      G
        B              t  c K  ?    
  ! X 
     C   ,    !    U x    ( y     G
 K           ! Q   !   7 0     ,     B ,  G
  7 !      B   B      B   b c K  ,    T C  ,
         ,  K B    B   B   !            G
       ( ) ,  U 7 !   !     ,    ,     0 G
        , 8    , 
   Q   ,    B   
       0  ,   U x    B          , !    
     ,    T ( )   , !     , B ,    7 !      G
       ,  K    8
      j   ,      
g        !   ,         8
K C B   ,    
,          !      8
!              G
   ,    !    ,  /    (   c 8    U 7 ! 
   G      Q ,    !    !    s   B   ,  B      G
   ,   /      ,         K B   ,     K ,  
   0           !        ! X      
   !   B   B   !     ,      B     !   (
          "  #     $ & " ) "  ) !  "  %  #  ,
 ,  # " /  !   2  )  !   #  2 , 
)   
 x B ,  !     ! Q   !   7 0         B 
   ,         j  u    ,        }  7   G
  v B    B   B   !      0     ?      ! X 
     C ,    !   ( y    B   B   !         G
         ! X        ?        8

X  C       0       M       ,       
  ,    ,  B   B   !     ,  ,   ! X         
           0    ( y    B   B   !             G
   ,    !    U x       8
     U  
!     ,      !    U x       X  C      
      !     !   /     ! X  8
  ,    , 
       j  ( )       !    !    ,  M    
 B          B       ,         B     G
  B      !        ! X  8
K C B       ,
   B     B      ,            ,   (
)   g         0           ,    , 
     , B    ,     ,  0   ,     0   !  Q     G
       ,  s    B    B   B   !              
   ! X       C ,    !   ( 4 Q        
     0                  !    U x   
           ,    ,          8
K  
  U      !         0        !     !   G
         K C B      K    ?       G
! X        , 8
  !     Q  ( )   0   
B    ,     ,    ,         g   !     
        !    !   B          
V
 /  G
    ,  ( )   B    ,        /            
     B          
V
 7 j  ( c        0  K
XVI Jornadas de Paralelismo, JP '2005 237
   
       
       
       
#    & #  (    
# + 
      #      +  .  0

         
                
 
   
      
1 
(
 + 
    6    
   9   
  + <

&       A  +
 # ( #    E +  
     G H
+
        ( #        I       + <
A  
( 
 I  #  #  ( 
(
 +  .     + <
 &    
 #  #  +    #         0   ( +  E +  +  . 
 P Q     +  6  # I      ( #     + 
 
 #   T +   +   ( #    E +  +  .  G  I <   W   
X   I Y G W X Z    [ <  &  #   ( 
(     
      (    # ( #    E +  
     G 0 1    <
     # #  I        #  _  
 #   (     + 
  
G W X    # (  
 b      # (
 +  
0
   c  

       
   I    
  
+           + <
 &       e
  #     + h
      +    
  6 # #
 A   +
 
  h
6    
 # b  
  #    +   (   
&      
#    +        e  c [      +     0
j #  # I
   
G W X
  I    #     T +   h
+    
         Y #  #  +    #      + 
(     +    +   b
  <  e (  6   6      h
     Z 6       & e #   + <
 &       
b   
  m
   +  
  +
 m  
 ( h

 0 G W X       +
  
#  # +
 m  

 m
 H     
+  
A   H 6   c   +   b

 +           0   A   +
      6  h
 c  +   b
     (  6   (              0 j #
+
 m  
 A    +   b
    (     +   h
#  _   #  #
m b     #     
6   #  _   
 # I
   
0 j    #
m b     #      b _
(    +  # + #   #                   H   +  
# 
  
 6  (  6   &  9  <  & 
  
+
 ( #               
       
 .   +
6   + 
      b #  &   0 A   

 (  6  # # I   # ( #    E +  
     +  +

                    0 P #  <
    # + h
+ 
   # (  6  6  &   #     # + + 
 
 6 # +
                     
 0
j    # I
   
        
(    .  

( 
& #     #  <
       
 #  
 

 P Q 0 j # (    
 6 
    +    #
   (
  
           (  6    # A    #
     .   #    H 6 
  c  +
  
#  

(
    +     
0 j  
( 
 + 6 +   

#  +   I     c E +
 +
  
#  # b    H #  h
#
m b     # 
  T +
  +      +  # + #  
e
#
   #   
      +   
 0 j #  I  
( 
h
& #    6 
  # I
   
   
s
 
  
    +    #  (
  &  #      6   ( #
 +
  
#   m
H (   T  
    # +  

6 A   6     (  6   (              H
( 
6 
   (
   +  T   
  E +    
(    <  +  #
H  +
       +   b
 H    I  c  h

   + <
 &      #
    
 0 j  
 A  

   c  b    m      + <
 &        I   h

+   
b # b       +  T   
  E +     H
+
 # +
   I     + 
     &  #  _  
 0
1    
# + 
    
 ( 
& #    ( 
(
 h

    b  b    .   #  # I
   
G W X 6
< 
 # #    
G W X A     P u   Y G W X h
A P Z 0 j # G W X A P   + 
   #         h
   6 # G W X [ + ( 
  
   ( + 
 
•
j # b  #
  #  #
m b     # 
+   &    h
    #    (
6    c           

(  6    +
  
# 0
•
  A   +
      6   c  +   b
 . h
#
+   
   (  6    #   +   
 e
 E +     +  T   
 (              # (  h
6   +  & _   #  +
#   # A  0
•
j # +
 m  
 A    +   b
 (  +   &   
+   
 (  6  # # I   # A  H +   

(  6   m  # A 
+   
  +  & 
+  T   
  +
  
#   m
0
•
A   
 A      
(  6   6
            c    +   b
 +     #    #  
 +  T   
 H +   
(        
 +   b

 # <  &   +  &  

 E +     +  T   
 H #

(  6    #   +   
    + <
A  

    +  
 +
                   
+

   +  &      # # I           h
 0
A
     
  E +  + 
  #           .  
(  6    +
  
# 
  +    #   + 
     h

 # ( #    E +  
 0 P   c  H # ( #    E +  
   h
  +    # +
  
#   m
[      H 

   I    
  + <
 &       6 # #
 A   6

(             (  6    &  
 #    # h
   +  T   
 0 j #  # I
   
  #       
b    .   e (   +     # G W X
  I    # 6 
 m     #  
 
 P Q 0
238 Redes y Comunicación

 

            !  
            * 
 , - - -
0  2   3  0 0  2
 
 
         

4 5 7 4  9 ;

< =   ; 9 > @  
   
; < @ 5 C 4 ; 4 @ = E < 5 G < 5 E  < 5  9 ; < 5 < = E  E  <  4 5 > 4 @ 9  4 J 4 ; " < @ 4 7
@ 4 ; E G $ < = 9 4 @ 4 O > 5 9  4 O < ; 4  $ 9 ; $ < ; 4  4 9 ; < 5 < $ O E = < = E 9 @ 4 5 R

4 5 7 4  9 ;

4 5 7 4  9 ; 
 + 

; . 0 = 9  4 ; 4   4 . ; 4 < O 9 = < O < O = 9 G 9 5 4 U < = 9 @ 9 = E  9 U < 5 < < U 9 ; < R

4 5 7 4  9 ;
+ 5
= 4 O O 4 @ 7 4  9 ; 
+ + 
+
O E $ 9  4 5 4 ;  E = E 9 J 4 5 7 4  9 ; > 4 > @ < 9 ;  < @ E W < = E : @  4 5 4 ;  E = E 9 5
 4 E @ C 9 ; G < = E : @ 9 C ; 4 = 4 ; " < < 5 > 5 = O E 4 @ 4 5 $ ; 4 C 4 ; 4 @ 4 5 R
<
9 = > < ;  < = 9 @ ; 9 O <  <  > @
 
; . 0 = 9  4 < $ O E = < = E 9 @ 4 5 5 > [ 4 < 5 < < O  > @ < C 9 ; G <  4 = 9 @ ; 9 O  4
<  G E 5 E : @ J < 5 <  9 4 @ < @ = U 9  4 J < @  < R
<
9 = C "  4 9  C F


; . 0 = 9 = 9 @ ; 4 > E 5 E 9 5  4 O < 4 @ = E <  [ E 4 ; G .
5
E G 9  4 J K K G 5 R
<
9 = C 9 W  C M


; . 0 = 9 = 9 @ ; 4 > E 5 E 9 5  4 O < 4 @ = E <  [ E 4 ; G .
5
E G 9  4 J K G 5 R
> 9 @ ; 9 O > 9 @ ; 9 O  4 ; 4   Q >


; . 0 = 9 $ < ; < G < @ 4 @ 4 ; O < E @ C ; < 4 5 ; > = > ; <  4 O < ; 4  = < ; < = 4 ; E W <  9
$ 9 ; > @ 9 5 ; 4 > E 5 E 9 5  4 G .
5
E G < $ ; E 9 ; E  <  R


 S  
           
^

      
 *
 !

*  a
   d  e      
 h   
 *   *      
 h

j *     *  k
 *  
l m n m o 2 e
* * m n m  j       
       *  
*   u  h
   
 

     *   
 
 
* 3

 e m    
 *  * *  

h
 *   
v    * 

  x
    
* u    

   *
* ! *
!

*  a
 
d  e 2 - * 
 u
  
  x     m n m *   
h 3
   h  * 
 a
*
                 *       

   x *
                 3      2
T

{      
    v   h
     *  ! 
   
 
*
 
     2 
 
h  
  



     *  3
! 
    
*
 
     
  
* 
  x    *
 * 3
  *   * } *     e m    * *     u

   
3
    
*  ~    
* 
h a *
h  { 
  * 

h  3
k
h

2 -  

  
 
j *   ~
 a
  *
 *    *
  * 
        
    

e m 2 
  ! * 

  



     *  ! 
     
*
 
      

    
     u

     
   *  k
 *    
*
v   h

*  h

2 -       h
  *
h
{  

 k



 { *   h      
           3
   2  j     u  
  ! * 
  



  j    
  
   
*     
* m n m 2
U € W
  X   ‚ ƒ „ … ‡ ˆ  ‰ ˆ Š ‹  ‚ ƒ Œ … ˆ Š
- *   
   
j *  

h   h  

*   
h 
3

j *     h    
h
 *     *    
       3

 2 ^ 
h        

  h   
  
* 

   
3

    a  

   
   
h 

x   h       
      { 
  *  ! 

j *       
*
 
     2
- *   ! *    !
      * 
h   {
*

‘
h  
       
       *
   2
Y
                  


   u    ~

h 
    *
   h  
 3


    *       * * 
  j *     *  k
j *
[

\        ^  2 -  h          * h 
    h 3
  
  
 *  
 a 


 u
    
      


 *  

{




{ * 
  ! 
  h 
   h  *       * h 

j * 2 ^

 

      `
\
"  !  %
"  
 *  

  ~

h    h  * 
3
 

    
[
  b   
"  l   d o
*
    
  * h 
   2 -       
    * u  




m  ~
{ * * ” h        

!

 * ” h   
             * h 
   u    h 
   * 

h
 h
  * 
    • 
   2
- * *    
    
 

‘
h    * 
    
 2      x     x   * 
  
 

j *
   0  x  

*  ~    
* 
 v   
           2 n  h
3
h   *

    

j *    
  ! 
  l k  2  o x  j 3
h    
  * h  ~
   

h    h  * 

 3
*     h   

   2 m  h  n e 

   


~  

     !
  
 !  
 h     
*
 
      
  
! 
x *        ~  h      !
 
h    h  * 
  
 
*
 
   c

  d   e c

  f 
 ` l – m – e o 2
   
u     x   
h

—
  }  x   *    
 {    2
Y   


  
   g   
^


h 
 *         
 *   h  *    

 3

x   ~

* {   
             *  
 *  
  

           u     *        * 

0  2   3
 0 0     *   n *  k   2 
 ~   
          
  h    
*  * 

 
 2


 
 h    

      
j *      3
   u 
* {   


*           
 h  k
3
h     h

         * 
   2 -  



j *
XVI Jornadas de Paralelismo, JP '2005 239

 



        
       ! 
  $      ' ) 
   
    ' -
 
   
  
   
     
                            

  . /  1 2 4 5 4 6 . 7  8

   9    9   
 


:  2   9  

   9    9    7 . ; . 2  
 
8   

:  2    9   

   9    9   
 
  

:  2  8  9   

  "
9   
"
9   . /  1 2 4 5 4 6 . 7  8  9     

  "
9   
"
9   . /  1 2 4 5 4 6 . 7  8  9  #  

8   8  8 
$
  "
9   
"
9   . /  1 2 4 5 4 6 . 7 8  9     
     9  
  ' )    
 ! '    !  B D B - D )
     ! 

    

   
    
              L     N


   
    
      U  W X !  '       

 ' 
[
\  [
X !  )   [      B D B  )   [
^
       ' 
    ! 
   
' '  [ ! 
     ' - `


  [ )   
 X !     
      U  W '    [ )   


   !

[     
d   !
 X !    

N 

 ^
  
    
     '  ^           


! [   

g
' 
  h    ' [ !  ' ! )       '
 [
\  [  )   ^
[      )     '   
  ' - W  g
  [ )  
    ' ^
     ' )
     '      
  $  )

 [ ! 
   '
  L       '   )  '    
   - 
h  j N   h l    



      

 ' 
   [ ) !  '   ' )     ^
  \     ' ) !   
) !      
  g    
 

    
  - m    
'     h l    N   '   
   

'  
j
' '      
   )
X !    ' X !  '     ^
   
  '   [
  
 X !    ' 
  
  
    
   [ )      
 o  p [ ' q - 
  '     !   $   
  '   '     '  ' !   L   [  -
      
'      


 

  
m   !  '  
' )  !  
'   [ )

[  ' 
' )   ' 
^
     '  L     
' )     '   ' ) 
   
    ' X ! 
)   )    D W - `

  ) 
   
   
'
   

 
g  [  '  [ )  
  ! 

 
 
    
d 
       

' - `

 [ )   [   
       u
g  [  ' ! '
   
     [  u v U B D )   ) !  '  
  
W     $   -
- m  

 

'  [ !  '  


    ! 
  $      ' [  ' [  ' - `

    ! 



 
N g  [  '
'  
 
 B  X ! 
  [  


  
            ! 
  ' 
  
[
\  [
 
         

'    '   !   h
' - m ' 
  ' 
  

 ' !    [ )   [  '       ! 
 !  

    

 
' 
   [
' 

'    

' )

 '     ) 
   
   - W  g


'  
  !  )  X ! 
z
  { [   
     

'
  
     '  ^        )   )     $ 

' !  [ )   
  
  
  h
- m    '        

'
'  g

'  
 
  
        X !  '    '   U  W -
W  g

'  
  ! 
  ' 
  
[
\  [
   


h  j 
 h l    N   ' )     h
[     -  [  '
       '   ' h
    ' )   X !   !  '  
' )  !  
'
g
 [  '  
  X !  '  
)   ) 
  ' - `



 ^

      

'  g

'  
    [  ' [   { [   
     

' X !  )

   
     h l    N )   
  '  g
         !   
   ! 
  '       $ 
   !
  
  ' 
  
[
\  [


g  
    ^
   
 

 
-
`

    ! 
   ) 
   
       u N  
'  g

'  
     {  )  ' 
 B      
  
              N 
X !  N     '   ) 
   
   N
 '   B       )      

 '   ! 
'       '   ^
[
' - `

)       [ )

 N
   '     B  ' ' 
  ' g

'  
  !  )  '   !


)   )     $ 
     

'   

B    

 
 
    
^
d  -  $   '  X !   '   '   
 !       
'     B 
  
h  j N   ! 

'  
  $   
  g    
 

[
      X !   '     
[       X !     N  '    '
    '
   N   [  
'  g
   g  N )

 L       
[  d    ' )   ' 
     '    !
  

    
-
m 
[   ' 
'  '      '  g

'  
  ! 

 )   
  g    
 

  
           
  
   o ) 
   
   
'
    
 
q  '  g

  d
  '  
'  
 o ) 
   
       u q -  ^
         !   
X !     !  '  
' )  !  
' 

' $        
[  ' !   )    
            N
 '   ) !    )
     !    ' )             !  '  ' -
W    [ 
  N  '     '
     d
 !        [
 ^
  N )   [    )   X !    !  
'   
   '
  ^
[  '
)      

   
  \
 
   
    
240 Redes y Comunicación
5
10
15
20
25
30
35
40
70 80 90 100 110 120 130 140
NC
VO
VI
CL
EE
BE
BK
    
   
    
 

 




 !

" #
$
% &
'
0.01
0.1
1
10
100
1000
70 80 90 100 110 120 130 140
NC
VO
VI
CL
EE
BE
BK
( !
 ) *

 !
" +
&
'
    
   
    
0
0.2
0.4
0.6
0.8
1
0.001
0.01
0.1
1
10
100
1000
NC
VO
VI
CL
EE
BE
BK
 

$
!
$

.

 !

/  1   
  4  
5

    6   
  
   
         
  
                
5
10
15
20
25
30
35
40
70 80 90 100 110 120 130 140
NC
VO
VI
CL
EE
BE
BK
    
   
    



 




 !

" #
$
%
&
'
0.01
0.1
1
10
100
1000
70 80 90 100 110 120 130 140
NC
VO
VI
CL
EE
BE
BK
(
!
 )
*

 !
"
+
&
'
    
   
    
0
0.2
0.4
0.6
0.8
1
0.001
0.01
0.1
1
10
100
1000
NC
VO
VI
CL
EE
BE
BK



$
!
$

.

 !

/  1   
  4  
5

    6   
  
   
         
  
     
 8

 ! " $ % ' ) + - + / 1 1 3 ! 4 +  " 1 $ 7 4 - + 8 ) ! : < $ ' ) +
% 1 < $ : )  " 3 / 3 : 1 : : + % 1 $ + : ! + - : + % D E E ( 7 4
< $ " 1 ! " ! < : + H - $ + - + $ / 1 $ 1 !  K : + M 1 ! N
: 1 K 1 - " 1 + % H R S 3 H " + T $ 3  : + % - + ! % 1  + - U V !
 ) 1 % ' ) 3 + $  1 - 7 + - " + 1 !  K : + M 1 ! : 1 ! - + : + - N
< + $ : 3  3 1 7 4 1 ' ) + - + $ R 1 < $ / +  K 1 : < $ + % $ + - "
: + Y
- 7 + ! + - < +  3 1 % < $ % - : + M + - " N +  $ " U
V - " 1  ! ^ 8 ) $ 1  3 T ! : + % - < % 1 ! 3 ^  1 : $ + - $ + - N
< ! : + 1 % H : + % : + ` a + ! ' ) + 7 M 3 + ! - + K 1
^ d 1 : % 1 " 1 M % 1 < $ 1 : + % 1 ! " 1 : 7 M 3 + ! + H ) % 1
+ % + - " 1 : : + % 1 $ + : " $ 1 - ) ! < + $ 3 : " $ 1 ! - 3 " N
$ 3 + ! + % ' ) + - + K 1 ! + - " 1 M % +  3 : % 1 -  ! + S 3 ! + -
4 % 1  ! ^ 8 ) $ 1  3 T ! : + % - < % 1 ! 3 ^  1 : $ + - - + K 1
H : 3 ^  1 : + !  !  $ : 1 !  3 1 U
    :     

           
V ! + - " 1 - +   3 T ! - + H ) + - " $ 1 ! % 1 - < $ + - " 1  3 ! + -
: + ! ) + - " $ 1 < $ < ) + - " 1 1 " + ! : 3 + ! : 1 " $ + - n ! : 3 N
 + - : + ` a  < $ : )  " 3 / 3 : 1 : 7 % 1 " + !  3 1 H + : 3 1 7 4
p ) !  3 T ! : + : 3 - " $ 3 M )  3 T ! 1  ) H ) % 1 " 3 / 1 r t 4 u v : +
% 1 % 1 " + !  3 1 < 1 $ 1 + % < ) ! " : + H R S 3 H 1  1 $ 8 1 U V - N
" 1 p ) !  3 T ! $ + < $ + - + ! " 1 % 1 < $ M 1 M 3 % 3 : 1 : : + ' ) + % 1
" $ 1 ! - H 3 - 3 T ! : + ) ! < 1 ' ) + " + " + ! 8 1 ) ! 1 % 1 " + !  3 1
3 8 ) 1 % H + ! $ ' ) + ) !  3 + $ " / 1 % $ : 1 : 7 + 3 ! : 3 N
$ +  " 1 H + ! " + 3 ! : 3  1 " 1 H M 3 x ! % 1 % 1 " + !  3 1 H R S 3 H 1
M " + ! 3 : 1 U ( - $ + - ) % " 1 : - M " + ! 3 : - - + H ) + - N
" $ 1 ! + ! % 1 - t 3 8 ) $ 1 -
D 4 * U
 + - < +  " 1 < $ : )  " 3 / 3 : 1 : % - : - < % 1 ! 3 ^  1 N
: $ + - < $ < $  3 ! 1 ! ) ! 1 - < $ + - " 1  3 ! + - H ) 4 - 3 N
H 3 % 1 $ + - U ( 1 - a Y - : +  ! " $ % 4 ` a M " 3 + ! + !
" : + % 1 !  K : + M 1 ! : 1 ' ) + + - " R ! 3 ! 4 +  " 1 ! : U
a 3 ! + H M 1 $ 8 7  ) 1 ! : % 1  1 $ 8 1 : + % 1 $ + : + - H ) 4
1 % " 1 % 1 - a Y - : + M + - " N +  $ " M " 3 + ! + ! ) ! 1 !  K
: + M 1 ! : 1 H + ! $ : + % ' ) + 3 ! 4 +  " 1 ! U T " + - + ' ) +
+ - " + 1 !  K : + M 1 ! : 1 + - < $ < $  3 ! 1 % 1 - ) 3 H N
< $ " 1 !  3 1 $ + % 1 " 3 / 1 U u : + H R - 7 < ) + : + M - + $ / 1 $ - +
' ) + % 1 < $ : )  " 3 / 3 : 1 : : + % 1 $ + : ! 1 %  1 ! { 1 + %
D E E ( 7 - 3 " ) R ! : - + + ! " $ ! 1 % < E ( U
( 1 - a Y - : +  ! " $ % 4 ` a M " 3 + ! + ! ) ! 1 % 1 N
" + !  3 1 H + : 3 1 < + ' ) +
|
1 4 + - " 1 M % + 7 3 ! : + < + ! : 3 + ! N
" + H + ! " + : + % 1  1 $ 8 1 : + % 1 $ + : U Y ! + % < % 1 ! 3 ^  1 N
: $ M 1 - 1 : + ! " 1 M % 1 - + M " 3 + ! + ! % 1 " + !  3 1 - H + N
: 3 1 - H + ! $ + - < 1 $ 1 % - a Y -  ! ` a 7 < + $ ) ! 1
% 1 " + !  3 1 < + $ < 1 $ 1 + % " $ R ^  : +  ! " $ % U u : + N
H R - 7 - + M - + $ / 1 ) ! 1  % 1 $ 1 : 3 p + $ + !  3 1 + ! " $ + + %
" $ R ^  : + / n : + 4 + % : +  1 $ 8 1  ! " $ % 1 : 1 : + M 3 N
: 1 % 1 : 3 p + $ + !  3 1 + ! " $ + % 1 - : 3 - " 1 !  3 1 - H R S 3 H 1 -
: + % 1 - + ! " $ 1 : 1 - : + % 1 " 1 M % 1 : + - ) - $ + - < +  " 3 / -
Y
- U Y ! + % < % 1 ! 3 ^  1 : $  3 !  ~ + - " 1 : 3 - " 3 ! N
XVI Jornadas de Paralelismo, JP '2005 241
                      "  %    
  "      ,     %   %    2         6  
     % 9   % :
  < =       2 ? 
 2  2   ?
     2   2  %    2   E         2        
          :

      2    %    2    K            O ?
      %          K     2      2    
% Q R  %  " T U %         W X T U U %       
 9   "    K     2      2     % Q R  %  % Q 
  K  
[
 :
\  2       2    %    2    K    %     ?
        W     %        O          ?
2    `  2      a <    `    2          
2  Q O    2   " ,     2 9       6      ?
  X   2           2  Q O  a < X   2   ?
2  %    2   E          2  Q O    2 ? 
 2 :
d 
e f g
h i j e f m i
\    2  2     ` 6  %        2  %    
  %      %    p <                ?
           r a < s              : t   
   "   ,   ,  %    2  Q O               
      r < =  s " K                      ?
    %   2           O               
 2          K     2  : p <   O          O ?
             O           2         ?
  2   `             2      X        O   
                   6        % 9   %
r     v s : \    2    2 9   6  %  %  2   
 %  O ,              %   2  : p   % Q  "
  K     %          ,     2 9     a <  
           2       %          R  ?
   :

 %         %   2  %    2    
%  2   , 9        2  %      2    %       "
          2      2  Q O X   K   2    
2  % 
[
O ` : t                     ?
2    %     2   6  %        2     % ?
   %   2             O        v K     ?
2   E   2                   K        :

 ?
%     %      2    ,   2 % v   , 6 2   }   
a      , =     2 p ~    r v } a = p s :
      ?
2    %    2    K   "    K    R   2     E     ?
     ,   O  2       2     %   2  %    2  
         O      "  %           
            K     2    a <   K       :
= % 2     ` E  2       2     %   
%  `      %   2  %    2         O   
       2     : \     2 "   2  %    2  ?
       E     2   E  %                ?
   % 
K      ,          K   2     2  % 
[

        X    %           R   2   2     
   ,          2          2             ?
      K     2      6        X   2     :
 m  m ‚ m f g j i
 T  p       < ~  2 6   , ƒ  2      2 <     
ƒ  2     2     :  

         
 
              

       
 
  
 "
   %     U U  :
   } :  : p  E   "  :
: < Q  6  W "     :    ?
2 : a <   ƒ  O            2 ~    :    

 
    

        
           
       " T  r ; s  T U !   " <   2  %     U U  :
   < :      "  :    "  : =      " \ :       "
"
: v   , "    v : v     : p  p  6  2  ?
2    E   
    2   2   <       : ƒ  2     2
  K    2 E  = % %   2  } =     " ƒ  2     2
\  ,        ,     }   "    %    T ; ; :
    :       "  : =     "    < : < 6      : ƒ  ?
2  ,   2   <         2 6  ƒ  2     2 p  6  2  ?
2              ~ : ƒ  2     2   K    2 E 
= % %   2  } = T    " ƒ  2     2 \  ,        ,
    }   "     T ; ;  :
   p :   %    " < : %   6   "    < : < 6      :
p    X         %    2    E  E    K      ,
  ,   2 6 % : ƒ    (   +  , ( ( " T ; ; :
   ƒ \ \ \ : U  : T  ?  U U   < 2       E    
   %  2     2         2 ~    : . 0 0 3 4 6 6
7 8 9 :
3 ;
8 = >
; ; ;
= 9 8 7
6
7 8 9 :
3 A 6 B C D 6 F 6 "  U U  :
   p : % : t     6     :  :      ,   : p ,    ?
    W          6     ,      6 2  ~
 2       2  ,   2            2 ~     2 6 
   ,   ?       :     I   (

 
   
 

J      
" T r  s     !    " T ; ;  :
  < : p :      % " } :  : <  % ?       "
 : <     "     :
X    : p  %       2  
E   
         K     2 X E        
 2 ? 2 6   , 6   2 ~    : ƒ  
      

      
  
  
  
  
 

O
       
   

  
Q
O
  
S
  T V
O
         
   "   ,   T T ! T  "
   %     U U  :
242 Redes y Comunicación
                         !    $     '      * $     -
. / 0 2 4 6 7 2 9 . / 0 2 4 ; = = 2 9 ? / 0 / A 4 C D E F ? / G D F J 2
L M N O P R M S U V X Z \ ] O _ a b L S c d e
f U _ g M Z i _ R b R R M k b l M U a _ b f U _ g M Z i _ R b R o X l _ O p a U _ a b R M k b l M U a _ b
q r b U P t Z R r U b u r g P M i w R r b O X u y b N P r N g P M i
{ | } ~  | 
‚ ƒ „ … † ‡ „ ‰ Š ‹ † ‰  Ž  ƒ † ‰ Š ‡ „  † † ƒ † ‡ … Ž ‰ † ”  … † ‡  ‰
‰ Ž ‰  † • „ ‰ — ˜ ™ † ‰ † ‡ › œ   ‡ † • „ … † ‡ › „ œ  Ž Š Ž  ƒ „ Ÿ
…    ¡ ‹ † Š  ƒ ‰ Ž ‰  † † ƒ „ ‰ Ž £ ƒ „ œ † ¤ Š Ž † ƒ  † • † ƒ  † ‡  ‰
Š ‡ Ž † ƒ  † ‰ ¦ „  „  „ œ † ‰ ¨ Ÿ — ª „ ‡  ‰ ‰ † œ  Ž …  œ † ‰ … † ‡ ‰ Ž ‰ Ÿ
 † • „ ¬ ® ‡ £ ‹ ƒ  ‰ • ¯   …  ‰ › œ  › ‹ † ‰   ‰ › † œ • Ž  † ƒ
„ ‹ • † ƒ  „ œ … † °  œ • „ ‰ Ž £ ƒ Ž ¤ Š „  Ž  „ ‡ „ › œ  … ‹ Š  Ž  Ž Ÿ
… „ … … † ‡ ‰ Ž ‰  † • „ ¬ ² Ž ƒ † •  „ œ £    † ‰  „ ‰ › œ  › ‹ † ‰ Ÿ
 „ ‰ ƒ  Š  ƒ  † • › ‡ „ ƒ † ‡ Š ‹ • › ‡ Ž • Ž † ƒ   … † ƒ Ž ƒ £ µ ƒ
œ † ¡ ‹ Ž ‰ Ž    † • ›  œ „ ‡ ¬
™ ƒ † ‡ › œ † ‰ † ƒ  †  œ „  „ ·    … † •  ‰  œ „ •  ‰ ¡ ‹ † † ‡
› œ   ‡ † • „ … † ‡ „ Š „ ‡ Ž … „ … … † ‰ † œ  Ž Š Ž  † ƒ ‰ Ž ‰  † • „ ‰
— ˜ ™ ‰ † › ‹ † … † „   œ … „ œ … † ‰ … † † ‡ • ¯   …  … † › „ œ Ÿ
 Ž Š Ž  ƒ „ …  ¬ ® … † • ¹ ‰ › œ  ›  ƒ † •  ‰ ‹ ƒ • ¯   …  … †
› „ œ  Ž Š Ž  ƒ „ …  ¡ ‹ † ƒ  ‰ º ‡  › œ  ›  œ Š Ž  ƒ „ ‹ ƒ „ „ ‡ Ÿ
 „ › œ  … ‹ Š  Ž  Ž … „ … „ ‡ ‰ Ž ‰  † • „   ‰ Ž ƒ  ¡ ‹ †  „ •  Ž ¯ ƒ
‰ „  Ž ‰ ° „ Š † ¦ ‰ Ž † ‰ ›  ‰ Ž  ‡ † ª Š ‹ „ ‡ ¡ ‹ Ž † œ ‡ » • Ž  † … † ‡ „ Ÿ
 † ƒ Š Ž „ ¡ ‹ † ‡  ‰ „  „  „ œ † ‰ › ‹ † … „ ƒ œ † ¡ ‹ † œ Ž œ ¬ ½  ‰
œ † ‰ ‹ ‡  „ …  ‰ … † ‡ „ †  „ ‡ ‹ „ Š Ž º ƒ … † • ‹ † ‰  œ „ ƒ ¡ ‹ †
† ‰  † • ¯   …  › † œ • Ž  † „ ‹ • † ƒ  „ œ † ƒ  œ • † • † ƒ  †
† ‡ ƒ µ • † œ  … † „  „  „ œ † ‰ „ ‡  ‰ ¡ ‹ † ‰ † ‡ † ‰ › œ  ›  œ Ÿ
Š Ž  ƒ „ Š „ ‡ Ž … „ … … † ‰ † œ  Ž Š Ž  „ ‡ „  † À ¡ ‹ † Š  ƒ ‰ Ž £ ‹ †
‡ „ • „ Á  œ › œ  … ‹ Š  Ž  Ž … „ … ›  ‰ Ž  ‡ † ¬
Â Ä Æ
 Ç È É Ê ~ Ë Ë Ì Í 
½  ‰ ‰ Ž ‰  † • „ ‰ — ˜ ™ Î „ ƒ † Ï › † œ Ž • † ƒ  „ …  ‹ ƒ Š œ † Š Ÿ
Ž • Ž † ƒ   † ‰ › † Š  „ Š ‹ ‡ „ œ † ƒ ‡  ‰ µ ‡  Ž •  ‰ „ ”  ‰ ¬ ™ ‰   ‰
‰ Ž ‰  † • „ ‰ › † œ • Ž  † ƒ „ • µ ‡  Ž › ‡ † ‰ ‹ ‰ ‹ „ œ Ž  ‰    œ „ Ÿ
 „ · „ ƒ …  † ƒ … Ž  † œ ‰  ‰ † ¡ ‹ Ž ›  ‰ Ž ƒ °  œ • ¹  Ž Š  ‰   Ž ƒ Ÿ
 † œ Š  ƒ † Š  „ œ ‰ † „  œ „  ¯ ‰ … † … Ž ‰  Ž ƒ  „ ‰ œ † … † ‰ ¦ Ž ƒ Ÿ
Š ‡ ‹ Ž … „ Ò ƒ  † œ ƒ †  ª › „ œ „  œ „  „ · „ œ · ‹ ƒ   ‰ † ƒ ‹ ƒ
• ‹ ƒ …   Ž œ  ‹ „ ‡ Š  • › „ œ  Ž …  ¬ ‚ ƒ „ † ƒ  Ž … „ … … † Ÿ
ƒ  • Ž ƒ „ … „ Õ Ö Õ × Õ Ø   Š ‹ Á  † ‰  „ …  † ‰ Š  ƒ  œ  ‡ „ … 
Ù Ú Û Ü Ý Ü Þ ß à ß á â ã ß Û ä å â æ ç ß ç è ä ß å â é â Þ Ý ê ë ì í î à ß á â
Ý ê Ý é ï ð Þ ß ñ Ý î ò ì ó ô ô õ ö ô ÷ ø ù ú ö ì ô û ö ô ú
›  œ † ‡ ‹ ‰ ‹ „ œ Ž    œ † › œ † ‰ † ƒ  „ „ Š „ … „ ‹ ‰ ‹
„ œ Ž  † ƒ † ‡
‰ Ž ‰  † • „ — ˜ ™ ¬ ½  ‰ ‰ Ž ‰  † • „ ‰ — ˜ ™ ‰ † ‹ ‰ „ ƒ „ Š Ÿ
 ‹ „ ‡ • † ƒ  † † ƒ ‹ ƒ ƒ ‹ • † œ  ‰ „ ‰ „ › ‡ Ž Š „ Š Ž  ƒ † ‰    „ ‡ † ‰
Š  •  † ‡ † ‡ † ƒ  œ † ƒ „ • Ž † ƒ   … Ž ‰  œ Ž  ‹ Ž …  ¦ Š Ž  Ž ‡ 
• Ž ‡ Ž  „ œ ª   † ‡ † Ÿ ‡ † „ œ ƒ Ž ƒ £  ‡  ‰  Ž … †  · ‹ † £  ‰ • ‹ ‡  Ž Ÿ
· ‹ £ „ …  œ ¬
½ „ ‰ „ œ ¡ ‹ Ž  † Š  ‹ œ „ ‰  „ ‰ „ … „ ‰ † ƒ ‡  ‰ ‰ † œ  Ž …  œ † ‰
† ƒ œ † … ‰ † Î „ ƒ Š  ƒ  † œ  Ž …  † ƒ ‹ ƒ † ‰  ¹ ƒ … „ œ
… † Ÿ ° „ Š   › „ œ „ ‡  ‰ ‰ Ž ‰  † • „ ‰ — ˜ ™    ¬ ™ ƒ † ‰ Ÿ
 „ ‰ „ œ ¡ ‹ Ž  † Š  ‹ œ „ ‰   ‡ „ ‰ Š  • › ‹  „ …  œ „ ‰ Š ‡ Ž † ƒ  † ‰ †
Š  ƒ † Š  „ ƒ † Ï Š ‡ ‹ ‰ Ž  „ • † ƒ  † „ ‹ ƒ  … † ‡  ‰ ‰ † œ  Ž Ÿ
…  œ † ‰ … † ‡ ‰ Ž ‰  † • „ ¬  ‹ „ ƒ …  ‹ ƒ Š ‡ Ž † ƒ  † • ‹ †  †
‹ ƒ „  „  „ œ    „ •  Ž ¯ ƒ † ƒ  » „ ‹ ƒ • † ƒ ‰ „ · † … † „ Š Ÿ
 ‹ „ ‡ Ž À „ Š Ž º ƒ „ ‰ ‹ ‰ † œ  Ž …  œ   ¡ ‹ † „ ‰ Ž • Ž ‰ •  … †  †
› œ  › „ £ „ œ † ‰  † • † ƒ ‰ „ · † „ ‡  ‰   œ  ‰ ‰ † œ  Ž …  œ † ‰
Á Š ‡ Ž † ƒ  † ‰ ¬ ² † Î „ ƒ › œ  › ‹ † ‰   Š  ƒ Š † ›   ‰ Š  • 
‡ „ ‰ ¹ œ † „ ‰ … † Ž ƒ
‹ † ƒ Š Ž „ ¦ ®  Ò ª    › „ œ „ ‡ Ž • Ž  „ œ
† ‡ ƒ µ • † œ  … † • † ƒ ‰ „ · † ‰ … † „ Š  ‹ „ ‡ Ž À „ Š Ž º ƒ ¬ ™ ‰   ‰
Š  ƒ Š † ›   ‰ … † ¤ ƒ † ƒ ‹ ƒ ¹ œ † „ … †  † Š Ž ƒ … „ … › „ œ „ ‡  ‰
„  „  „ œ † ‰   … † • „ ƒ † œ „ ¡ ‹ † ‹ ƒ Š ‡ Ž † ƒ  † … „ … 
c
¡ ‹ †
Š  ƒ  œ  ‡ „ „ ‹ ƒ „  „  „ œ … „ … 
i
… †  † ƒ   Ž ¤ Š „ œ   Ÿ
…  ‰ ‡  ‰ •   Ž • Ž † ƒ   ‰ … †
i
¦ † ƒ  Ž „ ƒ …  ‹ ƒ • † ƒ ‰ „ · †
… † „ Š  ‹ „ ‡ Ž À „ Š Ž º ƒ ª ‰  ‡ „ • † ƒ  † „ ‡  ‰ Š ‡ Ž † ƒ  † ‰ ¡ ‹ †
Š  ƒ  œ  ‡ „ ƒ „ „  „  „ œ † ‰ ‰ Ž  ‹ „ …  ‰ † ƒ ‡ „  † Š Ž ƒ … „ …
… † ‡ „  „  „ œ
i
¬ ½  ‰ „  „  „ œ † ‰ † ƒ † ‡ ®  Ò … † ‡ „  „  „ œ
i
‰ † … † ƒ  • Ž ƒ „ ƒ Õ Ö Õ × Õ Ø   Ö       … † ‡ „  „  „ œ
i
¬
™ ‡  Ø     Õ "    Õ Ø ×      Õ "   )  ‰ † Î „ … † Ÿ
•  ‰  œ „ …  Š  •  † ‡ › ‹ ƒ   Š ‡ „  † † ƒ † ‡ … Ž ‰ † ”  … †
‡  ‰ ‰ Ž ‰  † • „ ‰ — ˜ ™  „ ‰ „ …  ‰ † ƒ ‰ † œ  Ž …  œ † ‰ † ƒ œ † … ¬
™ ‰  † › œ   ‡ † • „ Š  ƒ ‰ Ž ‰  † † ƒ … Ž ‰  œ Ž  ‹ Ž œ † ¤ Š Ž † ƒ  † Ÿ
• † ƒ  † ‡ „ Š „ œ £ „ … †  œ „  „ ·  † ƒ  œ † ‡  ‰ … Ž  † œ ‰  ‰
‰ † œ  Ž …  œ † ‰ † ƒ † ‡ ‰ Ž ‰  † • „ ¦ „ ‰ Ž £ ƒ „ ƒ …  „  „  „ œ † ‰ „
‡  ‰ ‰ † œ  Ž …  œ † ‰ ª ¬ ™ ƒ ‹ ƒ  œ „  „ ·  „ ƒ  † œ Ž  œ   › œ  Ÿ
› ‹ ‰ Ž •  ‰ ‹ ƒ • ¯   …  … † › „ œ  Ž Š Ž  ƒ „ …  … Ž ƒ ¹ • Ž Š 
› „ œ „ ‰  ‡ ‹ Š Ž  ƒ „ œ † ‰  „ Š ‹ † ‰  Ž º ƒ  ¨  ¬ ™ ‰  † • ¯   Ÿ
…  › œ  ›  œ Š Ž  ƒ „ ‹ ƒ „ ‹ • † ƒ   ‰ Ž £ ƒ Ž ¤ Š „  Ž   … † ‡ „
› œ  … ‹ Š  Ž  Ž … „ … … † ‡  ‰ ‰ Ž ‰  † • „ ‰ — ˜ ™ ¬ ² Ž ƒ † • Ÿ
   
                    "      '
              -       1   3 1   
           '   6     8           
    1    6           >          ? @    '
       1      C             6     
                  3 1   1   3 1    6  '
     1  6        
i
N    1   6      
N            3 1      C      6    
i
    6       ? @          1          
 
T
  T      U V      
            
  1 1              
 1    3 1       '
           X     3 1      C     
       1   3 1             1   6    1   ?
[        ] 
         3 1          
               _     6       1  '
    ` a [   1                      >   '
               ?     >
        1
 >                       1   >    
    ' N  1  e     3 1  1 3 1      ]        '
   f                     
      1  '
  6             g    C               '
      ? @    1         6   1    f    1  '
   3 1      >      1      k    X        '
 1    6                   3 1        '
      >   l        6         3 1  
              _ ?
[             ]        X        1 '
          @      f                
3 1        1              1     _ 
     ` a [ ? @      f n          >   '
  N  1  e       l 3 1    1              '
       _       ` a [ ?       
    '
  f           6   1    f    o 1        '
      >         1    ?        
    '
  f              1    g     ]  o 1 '
 1   ?
 q  
r s

s s u " u v # r w r x u y " r z { u |

z
% r v { ~

u z s r z { v r ' ~ r s x z
[                        _         
 1        ` a [  N         g 
g 
N      1       1                 1 '
       -   
   8 ? €    >      1     X   >   '
  3 1                           
   o        ]      ?      >            
     C          1   f           n '
`              6              k  f
         ? ƒ                       '
   
   _     6                   
             " C   ? _       
  1 
                               '
            ` a [               '
 ]               6    
  l     '
         ? +        
  1        '
  X   3 1             1    "
      " '
                      ? €     ] 
          1     3 1                 g
6 1     -   1  '         g 8        ]   
   1    X    f      6          g    
  -       1  
  1 1           3 1 
              "            ? .   
 1        6       1               '
  f                  _  1  6     ? _ 
     
 1          C             

               3 1                 f ?
[              g 6 1              ] 
 6        1  6           "  1 g     '
                               ? _ 
     1  6        
i
g     1 6  '
           6    
          3 1     
     o         6    
i
      6     '
     1   3 1     6     6       "  "   '
3 1  …  3 1      1      6         
 1   6           ? .     6   1      6   '
      ` a [          1     f -   l
                8
            o   '
  3 1   1                6      6    '
    6      6           _       '
       1  6         ? €  ]         '
C     6        6   1    f     1     
  C  1    ? [   C  1    1         ]   
                          g 6 1    
               ]   6        1
 6        
i
? [   ]         1      
          6      6      
i
       
      6     3 1 
i
?      1            '
            6                    
              1 >   n -   1      
  o      ? @    6     f   "          6   '
   1                       
    l    ? [  o              
fp(i)
-   l        6        1 g  ƒ  ‡         
 6    
i
8       1            1    4 -
            ?
@  C  1     1     3 1                g
6 1              ]   6           6    
i
 1               1     "  6     
244 Redes y Comunicación

            
 
        
     
         %      (   
  +
, - . / 0 2 4 5 -
i
4 - 7 4 / 8 0 7 0 7 4 - : , / 5 2 : - 4 5 / > - : - 0 A - 4 B
C 0 . 2 0 . : - A 2 E F 2 5 - H 2 4 , - : K L - - M 4 / 4 A - H 7 F : 2 P
F 2 : . / 2 0 7
2 R T : - A 7 : 5 2 5 - / 5 7 X , L - M A 7 H - 5 / 2
F 2 : 5 - Z 7 [ 2 5 -   H 4 B \ 7 M 7 , 7 A 7 :
i
4 /   2 H ^ 4
7 , 7 A 7 : - 4 , - . / 0 2 4 5 - M 7 , 7 A 7 :
i
T 5 - L 0 A 2 A 7 M 5 -  
7 , 7 A 7 : - 4 , - . / 0 2 4 \ 4 - 7 4 / 8 0 7 0 7 M H / 4 H 2 4 - : , / P
5 2 : K L -
i
B
- F - A / H 2 4 - M H / 4 H 2 - f F - : / H - 0 A 2
F 7 : 7 , 7 : / 7 4 . 2 0 g 8 L : 7 . / 2 0 - 4 5 / 4 A / 0 A 7 4 5 - : - 7 M / P
5 7 5 , / : A L 7 M X 2 Z A L , / H 2 4 : - 4 L M A 7 5 2 4 H L X 4 / H / P
M 7 : - 4 B C M : - A 7 : 5 2 5 - / 5 7 X , L - M A 7 H - 5 / 2 F 7 : 7 M 2 4
H - 0 4 7 [ - 4 - 0 , / 7 5 2 4 F 2 : L 0 7 , 7 A 7 : 5 7 5 2 7 L H - 0 P
A 7 M / 0 - 7 M H - 0 A - . 2 0 - M 0 m H - : 2 5 - M 2 4 7 , 7 A 7 : - 4
, - . / 0 2 4 7 4 / 8 0 7 5 2 4 7 L 0 4 - : , / 5 2 : 5 / > - : - 0 A - B  2 :
M 2 A 7 0 A 2 E L 0 7 H 7 0 - : 7 > 7 . A / Z M - 5 - F : 2 F 2 : . / 2 0 7 :

2 R 7 M 2 4 7 , 7 A 7 : - 4 - 4 7 8 : L F 7 : 7 , 7 A 7 : - 4 , - . / 0 2 4
A 7 0 A 2 . 2 H 2 4 - 7 F 2 4 / Z M - - 0 - M H / 4 H 2 4 - : , / 5 2 : B
R / 0 - H Z 7 : 8 2 E 7 8 : L F 7 : 7 , 7 A 7 : - 4 - 0 L 0 4 - : , / P
5 2 : F L - 5 - 5 - 4 - K L / M / Z : 7 : M 7 . 7 : 8 7 B C M M 2 7 4 L , - s
F L - 5 - 5 - 8 : 7 5 7 : - M > L 0 . / 2 0 7 H / - 0 A 2 5 - M 4 / 4 A - H 7

E u  E v 7 . / - 0 5 2 K L - 0 2 4 2 M 7 H - 0 A - 0 2 4 - F : 2 P
F 2 : . / 2 0 -
2 R 7 7 M 8 L 0 2 4 7 , 7 A 7 : - 4 E 4 / 0 2 5 / 4 H / 0 P
L X - 0 5 2 5 - > 2 : H 7 / H F 2 : A 7 0 A - M 7 F : 2 5 L . A / , / 5 7 5
X 7 L H - 0 A 7 0 5 2 . 2 0 4 / 5 - : 7 Z M - H - 0 A - M 7 M 7 A - 0 . / 7
F 7 : 7 A 2 5 2 4 M 2 4 7 , 7 A 7 : - 4 B C M H y A 2 5 2 5 - F 7 : A / P
. / 2 0 7 5 2 5 - Z - 8 7 : 7 0 A / s 7 : K L - - M F 2 : . - 0 A 7 [ - 5 -
M 7 L A / M / s 7 . / z 0 5 - M 7   | - 0 A 2 5 2 4 M 2 4 4 - : , / P
5 2 : - 4 - 4 A ^ F 2 : 5 - Z 7 [ 2 5 - M     E 4 / 0 / H F 2 : A 7 :
. L 7 M K L / - : 2 A : 7 . 2 0 4 / 5 - : 7 . / z 0 B ~ 5 - H ^ 4 E - M F : 2 P
F 2 : . / 2 0 7 :
2 R 7 M 2 4 7 , 7 A 7 : - 4 F L - 5 - A - 0 - : - > - . P
A 2 - 0 - M 0 m H - : 2 5 - 7 , 7 A 7 : - 4 H / 8 : 7 5 2 4 5 - L 0 2 7
2 A : 2 4 - : , / 5 2 : - 0 . 7 5 7 - [ - . L . / z 0 5 - M 7 M 8 2 : / A H 2
5 - F 7 : A / . / 2 0 7 5 2 E X 7 K L - F L - 5 - 4 - : 0 - . - 4 7 : / 2 H / P
8 : 7 : 8 : 7 0 . 7 0 A / 5 7 5 5 - 7 , 7 A 7 : - 4 B C 0 - 4 A - 4 - 0 A / P
5 2 E L 0 A : 7 Z 7 [ 2 : - . / - 0 A - 5 - H L - 4 A : 7 K L - 0 / 0 8 m 0
H y A 2 5 2 5 - F 7 : A / . / 2 0 7 5 2 - g . / - 0 A - 5 - Z - H / 8 : 7 :
H ^ 4 5 - M u   5 - 7 , 7
A 7 : - 4 - 0 - M R / 4 A - H 7
  B  2 :
A 7 0 A 2 E - 4 A 2 4 A : - 4 7 4 F - . A 2 4 5 - Z - 0 4 - : . 2 0 4 / 5 - : P
7 5 2 4 F 7 : 7 F : 2 F 2 : . / 2 0 7 :
2 R 7 M 4 2 M L . / 2 0 7 : - M
F : 2 Z M - H 7 5 - M 7 F 7 : A / . / 2 0 7 5 2 B
   
‚ ƒ „ ƒ „ … 

† ‚ ‡ ˆ ‡ ƒ ‰

„ ƒ
 7 : 7 F : 2 F 2 : . / 2 0 7 :
2 R E F L - 5 - 0 7 F M / . 7 : 4 - 5 / 4 P
A / 0 A 7 4 A y . 0 / . 7 4 H - A 7 P v - L : Š 4 A / . 7 4 B C 0 L 0 A : 7 Z 7 P
[ 2 7 0 A - : / 2 : E F : - 4 - 0 A 7 H 2 4 L 0 - 4 A L 5 / 2 . 2 H F 7 : P
7 A / , 2 - 0 A : - 5 2 4 A y . 0 / . 7 4 5 / > - : - 0 A - 4  L 0 7 A y . P
0 / . 7 H - A 7 P v - L : Š 4 A / . 7 - , 2 M L A / , 7 E M M 7 H 7 5 7    

 Œ    Œ        E X L 0 7 A y . 0 / . 7 H - A 7 P
v - L : Š 4 A / . 7 . 2 0 4 A : L . A / , 7 E M M 7 H 7 5 7  Ž   ! Œ 
    $    Œ      Œ Ž  '  ) +  -

 Œ Œ  Œ   Ž  Œ
Œ  Œ   Œ    Œ    !   / 
0  B  L - 4 A 2 K L - v - H 2 4
2 Z A - 0 / 5 2 L 0 > L 0 . / 2 0 7 H / - 0 A 2 H - [ 2 : - 0 M 7 4 2 M L P
. / z 0 5 - - 4 A - F : 2 Z M - H 7 F 7 : A / . L M 7 : . 2 0 M 7 A y . 0 / . 7
5 - M 1
~ R  E F : 2 F 2 0 - H 2 4 y 4 A 7 . 2 H 2 H y A 2 5 2 5 -
F 7 : A / . / 2 0 7 5 2 F 7 : 7 F : 2 F 2 : . / 2 0 7 :
2 R - 0 M 2 4 4 / 4 P
A - H 7 4  ‘ C B
3 4 6 4 8 : ; < = ? ; A B D F G = A F A
 7 5 7 F 7 : A / . / z 0 T 7 4 / 8 0 7 . / z 0 5 - . M / - 0 A - 4 7 M 2 4
4 - : , / 5 2 : - 4 \ 5 - M 4 / 4 A - H 7 4 - 7 4 2 . / 7 7 L 0 7 > L 0 P
. / z 0 2 Z [ - A / , 2
F
E 5 - 0 2 H / 0 7 5 7 J

  L   Π  
 Π E K L - 7 4 / 8 0 7 L 0 . 2 4 A - 7 . 7 5 7 4 2 M L . / z 0 F 7 : P
A / . L M 7 : B “ 7 A y . 0 / . 7 H - A 7 P v - L : Š 4 A / . 7 5 - Z - - 0 . 2 0 P
A : 7 : L 0 : - F 7 : A 2 . - : . 7 0 2 7 M z F A / H 2 . 2 0 - M , 7 M 2 :
H ^ 4 Z 7 [ 2 5 -
F
K L - 4 - 7 F 2 4 / Z M - B “ 7 > L 0 . / z 0 2 Z P
[ - A / , 2
F
5 - Z - . 2 0 4 / 5 - : 7 : M 2 4 A : - 4 > 7 . A 2 : - 4 5 - P
4 . : / A 2 4 7 0 A - : / 2 : H - 0 A - F 7 : 7 F : 2 F 2 : . / 2 0 7 :
2 R
7 M 2 4 7 , 7 A 7 : - 4  - M F 2 : . - 0 A 7 [ - 5 - L A / M / s 7 . / z 0 5 -
M 7   | - 0 A 2 5 2 4 M 2 4 4 - : , / 5 2 : - 4 E - M 0 m H - : 2 5 -
M 2 4 7 , 7 A 7 : - 4 K L - H / 8 : 7 0 X - M 0 m H - : 2 5 - M 2 4
7 , 7 A 7 : - 4 7 M 2 4 K L - 4 - F : 2 F 2 : . / 2 0 7
2 R B  - H 2 4
5 - g 0 / 5 2 M 7 > L 0 . / z 0 5 - . 7 M / 5 7 5
F
. 2 H 2
F(P) = Ψ(P) + Φ(P) + Γ(P)
T  \
5 2 0 5 - - M A y : H / 0 2
Ψ(P)
- , 7 M m 7 - M F 2 : . - 0 A 7 [ -
- 4 A / H 7 5 2 5 - L A / M / s 7 . / z 0 5 - M 7   | - 0 A 2 5 2 4 M 2 4
4 - : , / 5 2 : - 4 F 7 : 7 M 7 F 7 : A / . / z 0
P
B “ 7 , 7 M 2 : 7 . / z 0
5 - - 4 A - A y : H / 0 2 4 - Z 7 4 7 - 0 - M H y A 2 5 2 5 - . 7 : 7 . P
A - : / s 7 . / z 0 F : 2 F L - 4 A 2 - 0
 B C M A y : H / 0 2
Φ(P)
- 4
/ 0 , - : 4 7 H - 0 A - F : 2 F 2 : . / 2 0 7 M 7 M 0 m H - : 2 - 4 A / H 7 5 2
5 - 7 , 7 A 7 : - 4 - 0 M 7 F 7 : A / . / z 0
P
. L X 2 4 H - 0 4 7 [ - 4
F : - 4 - 0 A - 0 L 0 : - A 7 : 5 2 H - 5 / 2 5 - / 5 7 X , L - M A 7
XVI Jornadas de Paralelismo, JP '2005 245
      
                       
      # $     ( $   *         . 0 $  *  
3    *        8     0    3   #    0      
3     *  >      *    0       0  #      B 
     *        0       *      C  *     
 
Γ(P)
   *  >       0        B    
        0   3   *  3    # E 
P
     #  * # $ 
*               $  * H   *    B   # E   #  $  *
. *    B   # E   M   3   *  3    # E 
P

 * #   3          
Φ(P)
   0         
3   3   #    *  *  >       0       # $ .      
  8    $       $          . 0 $  *  
         
               0  * > 
 *         . 0 $  *   3    *        8  
  0    3   #    0       *         .
0 $  *       #  $  * 3    #    0        
3    *  3    # E   #  $  * C .       0  *      
      *         . 0 $  *      ( $  #  
  0         `   *  3    # E 
P
C #        
 ( $     `     *  # E  *    * #    *  >     
*    0       0  #      B      *        0 
   a        C *   $  # E 
hasr(i)
  B   $ 
0  *    *  3    # E 
P
3    #    0     C  3   
    * 0  *         
Γ(P)
     c   $    $  # E    0  * $  # E 
#   3 $     3       # #              M 
#     C  *       3    #        c   
B     `   $     #   *    0      
     
*       C  * #   3           *   $  # E  
 0  * $  # E 
Γ(Pp)
   * ( $     $        * 
M B $   
Γ(P)
    $     # # E  *    *   
 #    h     $     #   *    0        i  
       a     3 $    h  #     c  C
Γ(P)
   
$  #   3          3    c E * #   j  k C # $     
 `   0        B      *  3    # E 
P
C   .  
  *  3   c  c *   ( $ 
P
      # h   

           
   3       *  c >  ( $     j m  #     *
      3    #        3 *    3    3   
3   #    
 m  *    0        n  c >  ( $  
  j m  .    h   0  * $   .   h  #   3    
 #   *        #  #       h  $  k   #   3 * #  
      3   c *      3  # k M # 
  C . h  3   
3   #     *     8        $ *      n    #  
#    j m  #     H  #   $   3    # E   #  * 
    3    # E   #  *   3   3   #         
*    #  #   c  *   #    #   B  3   3 $      

s   j  k C       B $       ( $  *  3    # E 
 t u v w x    v y z t  y
Γ
{
 #  *    ` c     ( $ * c    .     *      0 
       B   $  3   #     8   *  $  * H  # E 
 *    }    c  8  #       3   c *   m    
c   B  C  * B $     0       3 $        # c 
 m
      3    # E   n *  B         3 $    C  
$  * H   `  *        j m  3    c $  #   $  
3    # E  3   $   E 3    ( $  3   3   #   
 m
 *   .    >       0       3   c *   *   
     3  ( $   B    *  k     >     
 0         * 3     3      *  3 $       3  ` # 
 #   *   j m  #         # *   M #        
    #       € 3    $   #     3      # 
fp
*    0       ( $  # $ .        8    $      
$          . 0 $  *     .   
   
      0          c     
 m €  n     
3   3   #    
 m  *    0       ( $    ( $   
          $   H    *        n    0      
#    *   #     `   *    3      #   c       
#   c        8     #  $  * H  # E  #    $ # h  
 0           *       C *   B   # E       
 0        *    0    3   3   3 $      $ 
 *         . 0 $  *    *        8   3   
 *  >      ` i     0       3   c *   3 $  
3   3   #    
 m   $ # h    0       #    *
        $   H  €         3     C   *     
  j m    #        *             # *    
 0       C 3 $      $   B  M #   0       * 
 $  # E  
Φ
  $   $       B  M #   0  
*   $  # E  
Γ
 n   3        *       
c
  * 
# *   M #  # E    0         $   3  c *  # E  
 0       
n
€    M    #     ‚  ƒ  „ 
„  ƒ  

  *        j m  #       #     
  B      *    0       #  k  #   C         `
246 Redes y Comunicación
                               &
'      ) + ,    /     
n
 /    4   6     
'  7   
e
9 : 9 ; 9 =


 
 >     
n = c+e
?  
   @           >    7   '            
7   7             G         '  7   /  +
   /   '  M    7 O /      P )
      
     /    '  T /  '   + ,  V 7       /   &
'      4   V 7       /             ?  
 V   '    @ 7  /       6 Z        [ /     
   7 O /      P )
+
   /   '  M    7 O /      P )
'      / 
          '    /   ' '  M  a c V      ' +
d G        ; =

     '    /   a       &
'  M  G ' /  c             /  '  T /  '    
'   /   '  M  > a    



 9  9        &
/    '  M  /  7               '   /      
  '     + d     /     @ ' /  '   /   
c V       P )
  '   /   '  M    7    &
/       +   j  7     '       /    '    '  M 
 T   c     7  / '           '   +     
 7 O /      P )
' c >       /      
  /  '  M  '          G   '  M    '   
F
 7 @  M  /  7      c  +
 o 

 
p

q r s t v w  x w y z

q r | t w y

      7      '  M         /  7 
   O   '   ~  , /   O      7  '  M  + d
7  /      T      '  M       c   
    / @          '       7       &
/         /       /   c      > /   '  7   ‚ &

P   > ~ ‚ ) 
 a d P  
 +  7         &
    j    7    /     7  '  M    7   &
  '  7    / 7    /         /  7    O   &
'  ~  ,   /                          /   &
'    ' /    > a j  7      ƒ     /       [    &
 7   /          G   '    7    /   
/ O '   '        / + ,  '    7  '  M  >  
 /      '  7   /   7   7 P  ‚   /   &
' 7 c   7    Z       /  6 '        '  M   
 7        /  … ~ + d   /   ' /     7   &
 Z     : 9 ; 9 =  9 ; 9    ;         '  6 ' &
    ~ ‚ ) 
 + †    7  '  M  '      /     
'   /     ƒ 
7    7    /   > '    
G   '    '      7    7    /  '           +
    ƒ      / 
i
   ƒ   7    7    &
/  >  '    /    '   /  
i
   T   7    Z 
'     7  ' /  7      '    /     '   &
/       /      '      
i
+ ,  /        &
     7    Z  P   '    /    '   /  
i
+
       7  '  M  ' c > '  '  7   /   
       /   7       /        a    /
7       /       7    Z            &
  /    7  '  M  + ~  6   7     /     7    
     /     4 '  7   /    '    /  ?
i
'  7 
asri
4 =
 


 ; 9 
  9 
   ;
 9  
  / 
i
? + )     /             Z > a
     7   7  '    /    '   /  
i
    &
‰    7  '  /  7      /  /     '  '  &
7      '    '  7    /  P   +
      '  7 &
   j  7     7     7 O /        /  '    &
         /      ' '  M   /      4   P )
? >
a  7 O /        /  '      P d         /   
 …  4  7 O /        /  '              '   
  /  '  M     '     7 O /      P )
? +
 7     7       /  7  ~  , '   /      G   &
  /    /        7    7    /     /    
&
/  M    ' 7 c   '   '   4    '    j     

/ /    ?     >  / &
   /  & P d d 4
P ?     a
/ 7 c  O   / &
   / &    4
 ?   …  +  
'   &
       /        /       7    
   /    7      '   '   7   /  > '  7   ƒ  &
  a /   7        7   7  '  ƒ '  M  +

P '           [   /   '    /  
!
   /  
'    /  
!
     /        /      '   ' 
7 @      /   7 @  /    +    7   /  >

/ 7 c  O  '          /      /   '    /   >    
  7   /     /      /        /      
         '   '    /      /   + †   / &
  '  M       /  M    7    7    /     '   &
   /      /        /         /  7   &
 '        7    7    /  + P   7 @  >   j  '   &
          /   /     /   c  '         '     
 /       7        /  4    G   7  >    &
   a   '  7   ? > '  7     /      /     
  >    + ,  6         …   7    / 
   /   c  '  M  6       /        7    
   /   & ~     /    /        7    7    / 
    '       /  '  M     '     G   7 
   /    + ,    / 6    >  7        / 
    '      a      /              /
'   /  +
, 7 O /    P d  a  7 O /      P )
  j 
 Z  '  /   '    ƒ      /   '  M  ' c a
 /   ƒ '  M    
†   '             
'  ƒ 
  + P   7 @  >       '  /  &
     /          '        )    
 /   '  M  + , 7 O /      P )
   Z  '  /   &
XVI Jornadas de Paralelismo, JP '2005 247

  



  
  
               
  !      # ! 
#
   ! * * ,    , .    
 ,   
  !    
  
  
 


  
5 !  #  7
8 : < = 8 > @ A B > B E F @ G B A E H I 8 E @ 8 F @ : B G M N @ F G O > E 8 P
N E I < R @ : O G > @ U B V O > @ W Y B W O G Z < B G > B > O \ : B G B
B < N @ I F B G W B O ^ > @ I < @ Y O ` a @ U E > O B W E N P
E F B A E O I @ 8 > @ @ 8 : B A E O \ @ I @ W : G @ 8 @ I F @ F G B U B P
V O N O 8 F G B G @ N O 8 8 O W B N @ I F @ W O 8 G @ 8 < W F B > O 8 : B G B
W B 8 A O N U E I B A E O I @ 8 N M 8 G @ : G @ 8 @ I F B F E Y B 8 > @ : B P
F G O I @ 8 > @ N O Y E N E @ I F O R > E 8 F G E U < A E O I @ 8 E I E P
A E B W @ 8 > @ B Y B F B G @ 8 ` m W G @ 8 F O > @ W B 8
A O N U E P
I B A E O I @ 8 : O 8 E U W @ 8 > @ : B F G O I @ 8 > @ W N O Y E N E @ I F O
R > E 8 F G E U < A E O I @ 8 E I E A E B W @ 8 > @ B Y B F B G @ 8 : G O : O G P
A E O I H G @ 8 < W F B > O 8 N < R 8 E N E W B G @ 8 B W O 8 N O 8 F G B P
> O 8 B s < t : B G B A B > B A O I u Z < G B A E H I > @ a x m `

@ N O 8 : G O U B > O < I B Z G B I A B I F E > B > > @ A O I u Z < P
G B A E O I @ 8 > E { @ G @ I F @ 8 > @ a x m `  O O U 8 F B I F @ \ : B G B
N B R O G U G @ Y @ > B > \ : G @ 8 @ I F B N O 8 @ I @ 8 F @ F G B U B P
V O > O 8 @ ~ : @ G E N @ I F O 8 G @ : G @ 8 @ I F B F E Y O 8 \ > @ I O N E P
I B > O 8  m a  €  R  m a  € 
`  m a  €  \
A O N O G @ : G @ 8 @ I F B F E Y O > @ W O 8 N < I > O 8 Y E G F < B W @ 8
: @ s < @ ‚ O 8 \ 8 @ A O N : O I @ > @
  B Y B F B G @ 8 R > @ ƒ
8 @ G Y E > O G @ 8 \ R  m a  € 
\ A O N O G @ : G @ 8 @ I F B F E Y O
> @ W O 8 Z G B I > @ 8 8 @ A O N : O I @ > @    B Y B F B G @ 8 R
> @  8 @ G Y E > O G @ 8 `  U F < Y E N O 8 G @ 8 < W F B > O 8 N < R
8 E N E W B G @ 8 @ I F O > O 8 W O 8 @ ~ : @ G E N @ I F O 8 s < @ G @ B W P
E … B N O 8 A O I O F G B 8 A O I u Z < G B A E O I @ 8 > @ a x m ` m W
: B G M N @ F G O
c
> @ W N = F O > O   ˆ ^  8 @ u V H @ I < I
I Š N @ G O H : F E N O > @ B Y B F B G @ 8 A G t F E A O 8
c
> @  
R
 : B G B W B 8 A O I u Z < G B A E O I @ 8  m a  €  R
 m a  € 
\ G @ 8 : @ A F E Y B N @ I F @    `
ΠB F B U W B N < @ 8 F G B W O 8 G @ 8 < W F B > O 8 > @ W B
@ Y B W < B A E H I > @ W { < I A E O I B N E @ I F O O U F @ I E > O 8 : B G B
W B A O I u Z < G B A E H I  m a  €  A < B I > O W B 8 : B G P
F E A E O I @ 8 : G O : O G A E O I B > B 8 : O G > E Y @ G 8 O 8 N = F O > O 8
8 @ 8 E N < W B I U B V O
A O N U E I B A E O I @ 8 > @ : B F G O I @ 8
> @ N O Y E N E @ I F O R > E 8 F G E U < A E O I @ 8 E I E A E B W @ 8 > @
B Y B F B G @ 8 
 ˆ R > E 8 F G E U < A E H I < I E { O G N @ Ž
 ˆ P
€ I E {  R : B F G H I
  8 O U G @ > E 8 F G E U < A E H I E I E A E B W
A W < 8 F @ G @ > Ž
  P  W < 8  `  B G B A B > B A O N U E I B A E H I
> @ :
B F G H I > @ W N O Y E N E @ I F O R : B G F E A E H I E I E A E B W > @
B Y B F B G @ 8 \ W B F B U W B : G @ 8 @ I F B > O 8 A O W < N I B 8 \ < I B
: B G B A B > B < I O > @ W O 8 N = F O > O 8 > @ : B G F E A E O I B P
> O A O I 8 E > @ G B > O 8 \ ˆ Œ  R   ˆ ^  Ž    ` Œ B 8
: G E N @ G B 8 F G @ 8 u W B 8 \ @ F E s < @ F B > B 8 A O I ^ ~ \ N < @ 8 P
F G B I @ W : O G A @ I F B V @     > @ < F E W E … B A E H I > @
W B   € B W A B I … B > O @ I A B > B 8 @ G Y E > O G > @ W a x m
> < G B I F @ W B 8 E N < W B A E H I A O I A B > B N = F O > O > @ : B G P
F E A E O I B > O ` ΠB u W B 8 E Z < E @ I F @ N < @ 8 F G B @ W Y B W O G
N @ > E O > @ ˆ ^  Ž @ I N E W E 8 @ Z < I > O 8  : B G B W O 8 N @ I P
8 B V @ 8 @ I Y E B > O 8 : O G F O > O 8 W O 8 B Y B F B G @ 8 > < G B I F @
W B 8 E N < W B A E H I ` Œ B : @ I Š W F E N B u W B N < @ 8 F G B @ W
I Š N @ G O > @ B Y B F B G @ 8 s < @ : G @ 8 @ I F B G O I < I G @ F B G P
> O > @ E > B R Y < @ W F B N @ I O G > @
  N 8 ` m 8 > @ A E G \
@ 8 F B u W B N < @ 8 F G B @ W I Š N @ G O > @ B Y B F B G @ 8 B W O 8
s < @ 8 @ W @ 8 : G O : O G A E O I B O ^ @ I A B > B N = F O > O > @
: B G F E A E O I B > O `  E I B W N @ I F @ \ W B Š W F E N B u W B N < @ 8 P
F G B @ W I Š N @ G O > @ B Y B F B G @ 8 N E Z G B > O 8 : O G A B > B
N = F O > O > @ : B G F E A E O I B > O > < G B I F @ W B 8 E N < W B A E H I `
 < B > G O   @ 8 < W F 8 { O G  m a  €  a x m A O I u Z P
< G B F E O I
 ! # $ & ' ) +  ! , $ - / 1 2
ˆ Œ    ˆ Œ   
^ 

 

^





^



ˆ Y ` ˆ ^ 




O ^ 
ƒ  
ƒ 
 E Z G `


ΠB F B U W B N < @ 8 F G B s < @ : B G B W B A O I u Z P
< G B A E H I  m a  €  B N U O 8 N = F O > O 8 @ Y E F B I
W B 8 B F < G B A E H I > @ W 8 E 8 F @ N B a x m \ : < @ 8 F O s < @
I E I Z < I O > @ W O 8 8 @ G Y E > O G @ 8 B W A B I … B @ W  
> @
< F E W E … B A E H I > @ W B   € ` ^ E I @ N U B G Z O \ W O 8 Y B W P
O G @ 8 N @ > E O 8 > @ ˆ ^  O U F @ I E > O 8 A O I @ W N = F O > O
  ˆ ^  8 O I 8 E Z I E u A B F E Y B N @ I F @ N M 8 U B V O 8 s < @
W O 8 O U F @ I E > O 8 A O I @ W N = F O > O ˆ Œ  : B G B B N U O 8
: B F G O I @ 8 > @ W N O Y E N E @ I F O ` m I @ W A B 8 O > @ W : B F G H I
> @
  \ @ W Y B W O G N @ > E O > @ ˆ ^  : G O : O G A E O I B > O
: O G @ W N = F O > O ˆ Œ  @ 8 F M A @ G A B > @ W W t N E F @ > @
 
N 8 ` \ R @ W > @ W N = F O > O   ˆ ^  @ 8 N < A ’ O N M 8 U B P
V O ` m I F = G N E I O 8 > @ A B I F E > B > > @ B Y B F B G @ 8 B W O 8
s < @ 8 @ W @ 8 : G O : O G A E O I H O ^ \ @ W N = F O > O : G O : P
< @ 8 F O B < N @ I F B A O I 8 E > @ G B U W @ N @ I F @ @ 8 F B N @ > E > B
248 Redes y Comunicación
                   ! "  $ % $ % (
   *        -    %   %       
$ 7    8      7 * $   %   *    (     %   <
  ! (    *   %  B      %  * E        $ % $ (
  *  $    $ % $ %    % -    %   %  

     $ 7    8    K    %  * $  %   *   * (
 * $   %   *           B    E       
$ % $   *    R %   S *  K    %  * E       
! "  B    R %   S *   V      $ 7    8 
W )    K    %  * X  %         *       8    %
     B 1 ! -   *  S   \ *    R %  %  S *  
V      $ 7    8       E    %  \    8 
*   $         7 ` * E     "    7   )
   *  %   * %  *     * 7     * $  %      (
c R  %   8   d e g )   *     7            * (
  %    E       7    B $  %    *  %   *
%  *     * $  %    i *  % K  %  *  " * %  *     *
$ %  *     *    *     7   % %  * $      $  (
 % 8     K              $  %    8 
          %     K    %  * W    ( g    X  * n
   $   % 8    !     $  %    8       
*  * R     K    %  * W   ! ( *   X 
   % )   *    *  %  d e g ) d o   c R (
 %    
   
        
! "  1 ! "  1
-  W  X
0
  

-  W  X

0

0
- ) W  X


0   
- V W  X

0      
-  W  X


  
-  W  X
0
  

-  W  X


0   
- 0 W  X

  

- W  X

0      
-
W  X

0

! - ) 0
) V    ) ) 

- )         )  
 R %     V
  V ) 0 
"    7   )    *  %  E        *   $   % 8 
     *  *      %  7  \ 8 $ %  7  \  *  $   (
  *    %   8  < E      S p         i   8 
   g     *  $  %  %  
      R ` 
*  % K  %  -     7  % R $  %     *   $   % 8 
  !   *  *      %  7  \ 8 7  \ * 
  %   8  B < * (
       *  $ %  \  %  )     %     *     * 
E     *  *     *    $ *  %   7          % (
R    %  7  \ $ %    $ %  *  K    %  *    % 
 *   $   % 8    K       *      %   *
 * K   %  * $  %    * )     %     *     % 
  * $  %  % B $  %   *   $   % 8    K      
K  %  * *  % K  %  *     i  %            (
  i   8       g    7 *    * 
"    7   )    *  %    *   < %  *    %   (
  *                %   * *    (
*  $  %       *   %  *       K  (
     B  * K   %  *    *  ! - $ % $ %    (
* $ %   7 *    * $ %  *         %     *
*  R      K  * $  %    $   % 8     B <      (
1 ! -   *     <   *   K   % x  *       (
    K   % $ % $ %    $ %     
! "       *   $   % 8     !   *  *
%  *     *     *  %   E         < %  *
   % R    %  7  \ * $ %    $ %   *  *     B
  < %  * *    *    %     *            
   %   * *    *  *   %  *      % (
   *    `   %   K    %  *   * E   * 
$ % $ %   8 - B      1 ! -     7   
$ %  *             *  R   c    K       (
1 ! -  7   $ % S            `   % 
 K    %  *  - $  %   * $   %   *    
<    !   *  * %  *     *    *  %   E    
   $ % $   *  $           %    `   %
  K    %  *   * E   *    * $ % $ %    -
 * 8       *      * $ %   $   % R  B
*      7         *  *      %  7  \    (
   *  *    %   8            B    `   %
   R %     *      R     *    *  *
  < %   V      $ 7    8    *  * %  *     (
* K           1 ! -     
 $  %       $  i  $ % $ %    % - 
      `   %   K    %  * 

{ 
| } ~

 €  | } ‚ €   ƒ


 
|   „  ƒ |
    $ %  *      %  7  \ B x   * $ % $   *   
    $  %      $  %   * *  *     * d o 
7  *                ( x   % n *    E  
7  *      \ %  $ %   *    %           B
  $ %    K     *  *     <    c      
$  %      
XVI Jornadas de Paralelismo, JP '2005 249
                        $  &
    '       '       -    ' 0     3   3 &
     3     '            '  3     :  < 
  3               >         3    :  C E
 '   '     ' 3  3       '      H '   
             -       3   3      
 K L
M O   3                   '   '         
3   '              O    ' 3               
3    '                        '  &
        L U      '    W       '  3       &
  X   ' Y   Y 3             W E          
         
 K   '      '       O  &
]       L
 '    3    :  $      `        :  <  W
  3     '            3            
               0  '       $    
       
f(P)
L      ]              
$       3                E           
3     '  <      $      '       ' 0   &
    3           L           W   3   &
3   '      3     ' 0     3   3        
]   3   '       $        '           ' 3  &
    3                    L
i j
j k j l n o

p

  K L K  O q     L  E   W   r   s     s
r


t   u  s      r  L M       W 


L

   L      W  L  L      W  L    Y   X W
   L U     W    q   q         X      $
      :                '    E    '  W 



s   t s          ! "  W M  L
K 3   O   & w    O W    x W 3 3 L  
 %  
L

x   L      W  L  L     y  W  L    Y   X W
   L U     W  M    3        :    &
 O    q  -   $         :              &
  '    E    '  W    s   (   *  r  (     (
      W { M K | U L M M      W    x W
3 3 L    %    L

   L q  


   W U L         W    L   &
    ' W  |     '   $   3   $   '  O   &
 :              :                &
'       q -   W    s       
   r  
*  r  s  t r    t       s        t s t     t  
   r s 


r     r     *         L { | | |
 ' 3     K      E W     W 3 3 L    %   L

  L          K L  q     W       


 
O  '     -   &          3 3       $   -   &
              0    s 
     
   r  
  2 *   4 2 2     L M       :
M  K {     W    x W 3 3 L    %    L

   L     U L   W  M     :   E  '  
         :       q  '  $   '    &      
      :                '    E    ' 
   q q  O q E & 


              :     W  
 s       
     <     L M  W    x W
3 3 L    %   L

   L      W  L  L     y  W  L    Y &
  X W    L U     W  M   ' 3          E
 $ '    q            q  -    $   3       O
-                 E    '  W   *  
     B      B B L K 3   O   & w    O W
    W 3 3 L    %    L

  {  M W E *   
  r 2 t  t
    r "    G
 t r    W     L


 { | | | W I  ! J ( I * r t   t s    s
   r s 


r   *  r  s t  r  u   


 t r   
 " "    t r     s  r         *  W 

 L

    L   q W  L N    q   E W    L U  q '  W
 s  t r  
   "


r  s  


 t r      r    O
  *  r s  


 r    r  r   Q 
   u    s   
r   r


s  L        &     W 


L

    L         W K L M     W L  E   W  
L        


W  M '             q        
$         :            


 q    O q W  
 s       
     2   <    W     L

    L L     q  O q W  M  E   O '    '  
                           E
   &   $      O W    s       
   
 S  " ! W 

 L

 x   L     <       W  L  L w       W U L    &
   W   { L    


W  M 3 3        $
 '    &           :                &
'   $   '    


  '  :     :       3 &
           q        W  2 t      *  r  
 
    V    r      r s   W   L  W  L  W
3 3 L   %   W 


L
250 Redes y Comunicación
                              %  (   +       
/
  1     3    7 1 8   : ( +  >
? @ A C D F G I J @ K M N P R R M I T @ K @ W N F C Z G T @ [ C G ] M
_ ` a b c e ` f h i k m o p b r t u _ f v w x
y h r z ` m | r e u e e `  u € ` h t r u y h r z ` m | r e u e ‚ k € r b ƒ t h r t u e `  u € ` h t r u
„ … u h c † m e … h u ‡ … z c ` | ˆ e … u b k ‡ Š u a c … a z c ` |
‹  Ž    ‘
’ “ ” “ – — ™ š › œ  › ™ – “ ” ž “ ” “ Ÿ “ ” œ ¡ – œ Ÿ œ ”  £ š œ ¡ › œ ¤
” œ – ¥ š Ÿ ¦ – ” œ § “ ¡  ¦ ¡ ¥ œ – › š Ÿ ¦ œ ¡ œ £ œ ” › « ¡ Ÿ “ – Ÿ œ ¤
¬
“  › ¦ ­ “ – “ £ ¦ ” ” š ” › œ ¯ “ ” Ÿ œ ± ¡ › ¦ – ¡ ¦ ” ² š – › ™ “ £ œ ”
³ š ” › – š ž ™ š Ÿ ¦ ” ´ ³ ² ± µ ¶ ± ” › ¦ ” ” š ” › œ ¯ “ ” ­ œ – ¯ š › œ ¡
— ™ œ ™ ¡ “ ¯ š ” ¯ “ œ ”  œ ¡ “ ¥ š – › ™ “ £ · ³ ” œ “  ¦ ¯ ¤
­ “ – › š Ÿ “ ­ ¦ – ¸ – “ ¡  “ ¡ › š Ÿ “ Ÿ Ÿ œ ™ ” ™ “ – š ¦ ” – œ ¯ ¦ ¤
› ¦ ” ¶ ¹ “ – “ — ™ œ ™ ¡ ” š ” › œ ¯ “ ³ ² ± ­ ™ œ Ÿ “ ­ – ¦ ­ ¦ – ¤
 š ¦ ¡ “ –  “ £ š Ÿ “ Ÿ Ÿ œ ” œ – ¥ š  š ¦ ¼ £ ¦ ”  £ š œ ¡ › œ ” Ÿ œ £ ” š ” ¤
› œ ¯ “ Ÿ œ ž œ ¡ “ ” š ¸ ¡ “ – ” œ “ £ ¦ ” ” œ – ¥ š Ÿ ¦ – œ ” › œ ¡ š œ ¡ Ÿ ¦
œ ¡  ™ œ ¡ › “ › “ ¡ › ¦ £ “ ­ – ¦ Ÿ ™  › š ¥ š Ÿ “ Ÿ  ¦ ¯ ¦ £ “ £ “ ¤
› œ ¡  š “ Ÿ œ £ ” š ” › œ ¯ “ ¶ ± ” › œ ­ – ¦ ž £ œ ¯ “ ” œ  ¦ ¡ ¦  œ
 ¦ ¯ ¦ œ £ ­ – ¦ ž £ œ ¯ “ Ÿ œ £ “  “ £ š Ÿ “ Ÿ Ÿ œ ” œ – ¥ š  š ¦ ¶
± ¡ œ ” › œ “ – › Á  ™ £ ¦ ­ – ¦ ­ ¦ ¡ œ ¯ ¦ ” ™ ¡ “ ¡ ™ œ ¥ “ š ¯ ¤
­ £ œ ¯ œ ¡ › “  š  ¡ Ÿ œ “ £ ¸ ¦ – š › ¯ ¦ ” ¸ œ ¡ à › š  ¦ ” ­ “ – “ – œ ¤
” ¦ £ ¥ œ – œ £ ­ – ¦ ž £ œ ¯ “ Ÿ œ £ “  “ £ š Ÿ “ Ÿ Ÿ œ ” œ – ¥ š  š ¦ œ ¡
£ ¦ ” ± ¡ › ¦ – ¡ ¦ ” ² š – › ™ “ £ œ ” ³ š ” › – š ž ™ š Ÿ ¦ ” ¶ ’ ¦ ” – œ ¤
” ™ £ › “ Ÿ ¦ ” Ÿ œ œ ¥ “ £ ™ “  š  ¡ ¯ ™ œ ” › – “ ¡ — ™ œ Ÿ œ ž š Ÿ ¦
“ £ “  “ ­ “  š Ÿ “ Ÿ Ÿ œ œ ” › “ ” › à  ¡ š  “ ” ­ “ – “ œ ¡  ¦ ¡ ¤
› – “ – ž ™ œ ¡ ¦ ”  “ ¯ š ¡ ¦ ” Ÿ œ ž Å ” — ™ œ Ÿ “ œ ”  “ ­ “ ¡ Ÿ ¦
Ÿ œ ¯ Á ¡ š ¯ ¦ ” £ ¦  “ £ œ ” ¼ ­ ¦ Ÿ œ ¯ ¦ ” ¦ ž › œ ¡ œ – ¯ œ Æ ¦ – œ ”
” ¦ £ ™  š ¦ ¡ œ ” — ™ œ  ¦ ¡ ¦ › – “ ” § œ ™ – Á ” › š  “ ” ¼ “ £ “ ¥ œ Ç
— ™ œ ” œ – œ Ÿ ™  œ ¡ £ ¦ ” › š œ ¯ ­ ¦ ” Ÿ œ œ Æ œ  ™  š  ¡ ¶ ± ” › “
¯ œ Æ ¦ – “ ­ ™ œ Ÿ œ š ¡  – œ ¯ œ ¡ › “ – ” š ¸ ¡ š È  “ › š ¥ “ ¯ œ ¡ › œ
£ “  “ £ š Ÿ “ Ÿ Ÿ œ ” œ – ¥ š  š ¦ ­ – ¦ ­ ¦ –  š ¦ ¡ “ Ÿ “ œ ¡ £ ¦ ” ” š ” ¤
› œ ¯ “ ” ³ ² ± ¶
É Ê Ì
‘ Í Î Ï Ð  Ñ Ñ Ò Ó ‘
± ¡ £ ¦ ” Å £ › š ¯ ¦ ” “ Ô ¦ ” ¼ £ ¦ ” ” š ” › œ ¯ “ ” Ÿ œ ± ¡ › ¦ – ¡ ¦ ”
² š – › ™ “ £ œ ” ³ š ” › – š ž ™ š Ÿ ¦ ” § “ ¡ œ Õ ­ œ – š ¯ œ ¡ › “ Ÿ ¦ ™ ¡
 – œ  š ¯ š œ ¡ › ¦ œ ” ­ œ  › “  ™ £ “ – ¶ ± ¡ œ ” › ¦ ” ” š ” › œ ¯ “ ”
¯ Å £ › š ­ £ œ ” ™ ” ™ “ – š ¦ ” š ¡ › œ – “   š ¦ ¡ “ ¡ œ ¡ › – œ ” Á Ÿ œ ¡ ¤
Ø Ù Ú Û Ü Û Ý ß à ß á â ã ß Ú ä å â æ ç ß ç è ä ß å â é â Ý Ü ê ë ì í î à ß á â
Ü ê Ü é ï ð Ý ß ñ Ü î ò ì ó ô ô õ ö ô ø ù ú û ö ì ô ü ö ô û
› – ¦ Ÿ œ ™ ¡ ¯ š ” ¯ ¦ ¯ ™ ¡ Ÿ ¦ ¥ š – › ™ “ £  ¦ ¯ ­ “ – ›
š Ÿ ¦
“ › – “ ¥ à ” Ÿ œ £ ¦ ”  ¦ ¯ ­ ™ › “ Ÿ ¦ – œ ”  £ š œ ¡ › œ ” š ¡ › œ – ¤
 ¦ ¡ œ  › “ Ÿ ¦ ” ¯ œ Ÿ š “ ¡ › œ ™ ¡ “ ¦ ¥ “ – š “ ” – œ Ÿ œ ” Ÿ œ š ¡ ¤
› œ –  ¦ ¡ œ Õ š  ¡ ¶ ¹ “ – “ £ ¦ ¸ – “ – £ “ š ¡ ¯ œ – ” š  ¡ œ ¡ œ ” › ¦ ”
¯ ™ ¡ Ÿ ¦ ” ¥ š – › ™ “ £ œ ” ¼ œ £ ” š ” › œ ¯ “ ” œ œ ¡  “ – ¸ “ Ÿ œ – œ ¡ ¤
Ÿ œ – š Ç “ – £ “ ” š ¯ « ¸ œ ¡ œ ” Ÿ œ £ œ ¡ › ¦ – ¡ ¦ › “ £ ý  ¦ ¯ ¦ £ “ ”
­ œ –  š ž š – Á “ ™ ¡ ™ ” ™ “ – š ¦ ” š ” œ œ ¡  ¦ ¡ › – “ – “ œ ¡ œ ” œ
­ ™ ¡ › ¦ Ÿ œ £ ¯ ™ ¡ Ÿ ¦ ¶ þ “ Ÿ “ ™ ” ™ “ – š ¦ œ ” › « – œ ­ – œ ” œ ¡ ¤
› “ Ÿ ¦ Ÿ œ ¡ › – ¦ Ÿ œ £ ¯ ™ ¡ Ÿ ¦ ¥ š – › ™ “ £ ­ ¦ – ™ ¡ “ œ ¡ › š ¤
Ÿ “ Ÿ Ÿ œ ¡ ¦ ¯ š ¡ “ Ÿ “ ÿ
ÿ  ÿ   ™ ý ¦ œ ” › “ Ÿ ¦  ¦ ¡ › – ¦ £ “
œ £ ™ ” ™ “ – š ¦ ¶ ³ “ Ÿ ¦ — ™ œ œ ¡ ™ ¡ ³ ² ± £ ¦ ” “ ¥ “ › “ – œ ”
­ ™ œ Ÿ œ ¡ ¥ œ – ” œ ¯ ™ › ™ “ ¯ œ ¡ › œ ¼  “ Ÿ “  “ ¯ ž š ¦ œ ¡ ™ ¡
“ ¥ “ › “ – Ÿ œ ž œ › – “ ¡ ” ¯ š › š – ” œ “ £ – œ ” › ¦ Ÿ œ “ ¥ “ › “ – œ ”
Ÿ œ ¡ › – ¦ Ÿ œ £ ¯ ™ ¡ Ÿ ¦ ¥ š – › ™ “ £ ¶
’ “ ” “ – — ™ š › œ  › ™ – “ ” ž “ ” “ Ÿ “ ” œ ¡ – œ Ÿ œ ”  £ š œ ¡ › œ ¤
” œ – ¥ š Ÿ ¦ – ” œ § “ ¡  ¦ ¡ ¥ œ – › š Ÿ ¦ œ ¡ £ ¦ ” Å £ › š ¯ ¦ ” “ Ô ¦ ”
œ ¡ œ £ œ ” › « ¡ Ÿ “ – Ÿ œ ¤
¬
“  › ¦ ­ “ – “ œ £ Ÿ š ” œ Ô ¦ Ÿ œ ± ¡ ¤
› ¦ – ¡ ¦ ” ² š – › ™ “ £ œ ” ³ š ” › – š ž ™ š Ÿ ¦ ”    ¼
 ¶ ± ¡ œ ” › “ ”
“ – — ™ š › œ  › ™ – “ ” œ £  ¦ ¡ › – ¦ £ Ÿ œ £ “ ” š ¯ ™ £ “  š  ¡ – œ  “ œ
” ¦ ž – œ ™ ¡  ¦ ¡ Æ ™ ¡ › ¦ Ÿ œ ” œ – ¥ š Ÿ ¦ – œ ” š ¡ › œ –  ¦ ¡ œ  › “ ¤
Ÿ ¦ ” ¶ þ “ Ÿ “  £ š œ ¡ › œ ” œ  ¦ ¡ œ  › “ “ ™ ¡ ¦ ý ”  £ ¦ “ ™ ¡ ¦
Ÿ œ œ ” › ¦ ” ” œ – ¥ š Ÿ ¦ – œ ” ¶ þ ™ “ ¡ Ÿ ¦ ™ ¡ ™ ” ™ “ – š ¦ ¯ ¦ Ÿ ¤
š È  “ ™ ¡ “ ¥ “ › “ – ¼ œ £ ” œ – ¥ š Ÿ ¦ – “ £ — ™ œ ” œ œ ¡  ™ œ ¡ ¤
› – “  ¦ ¡ œ  › “ Ÿ ¦ œ ” › œ “ ¥ “ › “ – œ ¡ ¥ Á “ ™ ¡ ¯ œ ¡ ” “ Æ œ Ÿ œ
“  › ™ “ £ š Ç “  š  ¡ “ £ – œ ” › ¦ Ÿ œ ™ ” ™ “ – š ¦ ” “ ¥ š ” “ ¡ Ÿ ¦ Ÿ œ
£ ¦ ”  “ ¯ ž š ¦ ” — ™ œ ” œ § “ ¡ ­ – ¦ Ÿ ™  š Ÿ ¦ ¼ Ÿ œ ¯ ¦ Ÿ ¦
— ™ œ › ¦ Ÿ ¦ ” £ ¦ ” ™ ” ™ “ – š ¦ ” Ÿ œ £ ” š ” › œ ¯ “ › œ ¡ ¸ “ ¡ ™ ¡ “
¥ š ” š  ¡ Ÿ œ £ ¯ ™ ¡ Ÿ ¦ ¥ š – › ™ “ £  ¦ ¡ ” š ” › œ ¡ › œ ý “  › ™ ¤
“ £ š Ç “ Ÿ “ ¶ þ ™ “ ¡ Ÿ ¦ œ £ ¡ Å ¯ œ – ¦ Ÿ œ  £ š œ ¡ › œ ”  ¦ ¡ œ  ¤
› “ Ÿ ¦ ”  ¦ ¯ š œ ¡ Ç “ “  – œ  œ – ¼ Ÿ œ ž œ ¯ ¦ ” £ š ¯ š › “ – œ £
¡ Å ¯ œ – ¦ Ÿ œ ¯ œ ¡ ” “ Æ œ ” Ÿ œ “  › ™ “ £ š Ç “  š  ¡ ­ “ – “ — ™ œ
¡ ¦ ” œ ­ – ¦ Ÿ ™ Ç  “ ™ ¡ “ œ Õ ­ £ ¦ ” š  ¡ Ÿ œ ¯ œ ¡ ” “ Æ œ ”  š – ¤
 ™ £ “ ¡ Ÿ ¦ ­ ¦ – £ “ – œ Ÿ ¶ ¹ “ – “ œ £ £ ¦ ¼ œ ¡ £ “ £ š › œ – “ › ™ ¤
– “ Ÿ œ £ “ ¯ “ › œ – š “ ” œ § “ ¡ š ¡ › – ¦ Ÿ ™  š Ÿ ¦  ¦ ¡  œ ­ › ¦ ”
 ¦ ¯ ¦  – œ “ ” Ÿ œ  ¡ › œ – à ” ´    µ     ­ “ – “ š ¡ › œ ¡ ¤
› “ – – œ Ÿ ™  š – œ £ ¡ Å ¯ œ – ¦ Ÿ œ ¥ œ  š ¡ ¦ ”  ¦ ¡ £ ¦ ” — ™ œ
                        "      &
  "    )     ,           "    
     3   5       8       
i
 ; 5   &
   ,                     ?        
     A      5  B    ;  C  5          8   
             5   
i
 I         
8                 5         
i
          K  K  K


  


i
 I   O &
 
       A   " 5          U V 
       8                        
      A   " 5  3  5              " &
      "     Y   5  
 [ \ ] ^ _     _ ` a b c d e f g i j [ k _ l n  d  d p c `   e d c
_ ^ q  [ p c q p ] ^ c [ d _ d c r e k k c p  e ^ " c r d c ^ u c ^ d v
 5 #

% & (
K *
&
# K 
  

K *

     w  "   &
            5     "      5       5
   x          U V            8    &
     &            "    5            
   O    5              5              &
     5       3   5       8    5  O  
         ;   )       5     O   5    &
            "  w           5 5   
 }    "          8  "   "        
           O   )         5          
5          U V  
,  
€    "   "           5           
? .  0 C 3   "      5 O    5  }    "    &
          ,    O         "       &
  5        , ‚    3 O      B    5   
      ;   5       
,     O      
 ‚     3  5  }    "          "  
     5                         5
   "      "    8    5   
‡
     5  
                "             &
"           "        ˆ 5       3 ˆ  
5  8               5 "    5     5  ‰  5 &
   0        ? .  0 C  U   8     "    &
5     
3 € &    " 5   3        A  "     
"              5   ;   5 "    5     5 
.  0          U V   4       w      A 
  "   "    5    " 5        ;  ˆ    5    ;  
   }    w   Y      3 0   5       5   O
? 0 C ˆ 6    ˆ 7      B   "    0     w
? 6 7 0 € C 3 8  "         A     5    5   
          5          U V  
   5 "           A    "   "    5    " 5  &
      ;  ˆ    5    ;   5 O      6   }  &
  ? 0  6 C "        5     5 "    5     5    5 &
             5           5     &
       I     5    ;   "             
     8     }         5        "  B
   A     5    5            8   5    &
   U V  "   "        3  5         "  8 
    5      "     A     ;      5    ;  
5   }       "             5     €   5    &
 3 "                  }          
 }   w   Y      "   "    "        5     5
"    5     5    5                    
U V  
 5      5   Y  5    ,   O    B    5 
  O           = 5       ;  ?        5  
"    5     8            5    "      
   5             5          U V   I 
     ;  ‹ "        5      5 O      O   }   
8  "   "          5       ;  @    ‚ "    5 
   5    ;   "            5  5 O      "   " &
    €   Œ 5    3 5       ;   "       5      &
 5        ,    "       
A  C
Ž  E ‘ ’ ‘ “ G I ”  “
 5 "    5     5    5            ? "    5  &
  .  0 C   5          U V  ˆ  w   Y    
                3 ˆ   w   "   "   
   5         "      5       5  
3 ‹    
      " 5     }       "       ;  
5       "    "  5    5   
‡
     5 A      5 
   ‹     5        5  B  }           &
   B    ;    "     
 8     )   5     &
 5   ;   5      5   ‹ U  
‡
   ;   5    &
5          ‚  ;   5  5      0        O  3
   O     5 5              5    "   &
        5     5 8  "        5         
U V        "     5     O     O       
       3  5 ˆ                 L        &
        3    O                O   
252 Redes y Comunicación
    
       
              !    
   !  !    !      !   )       !       
-  / !       !  3 -    5
6      !         ! -          ;  <  >
3     3              3   B D 6 
      !     - !       3  ! 3   !    
I )          !  3    /   )    !   !     
 )      3  !   
 3  5   !           !
    -        3    P    !  Q  5 B   !  
   3  !     I )     U    V   )    
 I   3    !   X     !
Y
      )    
i
        \   )   !           
       !     )    !  V  3 \  !  !         !   >
 !  - 3  a  3 
    b 3  !   )      ) >
   !         !    3   3 !   )   !  5   3   3 !
  3  ! V     !    3 !  -  P   3 -  \  -       
          -   !  !      !    )   !   U 3 >
      b 3  !   )             !  X    
 !       3            3   / !       >
 !          ;  5 f ! 3 ! b    3 !        !    >
 !    3 !  -  P    
   !  !   !      3 -   
   )   !   3 P     Q    !   )     
      3            
       -          5
g !   !     ! V    ! -  3  !   !        P   >
 !        3 / !         ;   !   -    3      !
  3    P   3     !  Q        !  5
6    ! -  3     !       3   B D 6 
    ! -  3   g >  ! 3    ! V I  !   !     !   
- b      <   j           !  !    !     !   >
  !   k      5 g     !     )      - !   
- b            3 !               !   - 
 !     ;  U        ;  X   )   !           
3     ! -       3         3         >
    ;    !            !  5 6       j    !   >
   !  I   k   3 !    
Y
    ;             V
 !   !     !         ;   ;  !        -   >
3 !  -  ) 3   5 B   < 
Y
    ;   3      
       ;   V I   ! 3  !       \  3   !  5
6    ! -  3               )    !  !     >
   P     
     - b      <   j         
  !               ;   !   3  !  )   !   !   >
-  
FQoS
5
FQoS =
s

i=0
hcpu(i) +
n

i=0
hasr(i) + nm
U  X
p 
Y
    ; 
FQoS
     3       \  3   ! 
 
Y
    5 6     3  !    !  V            3 
  !  )   !     
Y
    ; 
hcpu(i)
  !  ! 
 !    )   !         3  5 p 
Y
    ; 
hcpu(i)
)   b    !      /    3   !      
   ;  
f g         )   ! 
i
5 p         3      
 ! 3  !    3    !    
Y
    ;  V    \  3   !
!  !     P   )   !     !   
Y
    ;           
         ;    )              !    )   !  
      3  B D 6         !  ! -       
    !          ;  5
 q r s t u   v w x y w t z u x q { | z w } {
hcpu(i)
6       !  \  3   !   
Y
    ;  3    
                  ;    !  !    !       
  !   !   )      5 6   \  3   !
hasr(i)
3    
       3    U    X    3          3 
      )     5 6          Q  !  3 !  ) 
 ; 3 !   ! 3  !      
Y
    ;   ! 3       ! 
 !      !   5 B   < 
Y
    ;            
 
              !             3   !
  !   )            !   
 3  5
     3   V   \  3   !
nm
  /    b 3  !
  )         -    3      !    
  )   !   !   !     ! -              ;   >
  3      V                  ;        5 6  >
 P
Y
    ;         !      !    !   
Y
  
 ! 3  !    3    ! V  ! 3 ! 3               V I
    
          !     !     ! -      
            )   !   3 P    Q    ! 
 )      5
XVI Jornadas de Paralelismo, JP '2005 253

  
      
    
hasr(i)

          
    
nm
 $
   & ' ) * + &  . 0
* ) 2 &   '     ) 3  3
3 .  . '  ) 2 ) & . 0 9 ) 9 * . +  9  

: ; < = > < ? @ ? A > ? D E = < D < = F A H J < L ? H N @ L < P

N < ; > ? F H Q ; D < L ? T ? A H ? ; > < D < L E = L X E A H > N E =
 < ; Z > H F E = \ ] < ^ < N E = D < = ? A A E L L ? D E @ ? A ? A < P
= E L T < A < L @ A E J L < N ? D < L ? F ? L H D ? D D < = < A T H F H E < ;
L E = = H = > < N ? = f g : h \ ] < ^ < N E = D < ; E N H ; ? D E F E P
N E      
 " $
j





 


  


 

& 



(
 )
k
l E = L X E A H > N E =  < ; Z > H F E = n  o = E ; N Z > E P
D E = ^ < ] A q = > H F E = D < J r = \ ] < D ? J ? = ? D E = < ; < L F E ; P
F < @ > E D ? A T H ; H = > ? D < < T E L ] F H Q ; @ E A = < L < F F H Q ;
; ? > ] A ? L    k  < F ? A ? F > < A H t ? ; @ E A @ ? A > H A D < ] ; ?
@ E J L ? F H Q ; H ; H F H ? L D < @ E = H J L < = = E L ] F H E ; < = n F A E P
N E = E N ? = o ? L ? \ ] < ^ ? F < ; < T E L ] F H E ; ? A = H X ] H < ; P
D E F H < A > ? = A < X L ? = ^ ? = > ? ? L F ? ; t ? A < L < = > ? D E z ; ? L h
> A ? = F ] N @ L H A ] ; ? F E ; D H F H Q ; D < F E ; T < A X < ; F H ? h < ;
L ? \ ] < L ?
|
] ; F H Q ; D < F ? L H D ? D ? L F ? ; t ? ] ; T ? L E A
Q @ > H N E ? F < @ > ? J L < k } ? D ? H > < A ? F H Q ; D < L ? L X E A H > P
N E F E ; = H = > < < ; X < ; < A ? A ] ; ? ; ] < T ? @ E J L ? F H Q ;
? @ ? A > H A D < L ? <  H
= > < ; > < < N @ L < ? ; D E > Z F ; H F ? = D <
A < F E N J H ; ? F H Q ; E N ] > ? F H Q ; = E J A < L E = F A E N E = E P
N ? = \ ] <
|
E A N ? ; D H F ^ ? @ E J L ? F H Q ; k  ; F A E N E = E P
N ? < = > „
|
E A N ? D E @ E A D E = < L < N < ; > E = h @ E A ] ;
L ? D E < L
&   





< = L ? F E D H z F ? F H Q ; D < L @ A E J P
L < N ? † @ E A E > A E < L *
  





\ ] < F E ; > H < ; < L ? =
F ? A ? F > < A q = > H F ? = \ ] < < L F A E N E = E N ? A < @ A < = < ; > ? h
< = H ;
|
E A N ? F H Q ; ? D H F H E ; ? L = E J A < < L @ A E J L < N ? ?
A < = E L T < A † L ? ? @ A E T < F ^ ? A < N E = @ ? A ? ? ‡ ] = > ? A < L
F E N @ E A > ? N H < ; > E D < L ? L X E A H > N E k D < N „ = F ? D ?
F A E N E = E N ? > H < ; < ? = E F H ? D E ] ; T ? L E A D < ,

   
h
\ ] < N H D < L ? J E ; D ? D D < L ? = E L ] F H Q ; † \ ] < @ < A P
N H > H A „ F E N @ ? A ? A ] ; E = F A E N E = E N ? = F E ; E > A E = k
: ; ; ] < = > A ? H N @ L < N < ; > ? F H Q ; h < L X < ; E > H @ E < =
] ; T < F > E A F E ; > ? ; > E = < L < N < ; > E = F E N E ? T ? > ? A < =
<  H = > ? ; < ; < L = H = > < N ? h F ? D ? ] ; E D < L E = F ] ? L < =
F E ; > H < ; < ] ; ; r N < A E H ; D H F ? ; D E ? \ ] Z = < A T H P
D E A < = > „ ? = E F H ? D E < = < ? T ? > ? A k  H > < ; < N E =
N
? T ? > ? A < = < ; < L = H = > < N ? h < = > < T < F > E A > < ; D A „
N
< L < N < ; > E = † = H > < ; < N E =
S
= < A T H D E A < = F ? D ? < L P
< N < ; > E D < L T < F > E A = < A „ ] ; ; r N < A E < ; > A <
0
†
S −1
k : L
|
< ; E > H @ E F E ; > H < ; < H ;
|
E A N ? F H Q ; ? F < A F ?
D < L ? F ? A X ? < = > H N ? D ? n N < D H D ? < ; > Z A N H ; E = D <
] > H L H t ? F H Q ; D < L ? } Š  o \ ] < ] ; ? T ? > ? A ? ‹ ? D < ? L
= < A T H D E A ? L \ ] < < = ? = H X ; ? D E k D < N „ = H ; F L ] † < H ; P
|
E A N ? F H Q ; H ; D H F ? ; D E = H ] ; ? T ? > ? A < = ] ;
 
j  


j j
j  E ; E k  ; ? T ? > ? A ? = H X ; ? D E ? ] ; = < A T H D E A
s
= < D < ; E N H ; ?
 
j  

 j j
j  = H ? L X ] ; E D < = ] =
T < F H ; E = n L E = ? T ? > ? A < = \ ] < = < < ; F ] < ; > A ? ; D < ; > A E
D < = ]  o < = > „ ? = H X ; ? D E ? ] ; = < A T H D E A D H = P
> H ; > E D <
s
k } E N E
|
] ; F H Q ; D < F ? L H D ? D ] > H L H t ? A < P
N E = < L T ? L E A D <
FQoS
h @ E A L E > ? ; > E < L ? L X E A H > N E
X < ; Z > H F E D < J < A „ < ; F E ; > A ? A < L F A E N E = E N ? = F E ;
< L N < ; E A T ? L E A D < z > ; < = = @ E = H J L < k
l ? N ? † E A q ? D < N Z > E D E = ^ < ] A q = > H F E = = < J ? = ? ;
< ; L ? X < ; < A ? F H Q ; ? L < ? > E A H ? D < ] ; ? @ E J L ? F H Q ;
H ; H F H ? L k  H ; < N J ? A X E h = H < = > ? @ E J L ? F H Q ; H ; H F H ? L
= < D < z ; < F E A A < F > ? N < ; > < h F E ; F E ; E F H N H < ; > E <  P
@ A < = E D < L @ A E J L < N ? † ; E D <
|
E A N ? ? L < ? > E A H ? h
< ; > E ; F < = L ? J r = \ ] < D ? @ ] < D < E J > < ; < A ] ; ? J ] < P
; ? ? @ A E  H N ? F H Q ; ? L Q @ > H N E X L E J ? L F E ; N ] F ^ ?
N ? † E A A ? @ H D < t k : L @ A E J L < N ? \ ] < = ] A X < < ; < = P
> E = F ? = E = < = \ ] < ^ ? † \ ] < < T H > ? A \ ] < < L ? L X E A H > N E
F E ; T < A ‡ ? D < N ? = H ? D E @ A E ; > E † F ? H X ? < ; ] ; N q ; H P
N E L E F ? L h @ ? A ? < L L E ^ ? † N ? ; > < ; < A ] ; N q ; H N E D <
D H T < A = H D ? D < = > A ] F > ] A ? L < ; > A < L E = D H
|
< A < ; > < = F A E P
N E = E N ? = \ ] < F E N @ E ; < ; L ? @ E J L ? F H Q ;  -  k  H X ] P
H < ; D E < = > ? L q ; < ? h L ? @ E J L ? F H Q ; H ; H F H ? L X < ; < A ? D ?
< ; < L ? L X E A H > N E @ A E @ ] < = > E = < E J > H < ; < D < T ? A H ? P
254 Redes y Comunicación
   
  
                         !
      #                 (       +

  -
.
    (                    (        !
            
  

    ; = .       !
             
C   #    

 (      F 

G     
  H   

  
       
G     
  !
F 
             L      M
s
i=0
hcpu(i)
N  
 
O
            
FQoS
-
P                 (        

   
       (              
  

 
 





            (             !
 
  
Y
 
 




- + 
O
        #  
 
    (           (                !
                      (       (   L    -
a     .
      
                

 d   
-  C      #       (          
  !
        
    
 
   (       
-      !
   (  C     F             g     G  
   
     L 
 h                     
  
          
 d    M
   h  
O
          !

      (          
        N -    k
C
g    h l             L     C h   
   !
          



   
C   #  
 (   H  #    

  F   
    G    
     (          
  k 
             
 (      
 

O
   G       
  (   
-  - .            
          
 
           
     G   (          (  !
     g                             

  
                    - ;  
    !
  C                 .
C
 (        
                   
P +Nelitist
   
 !
 
C       

Nelitist
   
  

   #    !
 
#             (                    l  
 
  F   
M  
     
N G     
  H   

- 
H                C      G  (         
   k
O
          

P
  F   
   
  
M  
 
     H   

N                       -
a               
 d    C
    (   !
           (           (          ! L
  
   
        
    ! L
       (   !
              - . 
 (        (      
    ( 
 
O
                     


    (   !
                  F   
G     
  H   

-
   G  s
        
 
   
  
   (   !
    
C    
         ! L
  
          
   M  

 G   N      
- .   

 G       

      
   
C      L               
   !
      C  

 G            C  

 G      !
         

 G     
O
   
-  - a      

              
 d    C    
        

   
   ! L
      
      (       -
   G  s  
           
    
    !
    C 
      

O
    
   

 k
#  
       k 
         - .              


     
              #  
  

        
      
        
     (     !
      (       s       G  
    
       
   
   
  
C  G       
l     G   (   !
           - .
      
   

 
   !
                    
 G     
        !
     

  G     
  
#  
          
 ( !
   
- a     d      
  
      
        
       

      
 
  
     
   
 G     
       - a   u       
   
  

     

O
        
           

!
               
  G       #      G     C

                       C 
 k 
 (     - . 
 
 (       
#     
    !    (       

G        
        #  
          !
            #            (        
   G  

t
-
                   
t " # $ % &
$ elitist ' ( $ *
 + - + . + -  .  1   .  .
( '
2
' ( $ *
 + - + . + -  .   
( '
$ ' ( $
*
 4    .    1 7 8 9
( '
& sex ' ( &
 .   : + ; <      .  = <  1
( '
& mut ' ( &
 .  - <     
( '
& >
2 9
 + - + . + -  A   E
$ F
8 G H
G    K G   M A  + - + . + - 
' (
2  ;  .
( '
7  .  A  + - + . + - 
' ( Q
 R +
( '
 A  
' ( &
 : + ;   + . . + 4 
( '
     +
"
+ :   V
$
elitist
V ;  V 
t
V  V 
inter

;  . ;   A X
$
elitist Y
 .  2 
$
elitist Y
  
G    A X 
t
E 
F
 A X
%
 1   V H  : + ; <    +  
& sex
.   X
%
 = <  1   +    .
G   M A X
%
 1   V 2 + \    +  
t
 A X
%
 1   V
"
+ . . + 4  
7  .  A X
"
+ . . + 4   G    K G   M K 
.   +
' (
G .  = <  1
( '
7  .  A X G   
_   V . 
.   `  +  4  \ V  +  ;   +    .
H   + - a     +   7  . 
XVI Jornadas de Paralelismo, JP '2005 255
    
        
  mut 
       
            

    
!  "             

$
inter
% 
'
( )    
    
$
t+1
( )
+
    $
inter
, -

 
       
   
 

           !     ! $ & ( * ! * + & (  ! $ & 0   4  & 5
! *  7 ! $ & ( * ! * + & (  ; &   * =  ! * + & (     4 $  *  ? $ A B
C  ? $  ! $ &  * (    ( $     H   I ?    $  ( *   * &  $  J
K  H  * ?   $ (     $         (    (   0 *  ! * + &   5
 I & (   (   0   $  (   
T
U & ! * + & ;  &    7
FQoS
A J
W U  & ( $  $ ( $   $  * & ( * 0 * ( U $   &   H $    ! * + &
 $ & ? U \ H    ! * ( $  7   (   0 *  ! * + &    I & (   (  
;  &        ]  A ( *
T
^ ! *  ?  &   H $ (   ? $  $    & 5
  U &   $  U ! * + & ?  ] $  b U     !  U   J K & ! $ & 5
  ! U  & ! *  ! U  & ( $   (   0 *  ! * + &    I & (     
?  & $  b U  U & ! *    $ U ?     (    & (   ? $   
  4 $  *  ? $ J K    4 U & ( $ H   I ?    $ b U  C  ? $ 
! $ &  * (    ( $ C   * ( $   & g ?   $ (  4  &    ! * $ &  
! $ &   ! U  * 0    * & ?  ] $      0   $  (   ;  &    J  *
    U & (     ? * &  ( $ & g ?   $ (  *     ! * $ &   & $
! $ &   4 U * ? $   & ! $ &     U & !  $ ? $  $ ?  ?  ] $ 
7 U &   $  U ! * + & ?  ] $  A (    ? $  H $   U  &     ! 5
 U   J  $  g   * ? $ B C  ? $   * ? *   ( $   ?  * j &  
& g ?   $  $    (  *     ! * $ &   b U      4 $  *  ? $
H U  (      * =   J W U  & ( $   ! U ? H   ! U   b U *   
(           ! $ & ( * ! * $ &       4 $  *  ? $   (  5
  & (  I J
K    4 $  *  ? $ b U   !    ? $  (  (   !  *  * 
! $ &    (  ( * 0    $  H   I ?    $   U  !  H  *    
(      ] U    ( $  ! $ &   ; & (  $    &    
? I r * ? $   & ( * ? *  &  $ H $  *    (   K 
J K  $ 
H   I ?    $   $ &   & g ?   $ (  !  $ ? $  $ ?    &
  H $    ! * + & 7
P
A B       (    H  $ ( U ! ! * + &   r 5
U   7 H  $    *  * (  ( (      ! ! * $ &     H  $ ( U ! ! * + &
  r U  
T
  &       r U   A B       (  ? U   ! * + & B
  & g ?   $ (  !  $ ? $  $ ?     *  *     7
Nelitist
A B
\  $  U ?       H      (   0 *  ! * + &    I & (   B  
& g ?   $ (    H   * ! * $ &   ! $ &   ! U  * 0    * & ?  ] $ 5
     ;  &    \   & g ?   $ ? I r * ? $ (  *     5
! * $ &   J   ? $   ] U    ( $ ( 
T
$  ?   ? H ^  * !   $ 5
( $     $  H   I ?    $  B H       $ C  ? $      5
* =  ( $ H  U      $    ( $  ! $ & ; 4 U   ! * $ &   ( 
 *    ?   w x K ( *   * &    B (  & $ ? * &  (    K w  5
   \  K w        J K  H  * ?   $   U &  ]  ? 5
H  $ (  w x
K (    ?  { $ ?  ( * $ B   & (   ? $   
 0       \ |    0 * ( $    J K    4 U & ( $   U &
 ]  ? H  $ (  w x K ?  \ $  ! $ & .  0       \
    0 * ( $    J w   * ( $   * ? *   ! * $ &   (    H  5
! * $ B H     &   ? $   b U ^ g & * !  ?  &    $  0   $   
$    & * ( $  ! $ ? $ 0   $    + H  * ? $  H    !  (  U & $
(     $  H   I ?    $  J

(  ? I  B H     0   U      H      ! * $ &   (   $ 
? j  $ ( $  (  H    * ! * $ &  ( $ C  ? $       ]  ( $ ! $ &
    ( *    *  U ! * $ &   (   0       ( *   * &    (  &   $
(   ? U & ( $ 0 *   U   J   ? $     4 * ( $      ( *  5
  *  U ! * $ &   H $        ? I   ? H  *  ?  &   U  * 5
 * =  (    &    *      U   (    ?     *  B       $ & 
U & *
T
$  ?  B    4  (  \  4  U H  (     J €    = + & ( 
U        ( *    *  U ! * $ &   ( *   * &      b U    !   5
4  b U  * &   $ ( U !  &  &    *    ?    ( *
T
   &  
H    !  (  U &  (       J K &   * 4 U    H $ (  5
? $  0   U &  ]  ? H  $ (       ( *    *  U ! * $ &    &
U & ? U & ( $ 0 *   U    w  &   b U    ? U & ( $  
  ! U  (   ( $ \  $   0        $ &  $  H U &  $  &  5
4  $  J   ? $   ] U    ( $     4 $  *  ? $ H  $ H U    $
 $             ( *    *  U ! * $ &   (   0        &
  ? U & ( $ 0 *   U   J
    ‚ "  ƒ „
  
 … „  † ‚ ‡ ‚
‚  „ … ‚  $ ƒ ‡ 
 ‚ 
    ˆ  ‚ & ‰ … †     &  Š  Š ˆ ‹ & Œ   „
Š  Š ˆ
€        ? U         $    * (  ( (  H   I ?   5
 $   ] U    ( $  H        4 $  *  ? $  K 
J
( * + - . / 1 + 3  ‚   
4 * . * 5 3 ( 3 6 7 * 8 9 ; < > ( @  A A
( 3 + 8 / < 1 * F / I 7 9 1 9 J 1 * J > M
elitist
@ " A
4 * J * O Q 1 * 8 9 ; < > 4
mut
@ A Ž A "
4 * J * T / U + 3 V Q 8 8 9 ; < X / Z Q * 7 > 4
sex
@ A Ž \ "
] 1 / + * 8 9 3 < / J . * Z A A
T / U / 1 9 8 9 3 < / J . * Z " A
_ . 6 + * 7 V 9 a / + J 9 V * V A Ž A A "
W U  (  $      I ?    $   K 

256 Redes y Comunicación


       
        

     ! # $  ' ! *      -  / $ 1  3 5 7 8 '  # $ 5 '  8 7  $ =
$ -     7  # !  = 7 $  8 !  ? / $ * ! 5 $ =
A
 $ = 7  # ! - ! 5  $ C
5 1 - 7  # ! 5 ! E 7 $ = 8 # ! 5 ' ! = $ 5 7  7 I ' = 8 '  ' ! = - ! 5  $ C
5 1 - 7  # ! 5 ! E 7 $ = 8 # ! 5 * $ # 8  = 7 $ ! 7   5 # ! 5 / $ 1  3 5 C
7 8 '  5 ?  N    ? P 1 $ N  5 $ /  E 3  =  #   C
7  # !  -   ! E - $ *  # $ -  '  - 8 #  # # $ 5 $  V 8 ' 8 !
# $ 5 8 5 7 $ *  5 X Z [    \ ] ! 5  $ 5 1 - 7  # ! 5 /  5 8 # !
! E 7 $ = 8 # ! 5 # $
A
!  *  $ *  3  8 '  5 ! E  $ -  5 ' ! = ` a C
1   ' 8 ! = $ 5 P 1 $ 5 $ # $ 5 '  8 E $ = $ = -  5 $ ' ' 8 e =   $ C
V 8  ? 7  = 7 ! [ X    ' ! * ! [ X    \  !
! E 5 7  = 7 $ ? # $ E 8 # !  - 8 * 8 7  ' 8 ! = $ 5 # $ $ 5   ' 8 ! 5 e - !
  $ 5 $ = 7  * ! 5  P 1 3 - ! 5  $ 5 1 - 7  # ! 5 5 ! E  $ [ X  C
  ? #  # ! P 1 $ - ! 5  $ 5 1 - 7  # ! 5 $ = [ X   
A
1 $  ! = * 1 N 5 8 * 8 -   $ 5 \
]  7  E -   * 1 $ 5 7   - ! 5  $ 5 1 - 7  # ! 5 ! E 7 $ = 8 # ! 5
' 1  = # ! - ! 5  V  7   $ 5 5 $ # 8 5 7  8 E 1 N $ = $ = $ - * 1 = # !
V 8  7 1  - 5 8 a 1 8 $ = # ! - ! 5 7  $ 5 7 8  ! 5 # $ # 8 5 7  8 E 1 ' 8 e =
  $ 5 $ = 7  # ! 5 $ = -  5 $ ' ' 8 e =  = 7 $  8 !  \ [ = # 8 ' /  5
7  E -  5 ? '  #  ' ! - 1 * =   $   $ 5 $ = 7  $ -  $ 5 1 - 7  C
# ! ! E 7 $ = 8 # !  !  '  #  * I 7 ! # ! / $ 1  3 5 7 8 ' !   ?
   N  [ \ # $ * n 5 ? -    8 * $   ' ! - 1 * C
=    $ 5 $ = 7  - ! 5 V  - !  $ 5 ! E 7 $ = 8 # ! 5  -   - 8 '   1 =
 - a !  8 7 * ! # $    7 8 ' 8 ! =  # ! = ! !  8 $ = 7  # !  '  - 8 C
#  # # $ 5 $  V 8 ' 8 ! ? $ -  - a !  8 7 * ! ]    \ [ 5 7 $  - C
a !  8 7 * ! 5 8 *  - $ * $ = 7 $   !  !  ' 8 ! =  1 =     7 8 C
' 8 e = 8 = 8 ' 8  - ' ! = '   a  E 8 $ = E  -  = ' $  #  \ p  #  ` C
-  # $ -  7  E -  8 = 7  ! # 1 ' $ 1 =  * $ # 8 #  # $   $ 5 7  C
' 8 ! = $ 5 # 8 5 7 8 = 7   $ -  !  ' $ = 7  q $ # $ 1 7 8 - 8 s  ' 8 e = # $
p   * n u 8 * ! # $ 7 ! # ! 5 - ! 5 5 $  V 8 # !  $ 5 # $ - 5 8 5 C
7 $ *  v = ! # $ E $ 5 1  $    $ -  


x  $ - V  - !  # $ - 
A
1 = ' 8 e = # $ '  - 8 #  #
FQoS
 5 ! ' 8  #   -     7 8 ' 8 e =
  !  !  ' 8 ! =  #   !  '  #  * I 7 ! # !  $ - = y * $  ! $ 5 C
7 8 *  # ! # $  V  7   $ 5  - ! 5 P 1 $ 5 $ - $ 5 V     ! C
 !  ' 8 ! =   '  - 8 #  # # $ 5 $  V 8 ' 8 !     $ - = y * $  ! # $
 V  7   $ 5 P 1 $ # $ E $  n = 5 $  * 8 a   # ! 5     - - $ a  
 -     7 8 ' 8 e =  $ 5 1 - 7  # !    7 8 $ = # ! # $ -     7 8 C
' 8 e =  ' 7 1  - v 8 = 8 ' 8  - x  N  !  y - 7 8 * ! ? $ - 7 8 $ *  !
# $ $ q $ ' 1 ' 8 e = $ = 5 $ a 1 = # ! 5 \
[ = $ 5 7  7  E - $ 5 $  1 $ # $ ! E 5 $  V   P 1 $ 7 ! # ! 5
- ! 5 * I 7 ! # ! 5 *  = 7 8 $ = $ =  - 5 8 5 7 $ *   !  # $ E  C
q ! # $ -  1 = 7 ! # $ 5  7 1   ' 8 e =     7 ! #  5 -  5 # 8 5 C
7  8 E 1 ' 8 ! = $ 5 # $  V  7   $ 5 v p    !  # $ E  q ! # $ -
 


# $ 1 7 8 - 8 s  ' 8 e = x ? N = 8 = a 1 = ! * 8 a   * n 5 # $ -
| 


# $ - ! 5  V  7   $ 5 $ = = 8 = a y = '  5 ! \ p 1  = C
# ! - ! 5  V  7   $ 5 # $ - * 1 = # ! V 8  7 1  - 5 $ !  a  = 8 s  =
5 8 a 1 8 $ = # ! 1 =  # 8 5 7  8 E 1 ' 8 e = 1 = 8
A
!  * $ ? -  '   a 
# $ - 5 8 5 7 $ *  $ 5 E  q  ? = ! - - $ a   -  


? N - ! 5
~  €  ‚ ƒ „  … † ‡ ˆ ‰
Š   ‹ Š 
Š ‹ Œ ‹   Š

 
max
      
FQoS
 
         



  
      
Γ(P0)

      
Texe
             
~  €  ‚ ‹ ‰ €  Ž  Ž
Š   ‹ Š 
Š ‹ Œ ‹   Š

 
max





FQoS
          
 
 

         
Γ(P0)
     
Texe
                 
~  €  ‚ Š  ‡  ‘ Ž  Ž
Š   ‹ Š 
Š ‹ Œ ‹   Š

 
max
     
FQoS
              

     
 
Γ(P0)

    
Texe
               
p 1  #  !     $ 5 7  ' 8 ! = $ 5     [ X   
7  $ 5 * I 7 ! # ! 5 $ 5 7 1 # 8  # ! 5 5 $ ' ! *  !  7  = $ ` ' 8 $ = C
7 $ * $ = 7 $ N # $ *  = $   5 8 * 8 -   \
 !  ! 7      7 $ ? 5 $  1 $ # $ ! E 5 $  V   P 1 $ -  # 8 5 C
7  8 E 1 ' 8 e = 5 $ 5 a  #  8 = 7  ! # 1 ' $ *  N !  '   a  P 1 $
-  1 = 8
A
!  * $     $ - * 8 5 * ! = y * $  ! # $  V  7   $ 5
v  1 * $ = 7  -  1 7 8 - 8 s  ' 8 e = # $ -  p   x \ [ = $ 5 7 $
'  5 ! ?  [ * $ q !   ' ! = 5 8 # $   E - $ * $ = 7 $ -  '  - C
8 #  # # $ 5 $  V 8 ' 8 !
A
 $ = 7 $   N    ? 8 = '  $ C
* $ = 7  = # ! $ = 1 =  


$ - = y * $  ! # $  V  7   $ 5
' ! = '  - 8 #  # # $ 5 $  V 8 ' 8 ! 5 8 - ! ' ! *     * ! 5 ' ! =
   N $ = 1 =  


5 8 - ! ' ! *     * ! 5 ' ! =
 \  ! # ! $ - - !  # $ * n 5 ? ' ! = $ - * $ = !  7 8 $ *  !
# $ $ q $ ' 1 ' 8 e = = $ ' $ 5   8 !     ! E 7 $ = $  -     7 8 C
' 8 e = ` =  - \
 8 =  - * $ = 7 $ ? ' 1  = # ! - ! 5  V  7   $ 5   $ 5 $ = 7  =
1 =  # 8 5 7  8 E 1 ' 8 e =  a  1   #  ! E 7 $ = $ * ! 5 - ! 5 V  - C
!  $ 5 * n u 8 * ! 5 # $ 1 7 8 - 8 s  ' 8 e = # $ p   ? ! - ! P 1 $
$ 5 - ! * 8 5 * ! ? P 1 $ $ 5 7  $ 5 -  # 8 5 7  8 E 1 ' 8 e = $ = - 
P 1 $ - ! 5  V  7   $ 5 8 = 7  ! # 1 ' $ = *  N !  '   a  $ = $ -
5 8 5 7 $ *  \ P 1 3  [ $ 5 '    s # $   !  !  ' 8 ! =  
   7 8 ' 8 ! = $ 5 ' ! = 1 = V  - !  # $
FQoS
* $ = !  $ = 1 =



P 1 $ -  5 P 1 $ 5 $ ! E 7 8 $ = $ = ' ! =    N 1 =
 \


* $ = !  P 1 $ - ! 5 P 1 $ 5 $ ! E 7 8 $ = $ ' ! =  \
1 = P 1 $ -  * $ q !   * n 5 8 *  !  7  = 7 $ 5 $ ! E 7 8 $ = $
$ = ' 1  = 7 !  7 8 $ *  ! 5 # $ $ q $ ' 1 ' 8 e = 5 $  $ ` $  $ ?  $ C
XVI Jornadas de Paralelismo, JP '2005 257
                         ! 

 # %
#     (    * ,   *    , 1    (  *  (  5
    (   7
     
9
 *     ( 5
 *  =    !    ( A  *  (       A  *   
E   *  G  *  * E  (  (    %
J
K M O  Q S T K M S
7  (    * =   W    (  *     (    A *   
(  X   G      (     E  *     E  Y      *
*  (   A  *    *  =          (  * A  5
    *    ( A  *     (  (  *  =    ( %     (
    *   (  *  (      (    W   Y   
   (  =    (   *   *  (  Y    ( W   * b (   5
  (      (    (    *  =    %
d  ( *  (     (  (    (  * 1      Y   5
  *     (      *         * (   
*             * E   (  (     (
=  ,   *  (    = * E  (    (    G =  
  * E 1     *       ( A  *  ( ,     5
*   (  *  (      (  
9
 *     (  (    ( 
A  * E  % j  1      *   ! (       Y   5
  (  *    *    *     (  * A       G 5
 * l   *   A  *  (   (  =   , (      *  *
  (  *  =    !       A  *    1    ( 5
  (    ,  (   ( *  (     ( A     Y   5
  7
 *     (        Y    W   * b (    
 *      *  *    *    *     (  * A  5
    (  (    ( j p 7 %
q r  r s r M O T  S
    % t W     * , j %         ,  %     5
(  *   % 7 A  *    
9
 * #  *
9
 *   E t   5
 =  *   A  j  (  *  =    p  *    7 A  *  5
   (    W   % 

  

 
 
 







v
  
v
  



    

v  v
   
v



 

  


  


  
 

    

,  E  (
      %  7 7 7 t       *       G , # $ $ $ %
 #   G d %        7        %

 v



v


  








 
% 7 %      G ,
 ) )  %
 w   %    * (   % W    % +     *  
E   ( ,   5 (  (    A         
9
 *
  5  (  (    A   (  * (  

  

 
 





  
"   &
  ( ,  E  (  .  
 .  %
t  # *  ( ( *
t    t    ,
# $ $ w %
 .  , % d   j % d   %
   =   j G  5
  d  j  (  *  =       W   
9
 *      5
  * A  * j  (  *  =    p  *
   7 A  *    
 G (    (    W   E W  G 5       (  * j  (  *  5
=     % 

  

 
 
 
 2
 

 

/
       5 


v
 7 
v
 
 

 9 v 

v

 :


   

 
5 7
 :
&
  (

,  E  (  $ 
 %
t  , # $ $ w %
   >  W t %  % d    % 0 % t W %
7
9
5
y     # *       E
 E  *   W 
9
 * j  ( 5
 *  =    p  *    7 A  *      G (    ( %
    :  v
  A

v  v
   
v

 
 

  



 


  
,  w , # $ $ # %
   =  E       W      { % 
  




 



  D
 v v  




  F
 
  

  




 v
 
%   *  E  * ,  ) ) . %
   # %   *     , > %  %  *  | ,  % 0  * }  { ,
> % j    %

   A  d   5
  E    W  1  
9
 * j  (  *  =    p  *   
7 A  *      G (    ( % 

 A 
 


 A
 

A  



   ( ,  E  ( #   #  % 
  5
7 j ,
t 
# *  ( ( , # $ $ w %
  # %   *     , > %  %  *  | ,  % 0  * }  { ,
> % j    %   W  t W *    *  {   

9
j  (  *  =    p  *    7 A  *      G ( 5
   ( %  


 

v  
&
  (
 M 



 O 

 
   
/



 
    & P Q
 ,  E  (   ) $ 
  ) %
t  ,   *  E  * 5 p  *  E , # $ $ w %
 )  # %   *     , > %  %  *  | ,  % 0  * } 5
 { , > % j    %
t    *  (     G

9
   W   *  (       W  1   (
9
 * # *  A  5
 E    
A  * (  j p 7  G (    ( % 
M 



 O 

     
/



 
   
(  V V ,
 E  (    $ %   *  E  * 5 p  *  E , # $ $ . %
  $  # %   *     , > %  %  *  | ,  % 0  * }  { ,
> % j    %
0   5 *     W 
9
 *
   A  E  W  # *       E # *  =     j  ( 5
 *  =    p  *    7 A  *      G (    ( %


 A 
 


 A  

A  



   V ,  E  (
# ) #  # )  % 
  7 j ,
t 
# *  ( ( , # $ $ . %
     %   E W   %  G %
O 
9

 \


5 




v






    


%
t  # *  ( ( ,  ) ) ) %
258 Redes y Comunicación
    
                   " $
 '     " )    ,  )   '  
  
     ,   5

      " '   " :
; < = ? @ B D F G H I J < L < ; O Q ? @ T I L < U < V X F Y [ G H L < \ ] ? B T
_ a
Y ] G O ? e T O h B i Y F h Y ? V ] l G @ h T @ J ? Y ] O B ? m m G p F Q T @ r X B h Y ?
t
F h u < v ?
a
B h O O ? w U ? = ? F Y [ ?
t
F h u < e T O h B i Y F h Y ? y ? O G F Y h ?
z
? O G { ? F m @ T I Q ? O Q ? @ T I {
a
? F Y [ G H } ~ h F Q T w ? € < ] Y O r < G
a
{ m ] ? B T ~ m h
a
Y ? < ] l u < G
a
ƒ … † ‡ ˆ … ‰
Š ‹ Œ  Œ   ‘ ’ “ •  Œ ’  — ‘   • ˜ ‹ ‘  š — › ‘ “ ˜   “ ž  Œ Ÿ  
 
• ‹
 
‹ • ˜ — ‹ ‘ “ ‘ Œ ‹
 
‹ •  
 
“ • “ ˜ “ ž — ’ “ ’ ’  Œ  • ¥ — ˜ — ‹
§ ¨
‹ © ª — ‘ ˜ ‹ •
 
‹ • “ ‘  ‘ — ‘   • ¬ “ ˜  Œ ® ˜ ‹ ‘ °   “ ’ ‹ ±
•  Œ ³ ´ ‹ — ‘ ˜ ž  Œ ‹ °  Œ ˜ “ ‘ “ ž  Œ ¥ — •   “ ž  Œ
§ ¶ ·
Œ ª
 
“ • “  ž ž ‹ º © — ‘  ° » “ • ¼ ‹ ½ ž “ ° “ ® ‹ • ¾ “ ’  ž “ Œ — ° ±
 
ž  °  ‘  “ ˜ — ‹ ‘  Œ ‘ ‹ ‹ ¬ •  ˜  ‘  “ ‘  ‹ Œ
¶ ·
Œ
 
‹ • Ÿ  
 Œ ’  ° “ Œ — “ ’ ‹ ˜ ‹ Œ  ‹ Œ ‹  ‘  ¿ • ° — ‘ ‹ Œ ’   •  “ ’ 
˜ À —
 
º Á ‹ Œ ‹  • ‹ Œ ˜ •   ° ‹ Œ Ÿ    ž ‘  °  • ‹ ’ 
¶ ·
Œ
‘  ˜  Œ “ • — ‹ Œ  ‘ ž ‹ Œ ˜ ‹ ‘ °   “ ’ ‹ •  Œ
 
“ • “  ž Œ ‹
 
‹ • ±
  ’ 
¨
‹ ©
 
  ’  Œ  • •  ’  ˜ — ’ ‹ Œ — ¼ ‘ — à ˜ “  — ¥ “ °  ‘ ±
   ž — ° — ‘ “ ‘ ’ ‹ ˜ —  •  “ Œ •  ’  ‘ ’ “ ‘ ˜ — “ Œ  ‘  ž
 
• ‹ ±
˜  Œ “ ° —  ‘  ‹ ’  ž  •  à ˜ ‹ º Ä ‘
 
“ •  — ˜  ž “ • ½ “ ž ¼  ‘ “ Œ
’  ž “ Œ ’  ˜ — Œ — ‹ ‘  Œ ’ 
 
ž “ ‘ — à ˜ “ ˜ — › ‘ À  ˜ À “ Œ  ‘ ž “ Œ
— ‘   • ¬ “ ˜  Œ ’  •  ’
 
  ’  ‘ Œ  • ¬  ˜ — ž °  ‘   •    — ±
ž — Æ “ ’ “ Œ  ‘ ž ‹ Œ ˜ ‹ ‘ °   “ ’ ‹ •  Œ Œ — ‘ “ ž   • “ • Œ — ¼ ‘ — ±
à ˜ “  — ¥ “ °  ‘    ž ˜ ‹ °
 
‹ •  “ ° —  ‘  ‹ ¼ ž ‹ » “ ž ’  ž ‹ Œ
 
ž “ ‘ — à ˜ “ ’ ‹ •  Œ º
Ç È Ê
‰ Ë Ì Í Î ‡ Ï Ï Ð Ñ ‰
Ò  ˜ À “ Œ ’  ž “ Œ “
 
ž — ˜ “ ˜ — ‹ ‘  Œ Ÿ   Œ   Ó  ˜   “ ‘ À ‹ ®
’ ¾ “  ‘ Ô ‘   • ‘   ‘ ‹ • ° “ ž °  ‘  
 
•  Œ  ‘  “ ‘ •  Ÿ  — ±
Œ —  ‹ Œ ’  “ ‘ ˜ À ‹ ’  » “ ‘ ’ “ ® Õ ‹ ž “   ‘ ˜ — “ Ö ³ × Ø º Ú
¿ Œ  ‹ Œ Œ  ž  Œ ˜ ‹ ‘ ‹ ˜  ˜ ‹ ° ‹ •  Ÿ  — Œ —  ‹ Œ ’ 
¨
‹ © º
Û “ ’ ‹ Ÿ   ž ‹ Œ ˜ ž  Œ   • Œ Œ   Œ   ‘ ˜ ‹ ‘ ¥ — •  —  ‘ ’ ‹ ž “
¬ ‹ • ° “ °  Œ
 
‹
 
 ž “ •
 
“ • “
 
• ‹
 
‹ • ˜ — ‹ ‘ “ • Œ  • ¥ — ˜ — ‹ Œ
À “ ˜ — “ Ô ‘   • ‘   ½
 
“ •  ˜  • “ Æ ‹ ‘ “ » ž  Ÿ    š — Œ  “  ‘
˜ —  •  ‹ Œ ‹
 
‹ •   ’ 
¨
‹ ©  ‘  ž ž ‹ Œ º
Š “ ° “ ® ‹ • ¾ “ ’  ž “ Œ
 
• ‹
 
  Œ  “ Œ ’  ˜ ‹ ‘ °   “ ±
’ ‹ •  Œ
 
“ • “ ˜ ž  Œ   • Œ ˜ ‹ ‘ Œ ‹
 
‹ •   ’ 
¨
‹ © — ‘ ˜ ‹ • ±
Ü Ý Þ ß à ß á â ã â ä å æ â Þ ç è å é â á ê ç â ë ì à í ß à î í â í ê ç â è å é å á
ë â ï ð ï ñ ò ê å í à ë é á å ó à ê ß å ò ð ï ô õ õ ö ÷ õ ø ù ú û ÷ ï õ ü ó é å á
à ë ý ç í ç Þ ß à á ç å è à Ý è þ ê â ê ç ÿ í ó ï ç à í ê ç â ê å í þ í â ã à ê â
  
 
‹ • “ ‘ ³ ´ ‹ — ‘ ˜ ž  Œ ‹ °  Œ
¶ ·
Œ ½ “ Œ — ¼ ‘ “ ‘ ’ ‹  ‘
¶ ·
’ — ¬  •  ‘   “ ˜ “ ’ “ ˜ ž “ Œ  ’   •  à ˜ ‹ º Ä Œ  ‹ — ‘ ˜ •  ±
°
 ‘  “ ž “ ˜ ‹ °
 
ž  Ó — ’ “ ’ ’  ž ˜ ‹ ‘ °   “ ’ ‹ • ®  “ ° ±
» — ¿ ‘ — °
 
— ’   ž  Œ ‹ ’   Œ ‹ Œ
¶ ·
Œ
 
“ • “ ‹  • ‹ Œ
 
• ‹ ±
 
› Œ —  ‹ Œ º
 ‹ • ‹  • ‹ ž “ ’ ‹ ½ ž “ Œ — °
 
ž  °  ‘  “ ˜ — ‹ ‘  Œ à ‘ “ ž  Œ
’  ˜ ‹ ‘ °   “ ’ ‹ •  Œ ‘ ‹ Œ   ž  ‘ — ‘ ˜ ‹ •
 
‹ • “ • ’  ° “ ±
Œ — “ ’ ‹ Œ
¶ ·
Œ º Ú ’  °  Œ ½  Œ   ’ — ‹ Œ •  ˜ —  ‘   Œ Ö  Ø Œ  ±
¼ —  •  ‘ Ÿ   ˜  “ ‘ ’ ‹ ž “   ˜ ‘ ‹ ž ‹ ¼ ¾ “ ž ‹
 
 • ° —  “ ½ ž “
  ‘ ’  ‘ ˜ — “ Œ  •  — ‘ ˜ •  °  ‘  “ •  ž ‘  °  • ‹ ’ 
 
  • ±
 ‹ Œ
 
‹ • ˜ ‹ ‘ °   “ ’ ‹ • ½  ‘ ž  ¼ “ • ’  — ‘ ˜ •  °  ‘  “ •
ž ‹ Œ
¶ ·
Œ
 
‹ •
 
  •  ‹ º
Œ  “  Œ ½ ’  À  ˜ À ‹ ½ ž “   ‘ ±
’  ‘ ˜ — “ Ÿ    Œ   ‘ Œ — ¼  —  ‘ ’ ‹ ž ‹ Œ ¬ “ » • — ˜ “ ‘   Œ  ‘
ž ‹ Œ ‘   ¥ ‹ Œ
 
• ‹ ’  ˜  ‹ Œ Ÿ   ž “ ‘ Æ “ ‘ “ ž °  • ˜ “ ’ ‹ º
Ä ‘  Œ    • “ » “ Ó ‹ ° ‹ Œ  • “ ° ‹ Œ Ÿ   Œ ‹ ‘ Œ  à ˜ —  ‘ ±
  Œ ’ ‹ Œ
¶ ·
Œ  ‘ ˜ “ ’ “
 
  •  ‹ ’  ž ˜ ‹ ‘ °   “ ’ ‹ •
 
“ ±
• “
 
• ‹
 
‹ • ˜ — ‹ ‘ “ •
¨
‹ © º Š ‹ Œ •  Œ  ž  “ ’ ‹ Œ ’  Œ — °  ±
ž “ ˜ — › ‘ °   Œ  • “ ‘ Ÿ   ž “ Œ “
 
ž — ˜ “ ˜ — ‹ ‘  Œ ‹ »  —  ‘  ‘
 ‘ “
¨
‹ © Œ — ° — ž “ • “ ž “ ‹ »   ‘ — ’ “ ˜ ‹ ‘ ž “ Œ
 
• ‹
 
  Œ ±
 “ Œ  • “ ’ — ˜ — ‹ ‘ “ ž  Œ ½
 
 • ‹  Œ “ ‘ ’ ‹ °  ‘ ‹ Œ
¶ ·
Œ ® ½
 
‹ •  “ ‘  ‹ ½ °  ‘ ‹ Œ  Œ
 
“ ˜ — ‹ ’  »    • ®  ‘ °  ‘ ‹ •
 —  °
 
‹ ’ 
 
• ‹ ˜  Œ “ ° —  ‘  ‹ º Ä Œ  ‹ Œ 
 
  ’  ˜ ‹ ‘ Œ  ±
¼  — • •    — ž — Æ “ ‘ ’ ‹  ‘ ž ‹ Œ ˜ ‹ ‘ °   “ ’ ‹ •  Œ “ ž ¼  ‘ “ Œ
’  ž “ Œ ’  ˜ — Œ — ‹ ‘  Œ ’ 
 
ž “ ‘ — à ˜ “ ˜ — › ‘ •  “ ž — Æ “ ’ “ Œ  ‘
ž “ Œ — ‘   • ¬ “ ˜  Œ ’  •  ’ º Š “ ¬ ‹ • ° “ ’  À “ ˜  •  Œ  ‹
 Œ   — ž — Æ “ •  ‘
¶ ·
 
“ • “  ž  •  à ˜ ‹ ˜ ‹ ‘ ‘  ˜  Œ — ’ “ ’
’  ¼ “ • “ ‘  ¾ “ Œ ’ 
¨
‹ © ® ‹  • ‹
 
“ • “  ž •  Œ  ‹ ’  ž
 •  à ˜ ‹ º
Ä Œ   “ •  ¾ ˜  ž ‹ Œ   Œ  •  ˜   • “ ’  ž “ Œ — ¼  —  ‘  
¬ ‹ • ° “   ‘ ž “ ©  ˜ ˜ — › ‘  Œ  •  ¥ — Œ “ ‘ ž “ Œ
 
• ‹
 
  Œ ±
 “ Œ  š — Œ   ‘   Œ
 
“ • “
¨
‹ ©  ‘ ˜ ž  Œ   • Œ º Š “ ©  ˜ ˜ — › ‘

Œ  ˜  ‘  • “  ‘ ‘   Œ  • “
 
• ‹
 
  Œ  “ º  — ‘ “ ž °  ‘   ½
ž “  ¥ “ ž  “ ˜ — › ‘ ’  ž “ Œ
 
• ‹
 
  Œ  “ Œ Œ  •  “ ž — Æ “  ‘ ž “
©  ˜ ˜ — › ‘  ® ž “ ©  ˜ ˜ — › ‘  ˜ ‹ ‘  —  ‘  ž “ Œ ˜ ‹ ‘ ˜ ž  Œ — ‹ ±
‘  Œ ®  ž  • “ » “ Ó ‹ ¬    • ‹ º


              
           "     $ & " 
)
* 
)
+ $    /  1 $ * 2
   /   $    / $ 5  +   $ *  5    
)
 *  $
)
" * "
<
 = ?
  /   $       5  *
)
 * " 
B C

)
" * "
)
* 
)
 * 5   2
 " *  
)
 *  $ / $
<
 = ?    * $    H  * $ 5  $   $ 
 $ $  5 + $   * "     $   H  / " * $  L  N    "  / P 
B
L
 R
)
* $   S / 1 "  5 $ / =    5 &   V
W
S = X ? L  N    "  /
Y Z [  
)
 *  " & "   " ^ Z
B C
 ?   *   *   " /  b  "
" * d +   $ 5  + * " S = Y ^ [   5  *
)
 * " & "   "  h
B C
 ?
  $  5 "   / $ 
)
 $ $   " * +  V * "    $ *  / $
B C
 b $    * $ d + $ *  * l " +  " m * " 5 5  n    V   N 5 "   1 "
/ $  5 & 
)
P
)
 / * l " & " 5 $ * / $ 
)
*  5 $  "  $    / $
  
)
" d + $  $  +  "  " * $ " / $ "   " /  5 
)
 $ o " ?
  *   *   " /  b & " & " r  / 
)
* 
)
+ $   "  d + $   2
 $   "   m * $ 5 $ *
<
 = 5    "   n   /  
B C
 ?   *
$ o $
)
  b $  S 1  5   =  Y

[ $  +  5 "   r  $  5    2
5  /  / $ $    ?   S 1  5   =  5 "
)
" u / $  $ V * $ V " *
$   * H N 5  $  /   5 "  $ V  * l "  b +  "
)
* $ m $ * $   $ P
  * "   * "  ? =   $ r " * V  b $   H     " /  " $   "
5  "   N 5 " 5  n  P  
)
+ $ / $ /  m $ * $  5  " * H  5 "  $ 2
V  * l "  ?      $   H  / " * $  * $ 5  $   $  / $  L   
 $ * $ 5   $  / " 5     / $ * " * & "   "   $  $ 5  "  $  / $
 * H N 5  Y  [ ?   *    "    b " +  d + $ /  m $ * $  5  " * /  
5 "  $ V  * l "  $  +  V * "  " 1 "  5 $ b
)
+ $ / $    $ *  + 2
N 5  $   $ ?
  5    * "   $ " $    b  + $   * "
)
* 
)
+ $   " $ 
  1 $ /   "
)
 * d + $ b " +  d + $ +     u "  "   n   /  
B C
 $     5   +  " /  * $  b $  5 
)
 *  "  $   
V   r "  / $  " * $ / $      " * "  / $ +  " * $ / 5  
5   +  " /  * $  / $ + 5 &   H 
B C
 ?     $ 
)
 2
  r  $
)
 * d + $    5   +  " /  * $  * $ +     u " 
)
" *  $
/ $  "  / $ 5      $  / $
)
 "   N 5 " 5  n  * $ "   u " / "  $ 
 "     $ * m " 5 $  / $ * $ / b d + $   $  $   "    
B C

5   5  "  $  / $  * H N 5 
W
)
 * $ o $
)
  b  $   "
$ 1 "  + " 5  n  / $
)
* $   " 5    $  d + $ 1 "   " 1 $ * X ?
  * $  +   " /  N  "  $  d + $  " * $ /
)
* 
)
 * 5    " + 
 $ * 1  5   /  m $ * $  5  " /  "   / "   "  5 "  $ V  * l "  / $
 * H N 5  d + $  $ 5     / $ * "  ?
 "   " /   / $      *    " r $   b  n    "  $ 1 $ 2
   P  + V * +
)
 Y  [ & " 
)
* 
)
+ $    "  V      " *
"   $  ? ~ "  / $ " m +  / " $   "  / $  + " * d +   $ 5  + 2
* " 5       $ $  V $      " *    
)
 $    1 $  $  / $
)
*   *  / " /   r * $ /   5   "  $  5 " / " r +  $ * ?  
m +  5    "  $    / $      $ " $  "  H   V  "  / $
+  " " +  
)
   " / $ /   5 " * *   $  b /   / $    5  5 & $ 
" 1 "  u " 
)
 * +  5 " * *   P " / $  "   " 
)
 * $    *  ?
=   $ r " * V  b $   "
)
* 
)
+ $   " $  5 
)
 $ o "
)
 * 2
d + $  $ 5 $    " & " * /  " * $ P  $  "   u " 5  n  $ 
)
$ 5 l N 2
5   ? S / $ H  b $  H      " / " $   +   r o $   1  
d + $  "  + $   * "
)
 * d + $ $   H
)
$   " / "
)
" * " +

$  5 "   " /  * / $ +  "    " $  "
)
" r "  " /  $  + 
   5  5 *    r " * ?    $ 5 *    r " *   $  $
)
$ d + $   
r +  $ *  $    
)
+     / $ 5 * + 5 $ d + $    " +   * $ 
/  1  / $  $  /  
B C

W
)
$ *     r +  $ *  / $ $   * " 2
/ "   V + $   $   $  /   "    
B C
 5   5 "  $ V  * l " 
/ $  * H N 5  X ?   *   *   " /  b  + $   * "
)
* 
)
+ $   " $ 
H   
)
 $ P V $  $ * "  b 5   1 $ * $   $   "   2
V +  $   $  $ 5 5  n  ?


   €         ‚      ! # ƒ  
  ƒ   ‚ € …      ƒ
  $   "  $ 5 5  n 
)
* $  $   "    + $   * "
)
* 
)
+ $  2
 "
)
" * " +  " *  "   n   /  
B C
 $    
)
+ $ *    / $
   5   +  " /  * $ 
)
" * "
)
* 
)
 * 5    " *
<
 = ? † $
$   $  /  b  $
)
+ $ / $ " 5 $  $ * " * $ 
)
*  5 $  "  $  2
  / $   
)
" d + $  $  b * $ / + 5  *  " 5 
)
 $ o  / " / / $
   5   +  " /  * $  P ‡  +     u " * $  * $    / $   
B C

)
" * "   *  
)
* 
)
n      ?    " * $ / + 5 5  n  / $
5 
)
 $ o  / " / b P  " " 5 $  $ * " 5  n  d + $ "
)
" * $ o " b  

)
  5 "  +  "
)
ˆ * /  / " / $ m +  5    "   / " /
)
 * d + $
$   H  r "  " / "  $   " $     " 5  n  / $ * $ / +  / "  2
5  "  ? ~ "  / $ " m +  / " $   "  5       $ $  * $ +     u " *
$     5   +  " /  * $  "  V +  "  / $  "  / $ 5      $ 
/ $
)
 "   N 5 " 5  n    $ 1 " / "  " 5 " r  $   "     $ * m " 2
5 $  / $ * $ / ?
 " * " d + $ $   "
)
* 
)
+ $   "
)
+ $ / "  $ * $ m $ 5   1 "
/ $ r $   "  +  * /   & 
)
n  $    ? ~ "
)
*  $ * "  + 2
)
   5  n  d + $ & " 5 $   $  d + $ $ R    $ +  5 *   $ *  
$   H   5 
)
" * "  * / $  " *   
)
" d + $  $  d + $  $ 1 " 
"  * "      * ? † $ $   $  /  b 5 " / "
)
" d + $  $  $ 2
* l " $   d + $  " /  5   +    1 $  / $  $ * 1  5   d + $  
5 " r  " * l " $     V    $    ?     $   $ 5 $ 2
 " *  
)
 * d + $   1 "   " "   $  $ * $   * / $  / $
  $ V " / " b $   $ 5 $  " *   d + $ $   $  * / $   $ "   $ 2
)
* $ 5  * * $ 5   ? † $   /    /   b / " / "   "   "  $  2
5  "   " 
)
$ d + $  "  d + $ 1 "   " "  $ o " *
)
" * "
)
" d + $  $  d + $  $ 5 $    " 
<
 = b $   $ * $ d +       
$  + P * $   *  5   1  ?
~ "  $ V +  / "  +
)
   5  n  d + $  $ 5 $    "   $ 
d + $ & " P " +  $ 5 "     / $ 5    *   / $ " /  2
  n  / $ 5   $ R    $ 
W B
S
B
X
)
" * " $   * H N 5  5  
 $ 5 $   / " / $  / $
<
 = b / $  /  d + $    V   $   " 2
5 $  $ "   r * $ +     u " /  ?   $   $ 5 "   b $  * $ d +     
$   $ 5 $  " *  
)
" * " * $    1 $ *   
)
*  r  $ "  "   2
5  " /   "        $ "  5  
)
*   *  / " / $  $   *  5  "  b
d + $     " V " * "   l " / $ "  5 &  / $ r "  / " P  "   " 2
260 Redes y Comunicación
               



        #
$ &
'
   *  $  .   $  /     0 * &     &      $  
'
 6
'
   $  0
'
    8  $   :    & <  >     $  & /  6
'
 6 8 6 :    6 >   $  
  @
'
   0    $  
'
 6
'
   $   6    $    $    #
E    6 
 H
 0   <        6  $     $  & /  6 :  
K       8   6   K 6   N   
O
$  & /  6 :      #
  $ 
P
6 R S U   :   6
O
$  & /  6 N   $ #   6  $ S
'
  
'
6    6 <      >    $ @       K 6   N    Z
    $         :     $  $ 
'
6   >    $ @  
<              6        E  N  
'
6     6  $    



0    @ 
'
6   N  
'
            $   
'
   #
   U  $    E   $     6 
 H


6 * 6 8    * 6 
     >    $        0 K  N  &     <       #
      $  & /  6   $  6       6    $  > 6  @   0
  :           
'
   :     >   6    $   #
  * 6     $  & /  6  6            
P
6 R
 K 6   8  * 6         N     * 6 <    6    #
$ 
'
 6
'
   $  R 
'
6 >  * 6  :   8    6 
'
 :   #
$      >     6 *  $   6          $   <  E
     R     $   <  E  *
'
  *  $     N  $   . 
N     6 
'
  6        0  
'
  *  
'
 :   $    N 
    :     6 *  U 6 
'
  6        @ :   0    #
>      
'
     6 
'
 :   $    8    6 
 H
  
      6              8    6 6
'
  6      0  6 
'
6  * 6  $ 6  6     *   *   6      6    
:      >  g &  $     0     6    6 *  $   6 
8     
'
   /    6 0  
'
 6       
'
    6 #
      6       $     0
'
  6    6          6
*      
'
 :   $     N  E         6   Z 
* 6 $  8 6   :       $ &  $   :    6  6 $  6   
'
6  :   $  @  * & 
'
  6          6  N   6 
   $   <  E     
N 8   *  $  0    $   <  E      6
'
   
  N  $     6 N   $ 6  6   6 
'
 :   $   0   6    6
 6 N    :     6  :   $      *      6   
* 6 *  $ 6    6  6   6 $  $ 6 0     6 6 K  U
* & 
'
 :   $       $ 
'
  6     
'
    8    0  
$    *  $  
'
 :   $    N  . 
'
  6      Z   * #
'
6  $  $  
'
      :    6 * 6  6 
'
 :   $   N   $ #
  6  $ $     
'
 6
'
 6
 H
0     $   <     &
 6   $  & /  6 :        $ 
P
6 R   @ :   0  
8    $      $  6  .  *
'
 6 0  
'
 :   $    N  . 
'
  6        $  * N  l 
'
 :   $  :        #
$ 
P
6 R U
'
6     6   >        
 H
 6     #
'
6    $              :     8  E :    
'
 :   $     >      6 *  $   6  0 $  >  :    
'
 #
    :    
'
   /    6   
'
  *  $     E   R  0
 $   $  $ 6 0 6 $  6 
'
 :   $     *  U 6 
'
  6   #
    6 $    *  $   6  
       $   <  E      0
l  $ 6  $    @  :        *      6     *   #
* 6
 H
U   $  &       $  6
'
 :   $    N  . 
'
  6      n    $  * 6  6 0  
'
   /    6 
'
  #
  E   @    6 
'
 :   $       $ 
'
  6     
'
6  :  
l  $ 6  $    @  :    
'
     :    
'
 :   $   
N  . 
'
  6      :    6 
'
      <      $     6
Z  $    $      0 :      K 6         $    #
6 *     * 6   6 * 6     
  
 0 $   
'
6  6
 *
'
  $ 6        *   $ 6 >  6 N   0  6 * 6 8    #
* 6       >    $        Z  * 6 $  8 6   :  
$ 6  6   $  & /  6 :        $ 
P
6 R $      K 6
  N    >    $  E   6 0   * 6  6 :      *
'
 
'
6   &  8  E    6   $    6    *  $   6    @ 0  6 
'
 :   $       $ 
'
  6      $    & >    $  E  #
     
'
    6  $ 
 6  6 $  6    6 0   6         >       6 
'
 #
:   $   N   $ #   6  $ $  * N  l   *  $    0    $  #
  E      o   6
 H
'
     $    $  > 6  @  Z  $ 6
'
  *  $   & :    
'
 6   E   $  * N  l     <  #
         $    6 
'
 :   $       $  $ 
'
6  6 
6 $  6    6 0      >  
'
 $ 6    :   K  U * & 
$  & /  6 N   $ #   6  $ :     K 6   N      
'
6  #
N   0     $   <           U   $   &   *
'
   6 
 8     * & 
'
  6   $    6   $   0   * 6  6 :    
  $     & * &  $     Z  $   6 *
'
6  $  *   $ 6  
8   &    $          >    $       
Z     *  0    $  
'
 6
'
   $   6    $  
6        $  & /  6 :        $ 
P
6 R      #
$   <          U >    $  E   :   6  6   *   &
$ 6  6     K 6   N       * &  0        
 6  K    6  :      .       . 6          6
$  & /  6 N   $ #   6  $ 0       6 6 <           $ 
 >   >    $ @   6     * 6 $  8 6  $    E  * 6 
 6 
 H
   6   6 *  $   6    0  6
'
   $  & #
/  6 :        $ 
P
6 R 0 *  $     6   6   
     >    0 U 6 $  6
'
     $  & /  6 N   $ #   6  $  
* 6  6 :   l  $  6  $   /     6   $  & /  6 :  
     $ 
P
6 R
 q  

r  s t u v x y  z y { |  s t } v y {
  6    > 6     $        8  * 6    8       
'
 6
'
   $ 
'
    $              $    6  0
'
    6 :     K        6     6     $      
K     *   $      *       Z
'
  *     >   0
      N    * 6   6 
'
  & *  $  6      *       U
    6         6     * 6      6 :   K  * 6 
    6   6    > 6        *      6   Z   #
XVI Jornadas de Paralelismo, JP '2005 261
   
             
$ %     
 
   
    )   +      -    $   /
                 
0    )   +       $
$ %  
6
  $  
     :
 
6
 
6
    ;         
 $  
6
/ > $    :
-         
6
 
6
      B C
$ 
6
 D 
:
)  $    
6

 F       $  D
           $   D :
   $   $   D   / 0   D           )       
  $
$ %     )  $   D      - 
  
  :
  

$   D     D     - 
6
 D    D :
 
 
6
      / >  $ 
6

     R
S
$   
  :
6
 
T
    $ 
U S T
W
6
  B $   

6
  -
 
 
+   :  ; :
$   -
 D  $   $ B 
  D      :
   / Y      $  D      
     $   - 
 
  D    $   R
 
 $  
6
  
6

 $ [ D D $ R   

D     -  / Y
   $ B    )    +     F    + :
- $  
$ 
6

     
 
^ S

 D 
   -  
   
6
D $         $ D   _  D  
6
  $   / Y 
  D $      B  D 
 $ 
6

$ D   C 
6
        
C  - $     C  D  
6

 b  
6
       D    $     
 
6
D $    - 
   $ D $  
/
0  
6
 C        
  
        
  
  $
$ %               $   
6
    D $      
        
-
g / 0    )     $
$ % :
   ;      
 $  
6

 !
# $ & ( * + ,
  i 
6
      / Y
      
6
 C         
   F
6
$ D  
6
        $        D  D    F   $ D  / 
)     
 )    
6
     
   D 
  D $ R 
  
D     -  $       D     
6
 D  
B 
 D $ :
   
   
D  
U
l g   W / Y      + - $  
 

   F  
  D           D     D $
  /
>    D     
    b  -      D  m  $    
6
              D   
6
)      /
Y  $ 
6
        
 )           - b   $ :
B     B
  
    $  $            
6
  :
6
    - b     D    $ D $     b     / Y     
6

-              D      $  
  b  
    $  $       
6
 
6
    
 $     D  
6

  
       B  D         /          $ B    
  +
6
      $     
  C  D  
   m D  $ :
D      D  $   $      D     
  D      $ R  
  D /
Y 
-
g   - $ m         
D   $ :
         $   D    $
6
 $ 
6

     
D 
^ S
/   
6
        $
$ %    -   
6
  :
)       
6
D $ 
6
   $  
 D      
6
)   :
   D  
6

    / Y        D    $ 
6
    :
  
  b  D    $     
6
)       )     :
-
 .    1 2   1
6 8 : < = ? @ B ? < D ? E F 8 = I J ? < K B 8 : < = ? @
N I F I Q ? J : B I T 8 : = : U V I X Y V K [ \ = : @
N I F I Q ? J : D I [ : D : < I K [ \ = : @
N I F I Q ? J : F @ ] ^ J : D ? E = < ? _ K [ \ = : @
N I F I Q ? J : a c V d [ \ = : @
e f J : _ ? @ D I E I _ : @ X j [ k @
e f J : _ ? @ D < ? @ @ [ I < @ l j [ k @
m E = : < o I D : @ J : < : J U V
p : = < I @ ? B _ I E q o ^ D < ? @ @ [ I < X Y k r Y E @
p : = < I @ ? I < [ q = < I ] : @ I _ q J I r Y k u E @
-
g    C          $  
D $ R  /
   D     
    b  -      D  m  $    w x  &
$ + y z { + $ & } *   + ~ * / p R     )  
  D        :
   )     $
$ D        
6
 
6
    +       :
   $
U

6
 
       
6
D $    D + $
6
W  
 
6
          ; D       D  
6
   D   

    F
6
$ D    
^ S
 /       $    
$  :
6
D   [ 
  
 $      
D + $
6
   
D    

D         q 0 q > r s  t 
  - 
  

R :
$ D   D     
    b 
U
)    
6
       
   $   
 _      
^ S
 W   D   $  R   g 
 
C    
D + $
6
/
0             - $   b  +   $     D  $   
6
     b 

   D $   
    $ 
6

    :
 D $     [ 
    F D    
         
^ S

       
6
 
6
    /         $     D    :

$  B    $ D $ R   
$ %    
C    D   

  - b      + s g g t  )   $   $ D )   
 $   :
6
    - $   b   
  F   $ D    
 _      
^ S

U
D 
  
S T
W / Y 
-
g  
 _ :
   
$ % )  $     
-     
     
6
 D             
^ S
   $      )   

 $  $      
6
 D            
^ S
 /   

     
D 
  D $ R  )    
6
        
2,0
/
     $ 
6

            D $


^
q
^
-  :
    
 D +    -      $  / q   )    l $  :
      
6
 
6
      C  D  
6

 b 
6
    :
    m   -  
6

6
  -       
6
 
6
    /
 €  ƒ 1    1    . ˆ  1
     D    $     
   $ B 
       B $ D $    [ :
 $      
   C    r Y Y Y  w / g x : w w  s  t  

q   l  ‰ 
  D 
      
6
 
6
$   
6
:
          $  / Y 
-
  $  D
  

262 Redes y Comunicación
   
             ! "  $ 
$  '
(

  
  
1
       
      
)
!   

15,625
$

   
 & 
        , 
*
-
. 

15,625 ≤

        1   3  5
  ,  8   , 
-
  9  ;
  
  
15,625

    
 & 
     $ 3  , 
.
5 & ;    
 
13,031

       
      
/
  B C     
 
13,031

       
      
0
    
 
13,031

       
      
1
  ;  9 
  
13,031

       
      
   
   G H ;
   ;   

I

 J
  C
;    ;   .    ;      G H ;
   ;   
    C
N       9
Q J 
 
   
 
;   V
  V
   V  ; 
Q 3         5     7   Q ;
   
I
 
        9 :          7    5   
 7   C ^   

Q  ;   9        G
;

I
    
  V     V  ; 
  B     Q
;     
;
   
I
 
       ;     Q 


f    V ,       

I
 
     
8   
 C g 
I


I

 ;  h   ;    ;   9
 . 
J    
9   
I
  
I


I

 ; 
        

  9   H ;    V
 C
5
I
   h       
         
< 
I
B l $
m Q ;

  ;
      l m Q ;
  
k = 1
C ^   

Q   G H ;

  G    
B
              
Q   
f  Q
I

 ;      
V    V  ; 

  9     
 Q      ;
   =    
    ;  h     


   
  
 C !  . Q J    G     
  G 
I

   
I
  
  9  
I

 ;
 & 
  Q 
  
I

       

    ;
    ; 
      < 
I
B C
g

I
 f     9       ;   
    
              ; 
  Q ;


I
  V   
   
C 5   G H ;
    
Q V . 
 ;   9 
;
  
    ;

I

  ;
 & 
 
I
  

I
  
   ; J
          ;  
C 5   G H 
;
  
          G H ;
;
  G B  9   9    

I

 B    
 ,
 Q 9
      
I

         ; 

      
Q ;

  ;
      l , m C
  ?  A   ! # $ & '  &   * , ! $ / * C E
^
 ;    
.    ;       ; 
   
t

N Q 
J       1  
   Q f    ;     
  ;
      
;  h  C 5
I
   
  
 .    ;  Q     ;   Q
   
I

;
     

I

  
I
 f  
I
  
 ;   1         
C 5   ; J
       
;           B
   ;  h            
I

   

      
I

C        Q      u   J    
       v     Q f      B   ;     

     
  

I
 f    ;
  ;    V

I
 
  ;            ;
 &  h  l m C 5     u 
   ;   h
       
  

I
 f    f 
I
   ;      ;
 &  h   Q
I


   
Q  h

   
I
     G H ;
    
 V . 
C




I
  
I
   
I
 f   
I

 f      1  

   ;
  
  v
    
 ;  u   
 Q
.    ;
I
u      
I
 f    
J    
;
    
  
 f  . C
5 v      G &  
       
I
 ; 


I
 ;  ;  h  f         V  

I

  
;
I


I
   
I
 ;  ; 
      
 V . 
C  
    
     ;   
     ;  
v    
I
 
  ;
   ;    
I
u      
I
 f       V
 
I
 ;  ;  h  C 
   
  V
Q    9  G H ;  
     u  
    
  B   ;  h           ;  h 
 ;       V       ;    v     Q f 
B  
; 
I

         f   
I
 f  
   V  
      ;  
v      

 9   f    V 

  
C
       V    ;  h  Q J 
 V     
 x 
 

-
 
 ;
     
  Q    f  



 ;  
 Q        v   G     

I
 
      C 5   

 G  ;

I
v

y
  f    

   H 9     ;

0
      F 3 5 z Q f 

I
      
I

&    ;  h       ; 
  Q     
1 

-
 C

   x  
;
  ;   ;

 x  
 ;       V  ; 
f  J 
 ;
   
   
Q 

I

   f   
I
 f      v 
I
 
         ;           ;
  
     
I
 f      

I
 
     C g


 
 
 

     1  

-
 Q
I

  
XVI Jornadas de Paralelismo, JP '2005 263
    
 
     

        
        
!
      

   " $     
     ,  
 

 

,  

! 

 
   " 0 1 
           5  7
  8      ,    5 
  :   <         > ,     7
 
     
  



   

    0
  
      D
   

     5 ,       <     ,     
   
    
H I
 D         
            7

     0
  O 
   D    

 

,  

        
  
H I
 D     
  R        
  5  V  ,
   W  

H I
 0
0
10
20
30
40
50
60
70
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
 










µs

         
0
0.2
0.4
0.6
0.8
1
0
500
1000
1500
2000
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs

   " #  %
µs&
' (
)
* 
*

+




,  -     /   !  #   % & !  ' %  0 2 * & !  * & %  & ' !    ! 0
X    Y ,   Z  ,  
     
        

  
    [        [    + D > ,        

       

 < 8     
        0 X 

   ,
 [    

 7
   
   [        [        


       
  
    0
      [   > ,    
   <  5 
  
    
V  
  

   ,   ,    
          


 7
5   D  ,  > ,             

        7

   , 

      Y   
 0 1   <  D     Y ,  
Z
  5  V   ,  
    R ,         
  5 ,   
 ,  ,  
 [     
    D > ,        

  5  5  7
       > ,     
      , 

 > , 
  
V

 
  5  :    ,    
 [     0 X      , 
        

 

,  
        
F    $


 
  
    


 5    D

                  

   $        
 
 D

  > ,   , g  

 7
> , 
       [ h            0 1   
 8 Y ,   D
   [        <         

    
     h    
[  
     0
1      Y ,      
               

  
 < 8     ,    0 j   ,             7

       k 1 1 1 D  
   [        [      5   h 
    W   ,    
    $ : 

           Z l
  0 m ,  > ,   
       Y ,      
    7
   D  

 

,  
       

  

   , 
,          
      ,       Y   
 0   $
> ,         > ,   ,  
 

 

,  
       Y , 
   ,      [        <         
    $ : 

 
g  
     [       

               
F
   0 o     5   Y  D       , 
      
   [ h 
0
20
40
60
80
100
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs













µs

         
0
0.2
0.4
0.6
0.8
1
0
500
1000
1500
2000
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs

   " #  %
µs&
' (
)
* 
*

+




0
5
10
15
20
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
' (
)
 8


9




 :
*
; <

         
0
0.2
0.4
0.6
0.8
1
0
500
1000
1500
2000
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
' (
)
* 
*

+




>
#     %
µs&
,  -    5 /   !  #   % & !  ' %  0 2 * & !    !  & 0
 


 5    $  ,

    ,    Y   8 
 [   [   
  5              

   0
X      , 
      
 < 8    [ h    D > ,   
 ,  
         Y ,  

D                  
 ,    D  ,  > ,     
    $   : 

       Y 
  $     0 o     5   Y  D        

      Y  
> ,      k 1 1 1

    



  
 < 8 
!

  
 
    $ : 

  D ,   <       Z l l   " D   

  

 

,  
     h  

  R 
   
 [ <      0
0
50
100
150
200
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
 










µs

         
0
0.2
0.4
0.6
0.8
1
0
500
1000
1500
2000
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs

   " #  %
µs&
' (
)
* 
*

+




0
5
10
15
20
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
'
(
)
 8



9





:
*
;
<

         
0
0.2
0.4
0.6
0.8
1
0
500
1000
1500
2000
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
'
(
)
* 
*

+




>
#     %
µs&
,  -    < /   !  #   % & !  ' %  0 2 * & !  B C !  & 0

  
          
 < 8           
 
p
 o D       , 
      
 < 8      Y    7

       

    
        Y ,    0 1   

   D   O    Y    
h  > ,               
 

   ,
 [     $     8 Y ,   > ,       
> ,   
       Y ,      
       0 1 
  
    

     
 D     > ,   
H
m
H
      Y 
  Y    
 W   > ,  g , 5      , 8   
   g   
264 Redes y Comunicación
0
50
100
150
200
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
















µs

      
0
5
10
15
20
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
 

 


 









      
$ %     &
             ( )        %       
    "
   

                         
"
$ &
'     

   ,  

           1   ,  
 1     

        5 7                
"
$ ,       



           :  
; <


  >
 

             @       

    &
0
2
4
6
8
10
12
14
16
18
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
 

 


 









      


A  C  D E F F E G H J E  K L H
0
2
4
6
8
10
12
14
16
18
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs
 

 


 









      


N 


L E

 
E O H J E  K L H
0
2
4
6
8
10
12
14
16
18
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs



 


 









      


D 

E O H J E  K L H
0
2
4
6
8
10
12
14
16
18
0 0.2 0.4 0.6 0.8 1
Tradicional 2 CVs
Nuevo 2 CVs
Tradicional 8 CVs



 


 









      


R 

A D   L K S G R
$ %    $ &
             ( )                 "
   U  W                 @        @ >

   @                        
"
$ ,    @            @  a     @

   >
@          5 7  1               1     >
  & f    i     @        

      U    

 >
      U          U       >     &       >
   

    5 7                     
            & $   o    W     1       5 7 
 '  )   + -     +   U               @    >
 ,    1      5

    

   

        
    @ 5 p  @ 

                  >     &
;
@

  @  U       7 i    ,   @    
.  0  1 ' 1   0 )  4 5 7 s
,
8  -  . 4 5 7 t       

      U     @ 5 p  @  & $    @   i ,     
.  0  1 ' 1   0 ) . 4 5 7                  &
'  @   U   1   ,

        

    @     >
   ,       5 7     >        i    s ,

 
    ,  t      5    i      t          :     
     @     &         5 7     :     + 1 0 )   7 + -
    +         i   @     &
'    5 7    7 + -     + s     5 7   0 '
<   8  
        @   

          i  

   >
    &
;
@  

    U   ,      .  0  1 ' 1   0 )
. 4 5 7 t                  ,        
@               & '      1        ,    
            



     .  0  1 ' 1   0 ) . 4 5 7
    @   @  1             @ 5    U    
     U       >     &
 y
z { |  ~  € z {   

‚    z  ~ ƒ ~ ‚ z
'         :         „  @   U            
 a          U               & '  @   
    t       

          @             
 a          1            
; <
  @   U  >
        U    , 1               
& f  

          1        o     

       5 7 >
     1        
"
$     @  s   @        
 a  @              s       ,      s      U  >
    @ 5 p  @  &   

       5 7     >     ,
     U                  @         

  
  

      U     & ˆ      @  ,   @      
1         



                 @       >

    &
$           
; <


   t     
"
$
      U ,       



         i   t   >
   @   „ @     

            

     


 p  @    :            & '           5 7 
1           i      o    
"
$ ,   @       >
         
; <
         @        @     ,

            a      „  s    @      t  >
        :              i  o   & $    @   i ,
  

       5 7     >     ,   @         >
     t            @     @  s

  ,

 >
1      t                 5 7  @ 5 

      >
  s   @        U     &        ,       



      o 1       i        t          :  &
'    @              U       o      
XVI Jornadas de Paralelismo, JP '2005 265
    

                         #
$ 

  &   (  )   ,    &  

 

          0
         &    (        &      & 8    & 0

(    ;  

         =              

  0

    # ?   & 8  , ;     &  

    (  A      
             &      &           E    0
  G         (           K 

 #    N (  0
&  ,  &   A     &                &

(  &   0
  (      &             R             
(   )           

  T    K   
  

    U  0
&     (                 (     8    G   &


         #
Y Z
Z [ Z \ ] ^  _
` a b ?  c      
  K   )        K     0
  

   =      #    K     (  

  ,
 c   (   (      
              
     !       "  R   ? g E g E
&  &     #
`  b j #
k
K  G       n #    c     # n  (  0

( 

          
 0 (                0
   # E              %


'   (    )
* * ,         , j  c  &     p p  #
`

b . # q  ( ( G ,  #
k
  c  G ,    r # q     0
   # ?   K        R K   c        

  K u      # E              0 
1 2
)      )   4   %            , a    #
`  b E # $ ( K     G , q #
k
K    ,
v
#          ,  #
j    ,    ? #      

  #  K   
  

        ) R    & 
  K R          K 0
&    

   =       ?   c   c  
# %




  7   , n    K  p p  #
`  b E $ $ $ #  p  # a q 0  p p  g       R   (    (
   &   

 (         
    #    

     9                 9    < = >  @  ,
 p p  #
`  b E  =            ? 
        # %  B      
              B           )  D E F     &
  D E * ,

      p p p #
`  b  # I    # (       )     
2
   )   &
 )        
2
   K      M          &
)            N )      )    N   )       
   )        # I  K  .  (  G    g    , E   # ,
a   a #
`  b
#         , q #    c &       ,  #
v
 0
  (    ,
#   (         ,
k
# Q   K    ,
q # n  c       , q # g  

    ,    n #   0
 c     # E &

(  &        R ?  r ? g E 
   ) (  0  K 

?  n 
  K
 K    

     0
  # E              0 
1 2
)      )
  4   %            , a    #
`  b
k
# n         ) ,  # ?   ( , n #
   ,  #  #
r     ,    . # q   †  ( #
k
          
 

    
  K     )  # E  U  W
1
% ' &
 Y W W   )       ) )          F  &
   7 ,

 )   a a  [ a   , I      G  p p

#
` a p b q # n     # ?    c  G    
  
ˆ
 g
      R   c            
 
(        #
   K     (  

  , E       0
ˆ
 g .   0
   )
  

,  p p  #
` a a b r #   K    . # q  ( ( G # ?   (  G &  0
  (    

   (   c     K       R  

 0

 (           # E           
 
1
     %           
1 2
)      )  
4   &   )       )     U        &
 ,  p p a #
` a  b
#  #  

R # (  
2
  & (     
2
 b   &
      #    ) K   0 n  d  , n E  , a    #
266 Redes y Comunicación
Estudio de QoS en WLANs IEEE 802.11e
José Villalón Millán, Pedro Cuenca Castillo y Luis Orozco-Barbosa
Instituto de Investigación en Informática
Universidad de Castilla-La Mancha, Campus Universitario, 02071 Albacete, España
[josemvillalon, pcuenca, lorozco]@info-ab.uclm.es
Resumen
El IEEE 802.11 es el estándar de redes
inalámbricas de área local (WLAN) más utilizado
en la actualidad. Sin embargo, dicho estándar no
proporciona soporte QoS para las aplicaciones
multimedia. Esto ha llevado al IEEE a la creación
de un grupo de trabajo encargado de diseñar un
mecanismo que proporcionen buenos niveles de
QoS a estas aplicaciones. Este artículo introduce
ésta enmienda al estándar, llamada IEEE 802.11e.
En su descripción se muestran los mecanismos
utilizados en 802.11e para dar soporte de QoS.
Finalmente se ha realizado un estudio sobre el
comportamiento del esquema distribuido (EDCA)
presentado en 802.11e, cuando se utilizan
aplicaciones con distintos requisitos, como es el
caso de los tráficos de voz, vídeo, best-effort y
background.
1. Introducción
En la actualidad, las WLANs se encuentran en un
periodo de gran expansión, debido principalmente
a su bajo coste, su facilidad a la hora de
desplegarse, y por supuesto, a la libertad de
movimiento que otorgan a las estaciones dentro de
su área de cobertura. Otro factor muy importante
en este auge de las WLANs ha sido la aparición
en 1997 del estándar IEEE 802.11, con su
posterior revisión en 1999 [1], y sus enmiendas.
Gracias a las enmiendas a nivel físico presentadas
al estándar (IEEE 802.11a, b, c), se ha pasado de
unas velocidades de envío de 1 ó 2 Mbps a 54

Este trabajo ha sido apoyado por el Ministerio de
Ciencia y Tecnología mediante el proyecto CICYT
TIC2003-08154-C06_02, y la Consejería de Ciencia y
Tecnología de Castilla-La Mancha a través del proyecto
PBC-03-001 y de FEDER.
Mbps. Sin embargo, las aplicaciones multimedia
no solo se caracterizan por las altas necesidades
de ancho de banda, sino que además imponen
restricciones severas en cuanto a retardos,
variación en los retardos (jitter) y tasas de
descarte. Es decir, las aplicaciones multimedia
necesitan soporte de QoS (Quality of Service).
El estándar IEEE 802.11 [1] define dos
funciones de acceso al medio a nivel MAC. La
primera de ellas recibe el nombre de DCF
(Distributed Coordination Function) y utiliza un
mecanismo de acceso al medio distribuido basado
en CSMA/CA (Carrier Sense Multiple Access
with a Collisions). La segunda de las funciones
recibe el nombre de PCF (Point Coordination
Function), y utiliza la anterior como base para su
funcionamiento. PCF es opcional y usa un
mecanismo de polling que requiere de un nodo
central llamado PC (Point Coordinator) que lo
coordine.
Cuando DCF es usado, cualquier estación que
tenga datos para transmitir debe determinar el
estado del canal de transmisión. Si el canal
permanece libre durante un intervalo de tiempo
DIFS (DCF InterFrame Space) la estación obtiene
los derechos para comenzar a transmitir. En caso
contrario, la estación deberá ejecutar un algoritmo
de backoff, que asignará un número aleatorio de
slots de espera El valor de ese contador de
backoff será decrementado en una unidad cada
vez que el canal permanezca libre por un tiempo
aSlotTime. Si en un instante cualquiera la estación
detecta actividad en el canal, detendrá el
decremento del contador, hasta que el canal este
inactivo durante un intervalo DIFS. Después de
este tiempo de espera, el contador reiniciará su
cuenta atrás hasta llegar a 0, instante en el que
comenzará la transmisión de la trama. El envío de
una trama necesita la confirmación, por parte de la
estación destino de que ha llegado correctamente.
Si no es así, el emisor debe retransmitir la trama
duplicando el tamaño de la ventana. Si por el
contrario la estación emisora recibe el ACK de la
receptora, actualizará el valor de CW a CWmin.
DCF es un mecanismo simple, en el cual todas las
estaciones que intentan acceder al canal lo hacen
utilizando los mismos tiempos de espera, por lo
que DCF no proporciona ningún soporte de QoS.
Esto ha obligado al IEEE a la estandarización de
métodos para proporcionar QoS. En este artículo,
se ha realizado un estudio en profundidad sobre el
nuevo método de acceso distribuido (EDCA)
introducido en el estándar IEEE 802.11e.
Este artículo está organizado como sigue: La
sección 2 presenta la enmienda IEEE 802.11e, que
pretende proporcionar QoS en WLANs. Una
evaluación de prestaciones sobre el nuevo método
de acceso distribuido en IEEE 802.11e (EDCA) es
mostrado en la sección 3. Por último, en la sección
4 se exponen las conclusiones de este artículo.
2. La enmienda IEEE 802.11e
El estándar IEEE 802.11e [2] es una propuesta
que define los mecanismos utilizados en una
WLAN para proporcionar QoS a aplicaciones en
tiempo real como voz y vídeo. En este nuevo
estándar, se hace una distinción entre aquellas
estaciones que no utilizan los servicios QoS, que
se denominan nQSTA, y aquellas que si los
utilizan, llamadas QSTA. Para proporcionar
soporte QoS, en IEEE 802.11e se introduce una
tercera función de coordinación, llamada HCF
(Hybrid Coordination Function). HCF incorpora
dos nuevos mecanismos de acceso al canal:
EDCA (Enhanced Distributed Channel Access) y
HCCA (HCF Controlled Channel Access).
La principal característica de HCF es la
definición de cuatro categorías de acceso (AC) y
de ocho traffic stream (TS) a nivel MAC. Cuando
un paquete procedente de las capas superiores
llega a la capa MAC, es etiquetado con un
identificador de prioridad de usuario (TID) acorde
con sus necesidades de QoS. Este identificador
puede tomar valores de 0 a 15. Si el TID del
paquete tiene valores de 0 a 7, es mapeado con
respecto a las cuatro AC, usando el método EDCA
para acceder al canal. Si por el contrario el
identificador TID tiene valores de 8 a 15, usará la
función HCCA para acceder al medio, quedando
almacenado el paquete en la cola de TS
correspondiente a su TID. Otra característica
incluida en este nuevo estándar es el concepto de
TXOP (Transmisión Opportunity), que es un
intervalo de tiempo en el cual la estación que lo
posee tiene permiso para enviar sus tramas.
2.1. EDCA (Enhanced Distributed Channel
Access)
El método de acceso al medio EDCA, pretende
mejorar el funcionamiento de DCF, tratando de
forma preferencial a las aplicaciones con
restricciones en el tiempo. Para realizar esta
diferenciación, EDCA introduce dos métodos: El
primero de ellos es asignar distintos IFS a cada
categoría de acceso. Para ello, el estándar
introduce un nuevo tiempo de espera llamado
AIFS (Arbitration InterFrame Space). El valor de
AIFS es AIFS[AC] = AIFSN[AC] x aSlotTime +
SIFS, donde AIFSN (Arbitration InterFrame
Space Number), es utilizado para la diferenciación
entre las distintas AC. El segundo método
utilizado es asignar distintos tamaños de ventana
CW para cada AC. Con este segundo método, el
estándar pretende asignar menores tiempos de
espera a las estaciones más prioritarias cuando
estas tengan que efectuar el mecanismo de
Backoff. Estos tamaños se obtendrán mediante la
(a)
(b)
Figura 1. EDCA. (a) ACs en EDCA. (b) AIFS EDCA
268 Redes y Comunicación
asignación de distintos tamaños límite de ventana
CWmin y CWmax. Otro factor utilizado para la
distinción en EDCA, es la duración del TXOP
(TXOPLimit). Este parámetro limita el tiempo en
el que una estación tiene los derechos para
transmitir, sin que el resto de estaciones le
disputen el canal.
La figura 1 muestra el funcionamiento de este
mecanismo distribuido. Si nos fijamos en ella,
podemos observar como dos o más AC dentro de
una misma QSTA pueden poner a 0 su contador
de Backoff en el mismo instante. Si esto ocurre,
ambos flujos intentarán mandar los datos
produciéndose una colisión, que en el estándar
han denominado colisión interna. Siempre que
esto se produzca, la capa MAC ofrecerá la
oportunidad de transmisión al flujo más
prioritario, tratando el de menor prioridad igual
que si se hubiera producido una colisión real.
3. Evaluación de prestaciones
En esta sección, se ha realizado un estudio en
profundidad sobre el nuevo método de acceso
distribuido EDCA. Se ha partido de los valores
recomendados por el estándar (ver tabla 1), y
sobre ellos se han variado cada uno de los cuatro
parámetros que intervienen en la diferenciación de
servicio: AIFS, CWmin, CWmax y TXOPLimit (ver
tabla 2). En nuestro escenario de simulación se ha
considerado un escenario base, compuesto por
cuatro clases de servicio: voz, vídeo, best-effort y
background, y sobre el se ha evaluado el
throughput y la tasa de colisiones de los paquetes
de voz y vídeo.
Tabla 1. Valores recomendados EDCA
AC AIFSN CWmin CWmax TLimit
Vo 2 7 15 3 ms
Vi 2 15 31 6 ms
Bk 7 31 1023 -
Be 3 31 1023 -
3.1. Escenario
Para la realización de las simulaciones se ha
utilizado el simulador de redes Opnet Modeler
10.0 [3]. Se ha modelado sobre la capa física
IEEE 802.11b, utilizando un ancho de banda de
11 Mbps. Se han definido cuatro tipos de servicio,
Tabla 2. Valores utilizados para el calibrado
Vo Vi BE BK
2 2 3 7
2 2 4 7
2 2 5 7
2 3 5 7
AIFSN
1 2 3 7
7 15 31 31
7 31 31 31
7 31 63 63
15 31 31 31
CW
min
15 31 63 63
15 31 1023 1023
15 63 1023 1023
15 127 1023 1023
31 63 1023 1023
CW
max
31 127 1023 1023
0 0 - -
3 4 - -
3 5 - -
3 6 - -
TXOP
Limit
3 7 - -
Voz (Vo), Vídeo (Vi), Best-effort (BE) y
Background (BK), en línea de la especificación
IEEE 802.1D [4]. Se ha asumido el uso de una
WLAN compuesta por un conjunto de estaciones
inalámbricas y un punto de acceso conectado a
una red cableada, formando así una red BSS. Con
respecto a la capacidad del enlace cableado, se ha
supuesto que es mucho mayor que la del
inalámbrico, y que éste no puede ser el cuello de
botella de la red.
Como ya se ha comentado anteriormente, se
han utilizado cuatro tipos de tráfico para realizar
las simulaciones, y cada uno de ellos utiliza una
fuente distinta para ser generado.
Para el tráfico de voz, se ha asumido el uso de
fuentes de caudal constante con una tasa de bits de
16 Kbps, acorde con el estándar de codificación
de voz G.728 [5]. Los paquetes de voz tienen un
tamaño de 168 bytes, incluyendo las cabeceras
RTP/UDP/IP. Estas fuentes son activadas
aleatoriamente dentro del intervalo [1, 1.5]
segundos después del comienzo de la simulación.
Con respecto a las aplicaciones de vídeo, se
han usado trazas VBR generadas mediante el
codificador de vídeo H.264 [6]. Se ha usado la
secuencia mobile calendar, codificada en formato
CIF con una tasa de 25 frames/s. La tasa media de
la transmisión de vídeo está alrededor de 480
kbps, con un tamaño de paquete 1064 bytes
(incluidas cabeceras RTP/UDP/IP). Está claro que
este tipo de fuentes está caracterizado por un
patrón de tráfico periódico, y tasas de envío muy
XVI Jornadas de Paralelismo, JP '2005 269
variables. Por ello cada aplicación de vídeo
comienza a transmitir dentro de un periodo
aleatorio asignado mediante f = uniform(1;
1+12/f), siendo f la tasa de frames/s. De esta
forma, las ráfagas de tráfico son distribuidas a lo
largo de un GOP (Group of Pictures),
representando así un comportamiento similar al
real. La transmisión de un frame de vídeo está
uniformemente distribuida a lo largo del intervalo
de tiempo del frame (1/f).
Las fuentes de tráfico best-effort y
background han sido creadas usando la
distribución de Pareto, de forma que el tráfico
generado se asemeje a su comportamiento
irregular y variable. Para suavizar los picos de
tráfico generados por este tipo de fuentes, en lugar
de una única fuente por estación se han utilizado
cinco. La tasa de inyección del tráfico best-effort
es de 128 kbits/s, mientras que cada estación de
tráfico background inyectará el doble (256
Kbits/s). Ambos tipos de tráfico utilizan paquetes
de tamaño 552 bytes incluyendo en ellos las
cabeceras TCP/IP, y comienzan a generar
paquetes en el intervalo [1, 1.5] segundos desde el
comienzo de la simulación. El tiempo de
simulación de todos los escenarios ha sido el
mismo, dos minutos.
Para medir las prestaciones de la red, se han
seleccionado 3 métricas: Throughput, tasa de
colisiones y tasa de pérdidas. Dado que cada una
de las fuentes inyecta una cantidad distinta de
datos, se ha optado por normalizar el throughput
de cada tipo de tráfico con respecto al tráfico
inyectado.
3.2. Resultados
La figura 2 nos muestra el throughput, las
colisiones y el número de paquetes descartados
para los flujos de voz y vídeo, cuando se varían
los valores de AIFSN. Los valores mostrados en
las gráficas muestran el AIFSN asignado a BK-
BE-Vi-Vo respectivamente. En 2.a se muestra el
comportamiento del tráfico de voz. En ella se ve
claramente la correspondencia entre número de
colisiones de este flujo, y sus prestaciones. Esto se
debe a que el tiempo que los paquetes se
encuentran encolados en cargas altas de la red es
muy alto en relación al deadline fijado (10 ms).
Por ello, un paquete que tenga que ser
retransmitido tendrá una alta probabilidad de ser
descartado. Los resultados de esta figura nos
muestran que para este tipo de tráfico los valores
recomendados por el estándar no son muy
convenientes. En concreto, estos valores producen
los peores resultados de todos los estudiados. En
la figura se muestra como las prestaciones de este
tipo de tráfico aumentan al asignar AIFSN
distintos para los flujos de voz y vídeo. Este
comportamiento es lógico ya que al asignar
valores distintos se prioriza más al tráfico de voz,
además de reducir la probabilidad de colisiones
como queda plasmado en la figura.
La figura 2.b muestra las prestaciones para el
tráfico de vídeo. Al contrario que para la voz, este
no se ve muy influenciado por la modificación de
este parámetro. Si bien esto es cierto, la figura
muestra un ligero aumento del throughput cuando
el valor de AIFS asignado al tráfico BE está más
alejado del AIFS del vídeo.
El throughput, las colisiones y el número de
paquetes descartados para voz y vídeo al variar el
CWmin son mostrados en la figura 3. Este
parámetro nos indica el valor inicial de la ventana
de Backoff, así como el valor que será
incrementado después de una colisión. Los valores
mostrados en las gráficas muestran el CWmin
asignado a BK-BE-Vi-Vo respectivamente.
Al igual que ocurría en 2.a, en 3.a se ve
claramente la dependencia del flujo de voz, del
número de colisiones que presenta. Como era de
esperar, el throughput de este tipo de tráfico
aumenta, al asignar CWmin mayores al resto de
flujos. Con ello, además de aumentar su prioridad,
se reducirá su número de colisiones (ver
retransmisiones de voz). Además de esto, la figura
nos muestra que el valor de CWmin para este tipo
de tráfico debe ser pequeño, reduciéndose sus
prestaciones al aumentarlo.
El comportamiento del tráfico de vídeo es
mostrado en la figura 3.b. El throughput de en este
tipo de tráfico no varía demasiado, aunque
aumenta ligeramente al alejar los valores de
CWmin asignados a BE y BK del suyo. Por otro
lado, la figura muestra que el aumento de su
CWmin no repercute negativamente en sus
prestaciones. Es más, debido a que este tráfico es
bastante más pesado, el aumentar levemente su
CWmin reducirá el número de colisiones sufridas
por este tráfico, manteniendo o incrementando sus
prestaciones.
270 Redes y Comunicación
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Voz
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Voz
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Voz
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
(a)
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Video
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Video
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
0 0.2 0.4 0.6 0.8 1
0
0.05
0.1
0.15
0.2
0.25
0.3
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Video
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
(b)
Figura 2. Prestaciones de EDCA usando diferentes AIFSN. (a) Voz. (b) Vídeo
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Voz
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Voz
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Voz
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
(a)
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Video
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Video
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
0 0.2 0.4 0.6 0.8 1
0
0.05
0.1
0.15
0.2
0.25
0.3
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Video
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
(b)
Figura 3. Prestaciones de EDCA usando diferentes CWmin. (a) Voz. (b) Vídeo
XVI Jornadas de Paralelismo, JP '2005 271
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Voz
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Voz
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Voz
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
(a)
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Video
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Voz
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
0 0.2 0.4 0.6 0.8 1
0
0.05
0.1
0.15
0.2
0.25
0.3
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Video
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
(b)
Figura 4. Prestaciones de EDCA usando diferentes CWmax. (a) Voz. (b) Vídeo
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Voz
6−3
0−0
4−3
5−3
7−3
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
1.2
1.4
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Voz
6−3
0−0
4−3
5−3
7−3
0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Voz
6−3
0−0
4−3
5−3
7−3
(a)
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Trafico de Video
6−3
0−0
4−3
5−3
7−3
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
1.2
1.4
Carga Total Ofrecida
Retransmisiones
por
Paquete
Trafico de Video
6−3
0−0
4−3
5−3
7−3
0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
Carga Total Ofrecida
Tasa
de
Perdidas
Trafico de Video
6−3
0−0
4−3
5−3
7−3
(b)
Figura 5. Prestaciones de EDCA usando diferentes TXOPLimit. (a) Voz. (b) Vídeo
272 Redes y Comunicación
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Throughput Global
7−3−2−2
7−4−2−2
7−5−2−2
7−5−3−2
7−3−2−1
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Throughput Global
31−31−15−7
31−31−31−7
63−63−31−7
31−31−31−15
63−63−31−15
0 0.2 0.4 0.6 0.8 1
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Throughput Global
1023−31−15
1023−63−15
1023−127−15
1023−63−31
1023−127−31
0 0.2 0.4 0.6 0.8 1
0.4
0.5
0.6
0.7
0.8
0.9
1
Carga Total Ofrecida
Throughput
Normalizado
Throughput Global
6−3
0−0
4−3
5−3
7−3
Figura 6. Throughput global de la red al modificar cada uno de los cuatro parámetros
La figura 4 muestra el estudio realizado
cuando el factor modificado es CWmax. Los
valores mostrados en las gráficas muestran el
CWmax asignado a (BK y BE) - Vi - Vo
respectivamente. Dado que este parámetro solo es
utilizado cuando un paquete debe ser
retransmitido varias veces, los resultados para
cargas bajas son similares para todos los valores.
A partir de una cercana al 80\% se empiezan a
notar diferencias.
En 4.a se muestran los resultados obtenidos
para el tráfico de voz. A diferencia de los
parámetros anteriores, al modificar este parámetro
no se obtienes throughput muy distintos. Esto se
debe a que al colisionar, los paquetes de voz
tienen una alta probabilidad de ser descartados,
por lo que pocas veces alcanzaran su CWmax. De
todas formas, al aumentar el CWmax del resto de
tráficos, los paquetes de voz se pueden ver
ligeramente favorecidos.
Las prestaciones del tráfico de vídeo se
muestran en la figura 4.b. En ella se ve que a pesar
de reducir el número de colisiones de los paquetes
de vídeo, si se aumenta su CWmax, el número de
paquetes descartado aumentará, disminuyendo así
su throughput. Esto se produce porque los
paquetes de vídeo tienen un deadline mayor, y
admiten varias retransmisiones, por lo que se
alcanzará su CWmax. Al asignarle un tamaño de
ventana mayor, se reducirán las colisiones, pero
por el contrario el resto de flujos tendrán más
opciones de hacerse con el canal.
Por último, en 5 se muestran el throughput, las
colisiones y el número de paquetes descartados
para los flujos de voz y vídeo, cuando se varían
los TXOPLimit asignados. Las oportunidades de
transmisión, que fueron descritas en el apartado 2,
son asignadas solo a los tráficos real-time para
intentar cumplir con sus requerimientos. A pesar
de esto, dado que las fuentes de voz utilizadas
inyectan paquetes cada 80 ms, y su deadline es
únicamente de 10 ms, nunca podrá haber dos
paquetes en la cola de voz, por lo que este tráfico
no se podrá beneficiar de la asignación de un
TXOP. Por ello, la estaciones mandará
únicamente una trama, y liberará el medio para
que el resto de estaciones intenten ganarlo (igual
que si no se le asignara un TXOP). En la figura
5.a se ve claramente este efecto. Si no se usan
TXOP, el número de paquetes descartados de este
tipo de tráfico es mucho menor, aumentando por
ello el throughput. En la figura también se muestra
la independencia del número de colisiones de este
parámetro.
Por el contrario, el tráfico de vídeo si inyecta
una cantidad de paquetes más elevada, sobre todo
cuando se encuentra con un frame de tipo I. Por
ello, la utilización de TXOP maximiza su
throughput. Esto queda reflejado en la figura 5.b.
En ella se muestra el gran aumento de las
colisiones, y como consecuencia, la reducción
drástica del throughput cuando los TXOP no son
utilizados. De los resultados también se puede
intuir que un valor de TXOPLimit mayor de 6 ms
para este tipo de tráfico tampoco es conveniente
ya que no aumenta las prestaciones de para los
paquetes de vídeo, y además repercute
negativamente en el resto de tráficos.
Para finalizar este estudio, en la figura 6 se
muestra el throughput global de la red al
modificar cada uno de los cuatro parámetros
estudiados. En ella se muestra claramente como el
throughput global de la red al modificar el AIFSN,
CWmin y CWmax es prácticamente el mismo para
todos los valores. Por ello, sería conveniente el
uso de los valores que maximicen las prestaciones
de los flujos real-time. Con respecto al la duración
del TXOP, la figura 6 muestra que el uso de este
XVI Jornadas de Paralelismo, JP '2005 273
es necesario para que no decaigan las prestaciones
de la red, y que el valor asignado a los flujos de
vídeo no debe ser demasiado grande.
4. Conclusiones
En este artículo se han descrito los mecanismos
introducidos en la enmienda IEEE 802.11e para
proporcionar QoS. A continuación se ha realizado
una evaluación de prestaciones de su modo
distribuido (EDCA). Para ello se han modificado
los valores asignados a los cuatro parámetros
utilizados por el método para proporcionar QoS.
Los resultados obtenidos muestran una
correspondencia entre el número de colisiones de
la red y las prestaciones obtenidas. El esquema
EDCA garantiza unas buenas prestaciones para
cargas inferiores a 0.75. A partir de este punto, y
debido al aumento del número de colisiones, las
prestaciones obtenidas decaen rápidamente.
Los resultados también nos han mostrado que
los parámetros recomendados en el estándar no
son óptimos. Se ha visto que el parámetro AIFSN
juega un papel muy importante para proporcionar
QoS. Los resultados sugieren la asignación de un
AIFSN distinto para los flujos de voz y vídeo.
Con ello se mejoran considerablemente las
prestaciones obtenidas para los flujos de voz. De
la misma manera se ha observado que la
asignación de un AIFSN mayor para los flujos BE
aumenta las prestaciones obtenidas para el vídeo.
Por todo ello, se puede recomendar la utilización
de los siguientes valores: 7 (BK) - 5 (BE) - 3 (Vi)
- 2 (Vo). Con respecto al parámetro CWmin, los
resultados también muestran que los valores
asignados nos son adecuados. Se ha mostrado
como el tráfico de voz puede beneficiarse,
aumentando el valor asignado al resto de tráficos.
De la misma manera, y debido a la mayor tasa de
inyección, los flujos de vídeo también se verán
beneficiados del aumento del tamaño de la
ventana. Por todo ello, se puede recomendar el
uso de los siguientes valores: 63 (BK) - 63 (BE) -
31 (Vi) - 7 (Vo). Con respeto al parámetro CWmax,
los resultados nos han mostrado que este no tiene
un efecto muy importante en las prestaciones para
los paquetes de voy y vídeo. Esto se debe a que
los paquetes son descartados por deadline antes de
que la ventana llegue a CWmax. Finalmente se han
examinado las prestaciones de la red al modificar
la duración del TXOP. Los resultados han
mostrado la necesidad del uso de TXOP tanto para
mejorar las prestaciones de los flujos de vídeo,
como para mejorar las prestaciones globales de la
red.
Referencias
[1] LAN MAN Standards Committee of the IEEE
Computer Society, ANSI/IEEE Std 802.11,
“Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY)
Specifications, 1999 Edition.
[2] IEEE 802 Committee of the IEEE Computer
Society, IEEE P802.11e/D13.0 Draft
Amendment to IEEE Std 802.11, “Part 11:
Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY)
Specifications: Medium Access Control
(MAC) Quality of Service (QoS)
Enhancements”, April 2005.
[3] Opnet.Technologies.Inc. OPNET Modeler
10.0 ©1987-2004. http://www.opnet.com
[4] IEEE 802.1.D-2004: Standard for local and
metropolitan area networks.
http://grouper.ieee.org/groups/802/1/, 2004
[5] Coding of Speech at 16 kbit/s using Low-
Delay Code Excited Linear Prediction, Std.
ITU-T Recommendation G.728, September
1992.
[6] ITU-T Recommendation H.264. Advanced
Video Coding For Generic Audiovisual
Services. May 2003.
274 Redes y Comunicación
   
        
       
  "  $     $
   & (   $  , $    0 2 & $  4 & 
        
;   $ = > & 
@
A C D F H J L N P P D R S T R D F V N W V X A J H P [ D R X S A X W \ ] J _ ` F V b c d A X W \ T J e C D f X
h i j l m n o i p r s m v w x l z | } n  € |  i ‚ } „ m ‚ z l … | r z | } †  j i v z m v ‡ } |  ‚ l } o o i p r s m v w x l z | }
Š r z ‹ i v € z o } o o i  } € l z ‚ ‚ } Ž  }  } r | ’ } Š r z ‹ n „ m ‚ z l … | r z | } ” } ‚ i r | z }
• – • — ˜
Ž ™ ‚ š } | i l i ›  € j } œ }  ž
• – –
Ž ” } ‚ i r | z } ›  € j } œ }
Ÿ  
 } r } r › s } ‚ s } v m ›
 
€ } r | ’ i ¡ ¢ £ z r s m Ž } š n  | ‚ w n i €
 
o  } l m £ o z € | } n  j ‹ n i €
§ © ª « ¬ © ­
® ¯ ° ² ³ µ ¶ ¸ ² ¹ º » ¼ ² ½ ³ ¸ ¾ ¿ ¸ ³ À ¸ ³ ¼ º µ ¸ µ µ ² º ³ Á ¯ ¿ Â
Ã
¸ À º Ä ³ ° » ² ¿ Æ º À º ¯ » µ º » Ç ¯ ³ º È É ² » ¸ ¼ ¿ ¸ Æ Ê » µ ² Ë ³ Â
¼ ² ¿ ³ ² ¼ Ì ¾ ² ³ ² ¿ ¸ µ ¯ » ² ³ » ½ º ³
Ã
² ³ » ¸
Ã
¸ ° ¯ ¿ ¶ ¸ Ç ¯ ¿
É ¸ ² Î ² À ½ À º Ä ³ µ ² ¸ Ç É º À ¸ À º ¯ ³ ² » ² ³ É ¯ »
Ã
½ À Ð ¯ » » ² ¿ Â
Æ º µ ¯ ¿ ² » Ñ ½ ² ² ¹ º » ¼ ² ³ ² ³ ¼ ¯ µ ¯ ² É
Ã
½ ³ µ ¯ º ³ ¼ ² Â
¾ ¿ ¸ µ ¯ » ² ³ É ¸ º ³ Á ¿ ¸ ² » ¼ ¿ ½ À ¼ ½ ¿ ¸ µ ² É ¸ » ²
Ã
Ç ¿ ² » ¸ »
Ç ¿ ¯ Æ ² ² µ ¯ ¿ ¸ » µ ² » ² ¿ Æ º À º ¯ » Ö × ³ È ½ ² ³ ¸ Ç ¸ ¿ ¼ ² µ ²
² » ¼ ¸ » ²
Ã
Ç ¿ ² » ¸ » Ì É ¯ » ¿ ² À ½ ¿ » ¯ » µ º » Ç ¯ ³ º È É ² » ² » ¼ Ø ³
º ³ Á ¿ ¸ ½ ¼ º É º Ù ¸ µ ¯ » Ì Ç ½ ² » Ð ¸ È º ¼ ½ ¸ É
Ã
² ³ ¼ ² Ð ¸ ³ » º µ ¯
µ º
Ã
² ³ » º ¯ ³ ¸ µ ¯ » Ç ¸ ¿ ¸ Ç ¯ µ ² ¿ ¾ ¸ ¿ ¸ ³ ¼ º Ù ¸ ¿ ¼ º ²
Ã
Ç ¯ »
µ ² ¿ ² » Ç ½ ² » ¼ ¸ È ¸ Î ¯ À ¯ ³ µ º À º ¯ ³ ² » µ ² À ¸ ¿ ¾ ¸
Ã
Ø ¹ º Â
Ã
¸ Ö
× ³ ² » ¼ ² ¼ ¿ ¸ È ¸ Î ¯ » ² ² ¹ Ç ¯ ³ ² ³ ¸ É ¾ ½ ³ ¸ » º µ ² ¸ »
Ñ ½ ² Ç ½ ² µ ² ³ À ¯ ³ µ ½ À º ¿ ¸ ½ ³ ¸ º ³ Á ¿ ¸ ² » ¼ ¿ ½ À ¼ ½ ¿ ¸ µ ²
É ¯ » Ç ¿ ¯ Æ ² ² µ ¯ ¿ ² » µ ² » ² ¿ Æ º À º ¯ »
Ã
Ø » ² Ý À º ² ³ ¼ ² ° ¿ ² ³ Â
¼ ¸ È É ² Ì ° Ñ ½ ² ¾ ¸ ¿ ¸ ³ ¼ º À ² É ¯ » ¿ ² Ñ ½ º » º ¼ ¯ » µ ² À ¸ É º Â
µ ¸ µ µ ² » ² ¿ Æ º À º ¯ µ ²
Ã
¸ ³ µ ¸ µ ¯ » Ç ¯ ¿ » ½ » À É º ² ³ ¼ ² » Ö
Þ
² Ç ¿ ¯ Ç ¯ ³ ² ³
Ã
² Î ¯ ¿ ¸ » ² ³ ² É ½ » ¯ ° ¾ ² » ¼ º Ä ³ µ ²
É ¯ » ¿ ² À ½ ¿ » ¯ » Ð ¸ ¿ µ ß ¸ ¿ ² µ º » Ç ¯ ³ º È É ² » Ö
Þ
² ¼ ¿ ¸ ¼ ¸ µ ²
À ¯ ³ » ² ¾ ½ º ¿ ¸ É ¾ ¯ ¿ º ¼
Ã
¯ » µ ² Ç É ¸ ³ º Ý À ¸ À º Ä ³ µ ² Ç ¿ ¯ À ² Â
» ¯ » ² Ý À º ² ³ ¼ ² » °
Ã
² À ¸ ³ º »
Ã
¯ » µ ² À ¯ ³ ¼ ¿ ¯ É µ ² ¸ µ Â
Ã
º » º Ä ³ À ¸ Ç ¸ À ² » Ì À ¯ ³ Î ½ ³ ¼ ¸
Ã
² ³ ¼ ² Ì µ ² µ º
Ã
² ³ » º ¯ Â
³ ¸ ¿ É ¯ » » ² ¿ Æ º µ ¯ ¿ ² » µ ² ½ ³ ¸ Á ¯ ¿
Ã
¸
Ã
Ø » Ç ¿ ² À º » ¸ Ì
¾ ¸ ¿ ¸ ³ ¼ º Ù ¸ ³ µ ¯ É ¸ µ º » Ç ¯ ³ º È º É º µ ¸ µ µ ² É ¯ » ¿ ² À ½ ¿ » ¯ »
° â ¯ ² É ¿ ² ¼ ¸ ¿ µ ¯
Ã
Ø ¹ º
Ã
¯ Ç ¸ ¿ ¸ µ º À Ð ¸ » ¸ Ç É º À ¸ À º ¯ Â
³ ² » Ö
ã ä æ
­ ç è é ê « ë ë ì í ­
î ¸ ï É ¼ º
Ã
¸ µ Ê À ¸ µ ¸ Ð ¸ » º µ ¯ ¼ ² » ¼ º ¾ ¯ µ ² ½ ³ Á ½ ² ¿ Â
¼ ² º ³ À ¿ ²
Ã
² ³ ¼ ¯ ² ³ É ¸ Æ ¸ ¿ º ² µ ¸ µ µ ² µ º » Ç ¯ » º ¼ º Æ ¯ »
ð ñ ò ó ô ó õ ö ÷ ö ø ù ú ö ò û ü ù ý ö õ þ û ö ÿ ô  ó ô   ö  þ û ö ü ù ý ù õ
ÿ ö 
  þ ù  ô ÿ ý õ ù  ô þ ó ù 
              "
µ ² À ¯
Ã
Ç ½ ¼ ¸ À º Ä ³ Ì ¸ » ¶ À ¯
Ã
¯
² ³ ² É ³ ï
Ã
² ¿ ¯ µ ² É ¯ »
½ » ½ ¸ ¿ º ¯ » µ ² ² » ¯ » µ º » Ç ¯ » º ¼ º Æ ¯ » Ö # µ ²
Ã
Ø » µ ² É ¸ »
¼ ¿ ¸ µ º À º ¯ ³ ¸ É ² » ² » ¼ ¸ À º ¯ ³ ² » µ ² ¼ ¿ ¸ È ¸ Î ¯ Ì À ¯
Ã
Ç ½ ¼ ¸ Â
µ ¯ ¿ ² » µ ² » ¯ È ¿ ²
Ã
² » ¸ ° Ç ¯ ¿ ¼ Ø ¼ º É ² » Ì ³ ½ ² Æ ¯ » µ º » Ç ¯ Â
» º ¼ º Æ ¯ » À ¯
Ã
¯ % ' » µ ² È ¯ É » º É É ¯ Ì % * # » ° ¼ ² É Ê Á ¯ ³ ¯ »
Ã
Ä Æ º É ² » À ¯ ³ À ¸ Ç ¸ À º µ ¸ µ ² »
Ã
½ É ¼ º
Ã
² µ º ¸ Ì » ² ½ ¼ º É º Â
Ù ¸ ³ Ð ¯ ° ² ³ µ ¶ ¸
Ã
¸ » º Æ ¸
Ã
² ³ ¼ ² Ì Ç ¯ ¿ Ç ² ¿ » ¯ ³ ¸ » µ ²
¼ ¯ µ ¸ » É ¸ » ² µ ¸ µ ² » Ö
% ¯ ¿ ¯ ¼ ¿ ¸ Ç ¸ ¿ ¼ ² Ì É ¸ À ¯ ³ ² À ¼ º Æ º µ ¸ µ ¼ ¸
Ã
È º Ê ³ Ð ¸
Ã
² Î ¯ ¿ ¸ µ ¯ µ ² ½ ³ ¸ Á ¯ ¿
Ã
¸ º
Ã
Ç ¯ ¿ ¼ ¸ ³ ¼ ² Ö × É
Ã
Ä Â
µ ²
Ã
¼ ¿ ¸ µ º À º ¯ ³ ¸ É À ¯ ³ ² À ¼ ¸ µ ¯ ¸ É ¸ É ¶ ³ ² ¸ ¼ ² É ² Á Ä ³ º Â
À ¸ Ð ¸ » º µ ¯ » ½ » ¼ º ¼ ½ º µ ¯ Ç ¯ ¿ É ¯ » µ º » Ç ¯ » º ¼ º Æ ¯ » À ¸ Â
È É ² ¸ µ ¯ » Ñ ½ ² ¯ Á ¿ ² À ² ³
Ã
¸ ° ¯ ¿ ¸ ³ À Ð ¯ µ ² È ¸ ³ µ ¸ Ì °
° ¸ Ð ¸ ° µ º » Ç ¯ ³ º È É ² » À ¯ ³ ² ¹ º ¯ ³ ² » º ³ ¸ É Ø
Ã
È ¿ º À ¸ » ² ³
À ¯ ³ ¾ ¿ ² » ¯ » Ì ¸ ² ¿ ¯ Ç ½ ² ¿ ¼ ¯ » Ì ² ¼ À Ö
î ¸ » ¿ ¸ Ù ¯ ³ ² » Ç ¿ º ³ À º Ç ¸ É ² » µ ² É ¸
Ã
Ç É º ¯ ½ » ¯ µ ² ¼ ¯ Â
µ ¯ » ² » ¼ ¯ » µ º » Ç ¯ » º ¼ º Æ ¯ » » ¯ ³ » ½ µ º » Ç ¯ ³ º È º É º µ ¸ µ °
Ç ¯ ¼ ² ³ À º ¸ Ì ² º ³ À É ½ » ¯ Ì °
Ã
Ø » º
Ã
Ç ¯ ¿ ¼ ¸ ³ ¼ ² Ì É ¸ À ¸ ³ Â
¼ º µ ¸ µ µ ² º ³ Á ¯ ¿
Ã
¸ À º Ä ³ ° » ² ¿ Æ º À º ¯ » µ º » Ç ¯ ³ º È É ² » ¸
¼ ¿ ¸ Æ Ê » µ ² Ë ³ ¼ ² ¿ ³ ² ¼ Ö * ² Ð ² À Ð ¯ Ì É ¸
Ã
¸ ³ ² ¿ ¸ ¼ ¿ ¸ µ º Â
À º ¯ ³ ¸ É µ ² ½ » ¸ ¿ É ¯ » À ¯
Ã
Ç ½ ¼ ¸ µ ¯ ¿ ² » - Ð ¸ È º ¼ ½ ¸ É
Ã
² ³ Â
¼ ² ¿ ² Á ² ¿ º µ ¸ À ¯
Ã
¯ / 1 2 4 6 8 9 ; 8 = 9 @ 6 B D E F Ð ¸ » º µ ¯
» ½ » ¼ º ¼ ½ º µ ¸ ² ³ ¾ ¿ ¸ ³ Ç ¸ ¿ ¼ ² Ç ¯ ¿ ¯ ¼ ¿ ¸
Ã
¸ ³ ² ¿ ¸ Ñ ½ ²
Ð ¸ Æ ² ³ º µ ¯ ¸ É É ¸
Ã
¸ ¿ » ² H D 6 1 K D 1 6 ; 8 = 9 @ 6 B D E Ö % ¯ ¿
¯ ¼ ¿ ¸ Ç ¸ ¿ ¼ ² Ì Ç ¿ ¯ Ç ¯ ¿ À º ¯ ³ ¸ ¿ º ³ Á ¯ ¿
Ã
¸ À º Ä ³ ° » ² ¿ Æ º Â
À º ¯ » ¸ ¼ ¿ ¸ Æ Ê » µ ² Ë ³ ¼ ² ¿ ³ ² ¼ ² » ¼ Ø À ¯ ³ Æ º ¿ ¼ º Ê ³ µ ¯ » ²
² ³ ½ ³ ¸ ³ ² À ² » º µ ¸ µ Ç ¸ ¿ ¸ É ¸ » ²
Ã
Ç ¿ ² » ¸ » Ñ ½ ² Ñ ½ º ² Â
¿ ¸ ³ » ¯ È ¿ ² Æ º Æ º ¿ ² ³ ½ ³
Ã
² ¿ À ¸ µ ¯ ¼ ¸ ³ À ¯
Ã
Ç ² ¼ º ¼ º Æ ¯
À ¯
Ã
¯ ² É ¸ À ¼ ½ ¸ É Ö
î ¸ º ³ Á ¯ ¿
Ã
¸ À º Ä ³ ° É ¯ » » ² ¿ Æ º À º ¯ » Ç ¿ ¯ Ç ¯ ¿ À º ¯ ³ ¸ Â
µ ¯ » ¸ ¼ ¿ ¸ Æ Ê » µ ² Ë ³ ¼ ² ¿ ³ ² ¼ » ² ¾ ² ³ ² ¿ ¸ ³ ¸ ¼ ¿ ¸ Æ Ê » µ ²
¸ Ç É º À ¸ À º ¯ ³ ² » ² Î ² À ½ ¼ ¸ µ ¸ » ² ³ É ¯ »
Ã
½ À Ð ¯ » » ² ¿ Æ º µ ¯ Â
¿ ² » Ñ ½ ² ² ¹ º » ¼ ² ³ ² ³ ¼ ¯ µ ¯ ² É
Ã
½ ³ µ ¯ Ö O ½ À Ð ¯ » µ ²
² » ¯ » » ² ¿ Æ º µ ¯ ¿ ² » ² » ¼ ¸ È ¸ ³ È ¸ » ¸ µ ¯ » ¯ ¿ º ¾ º ³ ¸ É
Ã
² ³ ¼ ²
² ³ ¯ ¿ µ ² ³ ¸ µ ¯ ¿ ² » Ç ² ¿ » ¯ ³ ¸ É ² » - % ' » F Ì Ç ² ¿ ¯ ² É ¾ ¿ ¸ ³
   

        

            
       # %  

          

     #  +
       

             /       
              

          2      4


          7   %      

%     < 
=        @                B      C   +
   %       %        =         
         I       %    %  %       
 

%      %        M   @   4
N              7   @     @       +
   <      B %          7      S  


%     C 

         %     W            %  +
        Z        7 =   \ %  %         2 +
             

              /  
         

                2   4  
 W 

%         %                  M  
%          2    % %     @           7
          

    # C 

  %    
15,000
         @             @  

     +
  %        b             @      4
b   

 =  \         2              
Z          %             #   C      M    4
N    M <  %    %     /        2      
 @    

    

       %    S      M  
 

%       %      @  W    S 

# e

 4   
                       @   

     +

                 2    S  I    2  +

   

 =           

           4
N  % <          2    S   <  /     %   +
                 /     %  @      M    
   2         

    

 

#       +
@  

         S   S      M     

%  
   %      = %      2    @  W    S 

# e


%     /        %        /     /        
                     = B    

%  
   %     

# e

4
        S          #       %   
h
  +
2         
h
  4  
h
             +
W              %          7



  7   +
  7        e <   /               W    +
 <      S   %    %        4       
    %   
h
 7     /            %  +
   <    %          I    7   S       \  
  W          

    

          +
      
h
 /    W         %     <  4
     %     7      %    <  /       N   e
 "  

   

 %     2 %    %   %       +
2       Z                  \  4 b 2      +

    7          %  @     7  e       



h
     %  '   m  )     +  4 ,  S    
     2     W     N
  e         @     7
  %  @         <  S C      7   S      7   +
    @     7 =  @            

     <  4
-     7 =

#  7   2      N   e     
   

    %   C     %                   +
@  W   =    \             %              
   \    4 ,  \ 7       /      %         +
     \         %         0           
2       ) 4 1   N   e 4
b       \       #  S   M        S    +
 

     3  
h
   <  ) %  %        @   2 
     %  <      %  @  

  /         I +
          2             =   #  %       
 

           <  %      2        4 N 
h
   <       M         %      2    S  +
       %    I    <            N   e  
  0       ) 4 1 4 -         %           %  +
%      %     

%  

     <         %   
h
  @   N   e 4       

         =     
               @  W /   %  #    

     
%      2   

     @  W C     4
8 q :
r s < t u v s r w u r
x
y z r s y r z
N                   #           
 

 =  \          

%     C 

 %   
%  %         2          @     

+
%        2     W   4 N 

              


%                   2      %       
                 %      

    
= > @ @   C D E  %        @        S        
%                      %   W 

%  7  +
   1   4
h
 

@   S 7         

     
%  %       %    %               2 
 I
h
 %   \



  7 =   \ 7  %      S     +
 M      

%      %     

# e

4
b   

 =  \         2       Z       
          %             #   C      M    4
N    M <  %    %   7 

=     

     7
  /        2      @    

      

  +
    %    S      M    

%       %     
@  W

# e

    S  4                  +
        

    

             
   2    S  I    2 

   

 =            +

           4
276 Redes y Comunicación
    
   
   
     




  
  



   
  


 ! " 
 "  '

   ) "

$ 
  "  

   
 0   


   '

 " 2 

  

 




 "    "  
  "  
 

'
3 " 4  $ 6 


 "     ) 
0
   " 4  
  A   2


 2 ) "    "

 C D 
 
   
 

 
 2
 


 2   

)
  "  2
 "  " !
 H J  " 
  "  2
 " L )


  ) H


 6 
!   "


 2 

 

3 "   " 

   
 ! " 
 H J  " 
 


2    "
 
)
  "  2
'
 "  " !
 6 

  "

C R


 2


" 
 6 
)  
 2 ) "    "

 2 
2
  "



V  
  ) )

   

6  "  " 

 2
 J W 
 C &

   H


     !
Y
" 
  " W   
 )
 
6  "  " 
 
     2 ) "    " 4  

2 

  " ) " Y  
) 
 
2 



2      " A '
     
 0   


   
 
 
  


 
 " '


  "
  
 )

6 

0
    )   2 ) "    " 4  C
'

   2   
 )    2 ) "    "

 2 


 '
2
 " W    
6  "  " 
 6 
!   J    )
)   A

)
 "


2
C '

0


2 )
   
 ! " 
 
c  
 


 " L "  V 2 
L  L )

 


V  2
 "  "

      '

)   
   
)  J  C )  J  2 


 W A     

     
)  
 
2    
 ) " Y     
  


  '

 "

"
 
 




2 "   

A   "    C D 
 '

  

)  "  


 2 



 W A     
 "  V '

"  


 
  " A    
  
 0   


   

 
!
    


  
 

    

 "   '

 2    "   )  

    





 
C * L ! " 


 '

 )  

 W A     " 4  
2 


 


  "  

H 
 
 

)  
L 
   A  "   
   "   2
 h   

  

"  V    H     " 4   " A  " W    " !  
 "


2


)
 
   
 
)  "  


 C
+ 
0


2 )


H  i  
, . 0 0 2 4 6 8 9 4 6 
"

'
2 )

  
) 
 
2 


 R

" R "   3 "  '
   )


 !
 $ = > ? C D )
L 0
 " !


 

H  i  


 "    " L  "  )
 2 


  )
   
 


 )

 ) "
 

  
)
  " !
 

)

 
 
)  )   '

 

 3 "

" Y   
 "
  

h   "   

  "

"
 '

 



2

0


2 )
)  2 
    " ! "    C
) 


V  
2


"  "    
 2
 " W    " 4  
  '
) )    
)
 
6  "  " 
 
)   2 ) "    " 4   )



2 
2
  "
    

  

3 
)
 
2    "   
'


    )  
A   "     )  
)
    "   H  ) )
  
 

L " h  2    2 
2
  "
   A      J   
@


C
D H
  " ! 


 
 



   

  " ) " Y  
) 


 '

  
 0   
  


   
  

6  "


  

  ) 
 


   
 C )  J 
 2
 " L )
"

'
2 )

     ) A  



   " 


     i  
 k


H  i  
2    2 
!
 "    

 
  
 " Y  

 )
 
   
 6 

2
 


    
 ! " '

   
C D  


      
   " ! "  ) 2 
 

6 


  
 
   
 2 

 



2    "  
2

 " !
 


 2      " ) " Y  
)  "  


 
  
H




V 
W  "
 
C
R  
)
    "   H  ) )
  

L " h  
2 

  '


      " ) " Y   

) 
 
2 



 2
 6 

)
 "  


 
2 



 W A       
)  

  " 4 

H  ) )
 C R  

 W A     " 4  
  " A    V 
   '

  )
  " !
 


 
  ) H


 6 



  " A 
 "  A m  


2

 
6 
    H  ) )  

 "  A m 

C +   !
Y

V  
 


      '

   " ! "  ) 2
 6 
)
   
   J  " 
 

 "   

 

  "
   
       " 

 
2 ) "   

2   
! "    2 h   "   
)
   
 " 2

0


2 )

    

 W A     "

  
      
B ) c &  $ C
D 

L " h   )
 H  ) )

 )
  "  


  
"  
 '


3 " 4  6 


    )
 

 
)  )   
 
'
6  "

 ) 
3 "  
  "  
      ) 
    " !   2  '
 

  

 )  

  " ! "    
)  "  


  
)
 

 h   "     
      6 

    2  
 

   
         ) 
    " !   C
R  @


 

L " h  2 


0
   
 " A  " W   '
 " ! 


 
    

) 
 
2 



C

"    
   
)    2 ) "    "

 
  



"   

 '
0   


  V
0
     

L 
 

 "   "  


 2
 " L )

 2
 " W    )
 
6  "  " 
 2    "   )  


   

   !   "   " 4   )
)   A

)  "


2
C
)  J 
 2
 " L )
"

2 )

     ) A   
    
A " 


  
) 
 

"  " 4  6 
 
2 


   

   2
 "  " 4      2     
   

    !
Y
6 



 W A   
)  "  


 C D   
    
A "  



L "     
   2 )   " W   
  "  V

" 
6 

  " A 

   
  )


 
A m     

 "   '

  2
  V 2 
2
  "
   )   A      J   
@


      2 ) "    " 4  " 2

0


2 )
  "


2


 '
2 
   ) "

"   
2       m





V 3 "




2
 "  "

 
    
 
 $ C
'

   2   
  "  ) A    
)    2 ) "    "
'

 6 
H    "
  
  ) A  



3 

) 



    2 
! "     )    2 ) "    "

 6 
H    "
'
  
 )


 
    
 

!
 V   H
     
2

 

3 





    C +   !
Y

V   
 '
 "
   

6 
   

2 
    " ) " Y   )
 
'
   
 
) "  "   


)  "


2
 
   



     
   " ! "  )  2
 6 
)


 

  " A   
   
 0   
 "  0   


   
 C D 
 


  " 

 

   "
   "
 
A   




'
2    "  " 4  

   

  
)
  " !
 


 2  '
 

 3 "

" Y   )   2 
    "

 
)  "  


 C
XVI Jornadas de Paralelismo, JP '2005 277


  

  
  

            

    ! "
#    &   
 ) 

+
   #
!       !  .
 

   "

 !
 



 !
    
         
    7  "

    !  

 ! 
 !   <   !



7 


 @
+
 !


   
      


      #  ! #     
  ! 7   "

   #  A ! C 
   #  !
   E 
 

 !
  !  !
 
  
 @ I ! #
! #  

   M      # # 
!  
   
"
  

    

 # 
!       !
P     

+

 "
<       <          
   #       !  &




E   E     )     #
  )


  C !     
  
  E 
 #


  #

 !   #

      


 @
    
!    ! &  ! # 
! 

  !





  # M

 !
  


 !
    M  #  !  #     
   
!    
 !   



   
 7
<   #
!


      !  W #  "
#  A !   ! E

 #  @   #    

    #


 !      
     
   
                           "

!        



   
 7
Z  !  . @
+

 
   !
      

 ]
      
                
 

 
     !  W #  
 @
! ^ # $ %
_ ` ' b
%
c d e c f g
%
e f
%
h c f ) ` _ j +
,     P  

E  )

E  

       
E !



 ! 

#
! #   ! #           !    
           <   

"
   #    

   !
 #  A !     


      
  !
Z  !  .  !       7  
     l !
  ! 
@ -   7  n 
   
E ! 7   ! 
 
)     
    !    

   "
        #

 #




  ] 

 
l / 1   4
o 
  8  <  
&   #  ! 


   Z  !  .  !

   
 

      7  
   @ -   
  
E !    

   "
   <       !  


  
  !  
# 
 ! Z  !  .
)   
&
p   
  ! " 
  #  #



:   " o 
  ;

< -
+

&
p      @ @ - !
  
   !
 

      
       
      #
! #  

 
+
<  !   B   !  
  Z  !  .     #   #  
   @ I    

    
 
 !
    7  
   # A


 
E 

  

 !
 
 
   !  W #  
   Z  !  .  #
  

 !
     

<  
    
 !   

  

 !
   !
 
 
        "
  C  
   

   !
  !   
   
   
  ! C  @
I     !  W #  
  
       Z  !  .     #


"

!  !
 <       # # 
!          !

     !
 ]  # 
     !    
#    
 @ D  # M
#



!  ! "

   #
!      


 !      


    B   !   F
<     7     !  
 


   
     #   
 
"
#    
  !
    
     <    
E !   
     
 ]  # 
    @ 

 !

        #   
!   <  

"
H
I u J u K v w x y v z u J x L { v | u M { u | u x } x w { N | ~ u O N x w x
y v  x v } ~ P v | u x w { Q z x L {  v | u x L } u w S x  L x } w | x } v w x  ~ x
T U V

      !  W #  

 
         !    E     #
 "

 !
     !  

  !




       


 @ I  

 

<        !  W #  
   #
!              
 !       !


 
   


 
   
 7


  "


     #



  Z  !  . @
Z     
!                !  W #  
  

 .  "

 n      
  #
 7         
#    
 

  ! "

    

 ! 

 n   
 


        
     
    #  # 
!    )    7  n       n    !     


]  

    
#    
  !
    
     @ -  

E  
       
     


  
  !  <        

"
     A !   <  

          #  # 
!      
E !
 ]  # 
 ! 
 

 
E !  

 !
 @
      #  ! n   

 ] 
 7
  !
  
     
   !  W #  
 #     W #    
      ! 
    
 X
  
     Y [ \  ^    ` 
!  <       <   M  #  !
 !  
 

    
#    
 @ 
 #
!
     
 "
    a b d  ^    ` 
!
     <       !

 # M

 


      ! 
 7  !

         


  
 !
    …       @
Z     

     ! #  ]  !  !      W        #  "
# 
!      

# A

 

) 
#   !
   # #  A ! #
!
       
@ 
 #
!
          !         !
 W "
#  ! #
!
      !
   #
 7    
!   
  7  !


<         ! 
!    A    !    
  ] 

 
  "

A !

 #   
 <   


        
@ I       

  

    !

  #   !
  
  7  !

 <   



   !             7   
 A    !    

  ! 
 

 )
         #

            
7
#     

   
 
 7
 M    p      @  @    #
  i l ,   
# @  @
-  

E          
  

         <        "



    # # 
!    &


  !

   
      7  ! "

 @ -   
  
E !   
     #
!   
  # # 
!  




     <   


 Z  !  .    

   
    
 
 


   
  l m   p q m s t  m p  v  @ I 
    "
#    !  !
 


  !

  &    !
      #

   

            
@
- #
!
 !   #  A !       #     !     !
  
 "
        # 
!  
 #
!   &  ! # 
! 

  !

      "
!  W #  
  
       Z  !  . @
w x z x | } } ~  €  ‚ ƒ } „ … } „  ~ 
Z  !  . 
   n   !

 #  !  


    
 !   
  "
            !  W #     
       @ 
   &  # "

     #     !  4 ˆ !  7         
     <    
    
 !          !




X 
  ˆ ˆ   

 

   
      
 


    ) 
 4 ˆ   
 !
  

 !
   
 
  
     
            
@
278 Redes y Comunicación
                            
        
(
            ,
(
  
(
 
 .                    ,     
  
   .                           7 
   8
(
,           ,
(
     <  8     
      =              ?     A        
7  B               8     F
G
 <   H
  
(
              J        
                       A
(
    H 
         
(
     A            
         H
.....
Nivel 1 Nivel 2 Nivel 140
Nivel 100 .....
Tarea 1
Tarea u
Tarea 2
Tarea 1
Tarea v
Tarea 2
Tarea 1
Tarea w
Tarea 2
Tarea 1
Tarea x
Tarea 2
P R  S T V
W 
X T T V  [ \ ^ T R ` T R [ V [ a
b             =       B           <
          8 f  .  g           
        
(
            H   
(
 
               
(
   g     
   
(
  #  & '    f       B     J A    
 
(
      
(
                 <
      8         
(
      
(
  
          H                      j <
    ( * +
. / ( * 1 
        B    H   
3  B   5 
(
       
(
      f 
            J       6          <
            ?         f         
     8      8  8 m 8 n
≥ 0
H
7 8 : 8 = ? @ A B C D D E D F G F H J K
      =               g     A  
( +
M +  +                8    
(
  <
           ? 
(
   A                <
=          H O       
(
  8        <
  ( +
M +  +        =          J       f 
        H     f             8    <
(
   S   U  8 
(
                
7       
(
  
   
(
    H   ,   B 
(
  
   f      n       8 W Y Z  (  . 8 
(
  <
             7       
(
      
(
 <
   H    3  B   \ 
(
           .    A 
       g     A               H
....
CPU 1
Active
Expired
CPU 2
Active
Expired
CPU n
Active
Expired
P R  S T V
q 
r
s
\ t ^ u ` [ \ T S v ] S \ S \ w \ v S v w R w x \ t V y ` v
v ^ T ` y \ w V [ ` T \ w a z ^ u ` { V  S v V T S v ] S \ S \ ^ ` T ^ T ` y \ |
w V [ ` T a
b       A     
(
       B         
             B  
(
 8 _ ` `
(
  8    <
               
(
       7   
 
(
     6   H
b ,    
(
  8             7       <
(
      
(
    8       =            
  f      8            B      
(
    f
  B         f n    H d         f
      7                     =    
    
(
.                  f      
f n    H         
(
            =   <
  A  f ?                 \ H f 8       
     j     
(
,  
(
             =     H
7 8 7 8 = H F @ ? C D j @ A K H k F A F H J K
d     J         =      b    n    j  
  f              f       
(
.     
n    8       7   
(
             
     =     A  H                    
6    \ H f 8   
(
    
(
   .    
         j           
(
     
(

     n         
(
  g     n        
   
(
                      <
          7  . j   
(
        
(
    8
                   =            . 
             B      
(
    H  7  
    6    \ H f 8          B         8
XVI Jornadas de Paralelismo, JP '2005 279


  


   
    

  
   
     
      !
   #  ! % '      + !  /   
   

              
      ! % '      !     5
       

     9 %          =
 


 

  

   
 
   
   
  
    
A

  
       /    '   

      ! % '        

5
   D        9
 G
  +            H     I 
     /   I       K        
 G       



 
 G          9
%
             +       

      5

 G     =
     K  + 

     
G
   +    5
Q   
     /         
 
 
      
  
 G     =

•
 

  
             !
   #  !      5
                 /     D      9
•
  
           
 
           


    I   


     

     9
[

  I  K            

  #  ! 


5
        ! % '      +      
        
  #    #        !
   #   
       /  

 I   


   9
•
  
        !
   #   #   H  + 
 
 
 
    

  
      ! !  #    #  
 


K                
 G     =
9
 _ 
`

a b

c d `

e f  g d ` f e b  g f j a
 !
e b
k            /    #        D    
  

     K       #        



  

  I 

l  
    

 
     Q  
Q   
  K 
 
  

           !         #       D     5
Q 

l ' 

 +      /              
 /     5
/     

        
             ! m  

  

          

l ' 

              5
  
        
  9 %
          +      /  
          
   
  '     #    
[
" /  
 

    

A
     #     n H    9 $        
 I 
             Q   
        
 9 k          
 /     D     

  n  5
 
 
[
"   

Q 
   


 
      5
          /   #   H 
      Q    
  

  9      
  +  
    
       5
  


             =
      /     
              Q       

  +     5
         #             
  
[
" 


A
     #     n H    
        

   
  

l ' 

    =

     
      5

   

        Q           
 
        
  
[
" 9
( 9 *                
 /     D     



  #     


 
      
 
  

    /     
  

          

l 5
' 

 9      
  +           -    
  
 G                       n  


/     n   
          
      
  n  5
 
      

 
  9  

  
   
    
   +
 
        


 
  
  5
#              Q 

l ' 

 +  '    
 


  

l  
        

        5
    
           
    #  K /   
 Q   Q   
  K 
      

          
     /              
 /     

  
  /      9
. 9 *                
 /     

  5
/              

l ' 


     
   5
     
   



 / 
[
     
  + 
        n   
          
   

  n  5
 
    /      9      
  + 
  
 5
G              +     K     
 G     
       Q A
   /            +  5
 l     K        K             

n  



l  
     9
%
          +    
                
  
n           
            
 Q    

5
  


   
    H       
 5    
 
  
 


A      
 #                
     
  
 G        k 
 ' 9 3   I 

  


   l

      
 

  


          D      5

   #          G
       u
G
 5 
 7  9 : 9
%
 
     +          Q     l      
 
    
  
#    Q    =
/    I            

   
  '     u
G
 5 
              5

  / 
[

             7  < : 9       
  
  l /  

   G         

  


  
Q    =
        !             /   

   5


       


    >  
  + !   G
     

 5
 


        l                     
       9 %         Q      
 
     
            
  '   
  
          +
I    !       /    
n  



         =

 
     9
k          
  
[
"   l
    G    

#         Q   H  +    
  
       5
/        / 
[
9 %
          +  I   
  
280 Redes y Comunicación


  


 
      
            
   
 "
   #  

•
        &  &   &       )       
  & 
   
*

          ,     ,       
   .  
     
3  &  &           6 
  "
   :    
  & 


< =


     
3  &  ?  
 . 


   &           D  ,       .   
 
  
    #         6 &   &  6 # &   )  . 
& 


  &  ?
•
        &  &   &     
         
,       
       .  
     
3  &  & 
         6 
             ,        "

  & 


< =


 ?    . 


   &        "
   D     #       6 &   R  ) ?  )  U  6   
,   V     


 &  V  



  &         "

        
    #       <
  )    
 


        
    #    
*
   ,    
    
3     ^   
               

 
    #  ?
*
 


)     V          & a  "
             
     
    #    
*
  ,         ^   &                 "
        
#  &   
  &         
    # 
  ?
•
  
d   
  d
          ,       "
  
        .  
     
3  &  &    "
          
  & 


< =


 V       ,   "
        
   
&  & &    &    


  "

      V :   # V   ,     
 &         "
&  & &   D


 
 &     )       
   "

 
 & 



  ?    . 


   &        D 
   #      ,     ,     ,      


 
  D 
 


U               ?
•
" i         " j
          ,    D     "
 <   .   
 &       &        

   
<
   &  )  .  &    
 


)        <    D "
&  


 
     ^   &      &          
)  .  ?    . 


   &        D     #    
       &   &  i          &       &  & ?
 & 


<  &        

 &      ^    D  V  
       
 3         

 &    
   & 
 &


 D      & 
 


     
*
& &  &    
  
    ,  
       &   &

    ?   "
&        ,  
  &  
*
& :   & 
 )   D  
       &  



  V  
     

         <  
 6   &      &  &  &     &                "
  


<   =   
  ,      .   
      
*
& ?
d 
     <



             <     
 &     

  6     & 



  ,        
  & a    
 
  ,  
  V :  
*
&  
 &

 <    


 
   
   )  


 
         ,  
  &    
*
&     "
6 


 
  
 )    &   ?
m         6  
 .  &     
 
      "
   
   ,        )       
3          
&  &   &   :  
  &  


< =


     
*
&   &  "
   &  



 
 &    
*
&  ,          
 "
&     
   


 
 V   &     &  



 
 & 
 
  
*
&   =   &        ,  
   



 
&   .     D  V   
  ,         

 &     "

   &   &


 D     .   
   &  6  3 ,    
   6 
*
&     
         &  ?  ) 6 


 
 V
  
*
&  =   &       ,  
  V      <    )  
    
3    
  & 


< =


              
,      .   
    U  V       i   i 


  
  "

   ,    
    a  
  <  
  
*
&  ?
(   


 
 V i  : ,  


       ,       "


  3   <  &                   
    
 "


 


          &   V         


 
     "

      o 

 
       #       , 
 
  
&         &      


 V     . 


   V j :    "
 i    &   * , - /  1  
" "    * , , V , 4 / V :  D



  V
 


   &   &      
    



  )    "
&        
      
 ,       
     <


) "

 


< 


  
 
                   & 
q 
   
?
6 r 8
s t u
9
v w x s t z w
d   

  )  .  V   i      3  &     )   6 

  &    D  &        
 & 
*
  6 &   & 
   V


 
   &   D


      &            <


)

&        6 &       q 
   
            "
      &  & &     6   V  & 


<  &      
3  




  &        
 :    &  
6 &  & )  .     "
 


< =


       .  
 &            V  
     &  & &    )   &


             6 &    
a #     V :   
 
 V         &    &     
 6    D      D


  ?
q    


 
 V   i       
 &        ^   &  
& 
     ,  


  


 
 m   = 4 ? : V i     & 
       i     U    


    


 &      &  "
&   V          :  &      &  &   :         & 
 .     D  &            &     ? 


)    
  
 "
   &  & 
    6        



 &  &       
&      ^    D  ?
XVI Jornadas de Paralelismo, JP '2005 281


 
 
    
    
  ! 
"   " !   &

"

  
    
 

*
   ,
,       ,  


  0  ! 2 ,       4  & 6   
*
"  
*
  &
  
,   ,  " &       6    6  & !
 = >    4  & 6  "   A
, "
   ,     B !  ! 
 B   &
*
   " 
  ,
A
, E    ,   & 
"  H
    

  &  E  ,
H

  
    

"


B   & E    
 &
 
  

  & 
4       " !   &     N    
   H "
A

  

*
  &    
    
 ! 
*
 ,
 
*
   ,   A
&     

*
 E     !  6      6      6  & !
A
   = >      
  , !
    
"   " !   &
"   A
*
&  Z ! &  
       6        ! 

*

  

*
! ,  
*
Z     &
  
*
  & 
    B !  B

 A
& 
   & 
*
"       " !   &
H "    ! , & 6 


4  ,
 B

*
Z 2
*

 "


\ !   

"  ,
,    
\ !    \ !     ! 
,   &
,
 & 
     , !    
H ]  !  & 
*
"       " !   &

*
Z 2
*

 "   ,  A

 "  & ,          ,    &     N  &     & =
` a  a b a c d e

f

     & 0  6             !  #  % & '   ) +
,
 . %  1 3 1  )  %   7  6         9 : : < =
 9  ?    @
  A  1   C ) E  1   G ) H    J
   K M N M P M Q R T A
,
. H  1     X Y Y Z \
] ] ^ _ `
X a Y c d e f g
` _ h
Y i d c g a f
_ k ] l m
e n o 
9 : : < =
 p  0 !  @ = 
      ?  t   H v 
  x  
i z     
 |
,
 E  . H  %  ~ T E   )   H 
 % % G  R  C )   ~  . H  )  . )     X Y Y Z \
] ]
i i i a
f
_ k
Z n Y g c a
_
c
] k m
f c
_ ] k m    ] k    
a Z 
h
 ƒ          )  E
,
  #   T  %   . )  X Y Y Z \
] ]
i i i a
l m
e n o 
m
c Y n d
l `
g c  g c a
_
c
 <   H            ~  . H  #  C  X Y Y Z \
] ]
i i i a

g c e g
l
a
_
c
 ‰  R %  1 %  T  %
  . )  % '  & E G   X Y Y Z \
] ]
i i i a
f
`
a i
m `
f a g  n
]
f
_
e 
_
c
 Π v
   =   6  &  Ž
 ,    
&  A  1   C J
) E  1   G ) H            +
,
 . %  1 3 1  )  %  
‘     H  9 : : 9 =
 ’ 
j
!  Ž ,    H  & 
*
 N  , = 
,
% E   C  X Y Y Z \
] ]
i i i a
`
n e a f
_ k ] ` _ h
Y i d c g
] ` _ l
d c
m `
 “  Ž ,     k &   = 
  1 % • C K     X Y Y Z \
] ]
i i i a
k m
f c
_ ` _ h
Y a f
_ k ]
i
m
e 
_
i
` `
g c  g c
  

:  N  &     =  —  )   &   J  H   E 1   G   . H  % J
% G  X Y Y Z \
] ]
i i i a
m
e Y g
l
a f
_ k


 N  &     =  —  )  $  )  J R %     . H  % % G 
X Y Y Z \
] ]
i i i a
m
e Y g
l
a f
_ k

9  @ Ž v N  , =  ~ $ ! $  )  J R %     . H  % % G 
X Y Y Z \
] ] k
n
l
Y
m
f
_
c g a d
k
 a f
_ k

p  i
j
  6 ,   ( 0  ! 2  X Y Y Z \
] ]
i i i a X Z a
f
_ k ] l m
e n o

ƒ  N  Ž 0  ! 2  X Y Y Z \
] ]
i i i a
m * k
a f
_ k ] l m
e n o

<    A i
& N  , =  X Y Y Z \
] ]
i i i a c g  X d Y a f
_ k

‰  › @
j
 k & n
    =  X Y Y Z \
] ]
i i i a
 d
` _ h
Y i d c g a f
_ k

Œ  œ      
j
 k & n
    !  
&    X Y Y Z \
] ]
i i i a
h ` h
a
_
c

’  N    
  œ 
  @    ,
&    —  +   ž E  1
~  . H  )  . )   
,
&  .  + . E )  %   ‘ , & !    9 : : : =

“   
 ,  ,  ? = @  k
   A  E C   .  E '  ) % J
1 % % G , E & E  E G E  E  )  . E  . E  1 E 1 1  C   #  J
.  %   C  |   1  C —  +   ž E  1  œ    v  , &  

N
j
 7 ¡ ’ ƒ ’ ƒ 9 Œ p 9 : 9  9 : : ƒ =
282 Redes y Comunicación
Evaluación de Prestaciones,
Modelado y Simulación
                   !  # % ! #  ' ) + %     . /  0 % 2     0     # #  
5     #   6 8 9    < 2      8 @      ' 6  # D 2 8 G   I
J K L N P R N S K U R V W K X U Z K U [ K P \ N ^ _ K ` U V a V Z \ N W K c V S L d R N W V P K e
f U [ g K P e [ W N W W K j d P ` [ N
k N ` d a R N W W K X U m V P S o R [ ` N
r s s t u
j d P ` [ N
v
m w x g [ a a N y S K N ` N ` [ V y w S Z N P ` [ N z { W [ R K ` x d S x K e
| ~  €  ‚ ƒ €
„ … † ‡ ˆ ‰ Š ‹ Š Œ  Ž Œ Š  Œ ‰ Œ … † ‹ … Œ ‘ ‡ ‹ ’ ‰ † ˆ “ Œ Œ “ ‹ • –
’ ‹ † ˆ — … — ˜ † ‡ Œ š Œ š —  › ‰ ’  ‰ › ‰ † Œ š ˆ … ‹ Ÿ ‡ ˆ Š –
š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —    ¡ ¢ £ ¤ ‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ Ÿ — š Š — ‰ Œ ¥
— ˜ ¦ § Ÿ —  Œ ‰ ¨ © ‡ Œ Ÿ ‡ ‹  ‹ Ÿ † Œ  ˆ ª ‹ † ˆ — … ˆ ‰ Š Œ  ˜ —  š Œ ¥
š ‹ ­ ˆ … ® ’ ‰ Œ — ˜ ‹ … Œ Ž ‰ ˆ š ’ • ‹ † —  † ‡ ‹ † Ž Œ ‡ ‹ “ Œ
Ÿ ‹ • • Œ ¥ ¯ ¡ ¢ £ ° „ ¢ ‹ … ¥ Œ ‘ † Œ … ¥ ‰ † ‡ Œ ³ ˆ Ÿ Œ ° ˆ š –
’ • ‹ † —  ˜ —  „ ´ £ ¢ ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —  ‰   ³ ° „ ¢ ¤ Ž ˆ † ‡
† ‡ Œ ˜ ’ … Ÿ † ˆ — … ‹ • ˆ † ›  Œ ¶ ’ ˆ  Œ ¥ † — š — ¥ Œ • ‹ Ÿ — … † Œ š –
Š —  ‹  › ¡ ¢ £ ˆ … ®  Œ ‹ † ¥ Œ † ‹ ˆ • ¨
© —  Œ † † Œ  ’ … ¥ Œ  ‰ † ‹ … ¥ † ‡ Œ  Œ ‡ ‹ “ ˆ —  — ˜ † ‡ Œ
š Œ š —  › ‰ ’  ‰ › ‰ † Œ š · Ž Œ Š  — Š — ‰ Œ ‹ † ‹ ‘ — … — š ›
— ˜ † ‡ Œ ´ ¦ Ÿ ‹ Ÿ ‡ Œ š ˆ ‰ ‰ Œ ‰ ˜ — ’ … ¥ ˆ … ¡ ¢ £ ‰ Ž ‡ ˆ Ÿ ‡
‰ ’  ‰ Œ ¶ ’ Œ … † • › Ž Œ ’ ‰ Œ † — ¥ Œ † Œ  š ˆ … Œ Ž ‡ Œ  Œ † ‡ Œ
‡ — † ‰ Š — † ‰ — ˜ † ‡ Œ š Œ š —  › ‡ ˆ Œ  ‹  Ÿ ‡ › ‹  Œ ‹ … ¥ ·
† ‡ ’ ‰ · Ž ‡ Œ  Œ Ÿ — š Š ’ † Œ  ‹  Ÿ ‡ ˆ † Œ Ÿ † ‰ ‡ ‹ “ Œ † — š ‹ ­ Œ
‰ Š Œ Ÿ ˆ ‹ • Œ š Š ‡ ‹ ‰ ˆ ‰ † — ˆ š Š  — “ Œ † ‡ Œ Š Œ  ˜ —  š ‹ … Ÿ Œ
— ˜ ˜ ’ † ’  Œ ¥ Œ … ‰ Œ ‰ ˆ … ® • Œ – Ÿ ‡ ˆ Š š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —  ‰ ·
Ž ‡ ˆ Ÿ ‡ Ž ˆ • • ˆ … † Œ ®  ‹ † Œ ¦ § —  š —  Œ Š  — Ÿ Œ ‰ ‰ — 
Ÿ —  Œ ‰ ¨
¸ º »
€  ¼ ½ ¾ ƒ € ¿ ¼
»
À
‰ ˆ … † Œ ®  ‹ † ˆ — … ‰ Ÿ ‹ • Œ ‰ ®  — Ž ‰ · † ‡ Œ … ’ š  Œ  — ˜
†  ‹ … ‰ ˆ ‰ † —  ‰ ‹ “ ‹ ˆ • ‹  • Œ — … ‹ ¥ ˆ Œ ˆ ‰ ˆ … Ÿ  Œ ‹ ‰ ˆ … ® • ›
 Œ Ÿ — š ˆ … ® • ‹  ® Œ  · ‹ … ¥  ˆ • • ˆ — … †  ‹ … ‰ ˆ ‰ † —  Ÿ ‡ ˆ Š ‰
Ž ˆ • • ‰ — — …  Œ Š — ‰ ‰ ˆ  • Œ ¨ © ‡ Œ  — • Œ — ˜ Ÿ — š Š ’ † Œ 
¥ Œ ‰ ˆ ® … Œ  ‰ ˆ ‰ † — †  ‹ … ‰ • ‹ † Œ ‹ • • † ‡ ˆ ‰  ‹ Ž Š — † Œ … –
† ˆ ‹ • ˆ … † — ˆ … Ÿ  Œ ‹ ‰ Œ ¥ Ÿ — š Š ’ † ‹ † ˆ — … ‹ • Š — Ž Œ  ¨ Ä — 
† ‡ ˆ ‰ · Œ Å Ÿ ˆ Œ … † ‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ ‰ š ’ ‰ †  Œ —  Ÿ ‡ Œ ‰ –
†  ‹ † Œ ¥ ¨ Æ … Œ — ˜ † ‡ Œ ‹ Š Š  — ‹ Ÿ ‡ Œ ‰  Œ Ÿ Œ … † • › Š  — –
Š — ‰ Œ ¥ ˆ … † ‡ Œ • ˆ † Œ  ‹ † ’  Œ † — š ‹ ­ Œ Œ Å Ÿ ˆ Œ … † ’ ‰ Œ
— ˜ † ‡ ˆ ‰ ‡ ’ ® Œ … ’ š  Œ  — ˜ †  ‹ … ‰ ˆ ‰ † —  ‰ ‹  Œ ‰ ˆ … ® • Œ
Ÿ ‡ ˆ Š – š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —  ‰ Ç ¦ · È É ¨
À
¡ ¢ £ ˆ … † Œ ®  ‹ † Œ ‰
‰ Œ “ Œ  ‹ • Š  — Ÿ Œ ‰ ‰ —  Ÿ —  Œ ‰ — … † — ‹ Ÿ ‡ ˆ Š · ‹ ‰ Ž Œ • • ‹ ‰
— † ‡ Œ   Œ ‰ — ’  Ÿ Œ ‰ ‰ ’ Ÿ ‡ ‹ ‰ † ‡ Œ Ÿ ‹ Ÿ ‡ Œ ‡ ˆ Œ  ‹  Ÿ ‡ ›
‹ … ¥ † ‡ Œ ˆ … † Œ  Ÿ — … … Œ Ÿ † ˆ — … … Œ † Ž —  ­ ¨
À
‰ ‹  Œ ‰ ’ • †
— ˜ † ‡ ˆ ‰ · † ‡ Œ †  ‹ ¥ ˆ † ˆ — … ‹ • ‹ ¥ “ ‹ … † ‹ ® Œ ‰ — ˜ Š ‹  ‹ • • Œ •
‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ ‰ ‹  Œ ­ Œ Š † ·  ’ † ‰ — š Œ — ˜ † ‡ Œ ˆ  ¥  ‹ Ž –
 ‹ Ÿ ­ ‰ · ‰ ’ Ÿ ‡ ‹ ‰ Ž ˆ  Œ ¥ Œ • ‹ › ‰ —  … Œ † Ž —  ­ • ‹ † Œ … Ÿ ˆ Œ ‰ ·
‹  Œ š ˆ … ˆ š ˆ ª Œ ¥ ¨
„ † ˆ ‰ Ÿ • Œ ‹  † ‡ ‹ † Ÿ ‡ ˆ Š – š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —  ‰ ‹  Œ
‹ • ‰ — — … Œ — ˜ † ‡ Œ š — ‰ † Š  — š ˆ ‰ ˆ … ® † Œ … ¥ Œ … Ÿ ˆ Œ ‰
ˆ … † ‡ Œ š ‹  ­ Œ † — ˜ š ˆ Ÿ  — Š  — Ÿ Œ ‰ ‰ —  ‰ · ‹ ‰ ¥ Œ š — … –
‰ †  ‹ † Œ ‰ † ‡ ‹ † ‰ — š Œ  Œ Ÿ Œ … † Ÿ — š š Œ  Ÿ ˆ ‹ •  Œ • Œ ‹ ‰ Œ ‰
‹  Œ ¡ ¢ £ ‰ Ç ¦ Ì · ¦ ¦ É ¨ Í — Ž Œ “ Œ  · … — Ž ‹ ¥ ‹ › ‰ † ‡ Œ
 Œ ‰ † —  ® ‹ … ˆ ª ‹ † ˆ — … — ˜ † ‡ Œ Ÿ — š Š — … Œ … † ‰ ˆ … † ‡ ˆ ‰
­ ˆ … ¥ — ˜ ‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ ˆ ‰ … — † Ÿ • Œ ‹  · ‹ … ¥ † ‡ Œ  Œ ˆ ‰
‰ † ˆ • • š ’ Ÿ ‡ Ž —  ­ † —  Œ ¥ — … Œ ˆ … —  ¥ Œ  † — ˆ š Š  — “ Œ
† ‡ Œ Š Œ  ˜ —  š ‹ … Ÿ Œ ‹ … ¥ š ‹ ‘ ˆ š ˆ ª Œ † ‡ Œ ’ † ˆ • ˆ ª ‹ † ˆ — …
— ˜ † ‡ Œ  Œ ‰ — ’  Ÿ Œ ‰ ˆ … ‹ ¡ ¢ £ ¨ Î Œ ‰ ˆ ¥ Œ ‰ · ‰ † ‹ † Œ – — ˜ –
† ‡ Œ – ‹  † ¡ ¢ £ ‰ ‹ … ¥  Œ Ÿ Œ … † Ÿ — š š Œ  Ÿ ˆ ‹ •  Œ • Œ ‹ ‰ Œ ‰
ˆ … † Œ ®  ‹ † Œ Ï · Ð —  ‹ † š — ‰ † Ñ Š  — Ÿ Œ ‰ ‰ —  Ÿ —  Œ ‰ — … † —
† ‡ Œ Ÿ ‡ ˆ Š ·  ’ † † ‡ Œ › ¥ — … — † ¥ Œ ‹ • Ž ˆ † ‡ ˜ ’ † ’  Œ
¥ Œ … ‰ Œ – ¡ ¢ £ ‰   —  ¯ – ¡ ¢ £ ‰ ¤ · ˆ … Ž ‡ ˆ Ÿ ‡ ¦ § Š  — –
Ÿ Œ ‰ ‰ —  Ÿ —  Œ ‰ —  š —  Œ ‹  Œ Œ ‘ Š Œ Ÿ † Œ ¥ † —  Œ ˆ … † Œ –
®  ‹ † Œ ¥ ¨ ¯ – ¡ ¢ £ ‰ ˆ š Š — ‰ Œ … Œ Ž  Œ ‰ †  ˆ Ÿ † ˆ — … ‰ † ‡ ‹ †
¥ — … — † ‹ Š Š Œ ‹  ˆ … Ÿ ’   Œ … † Ÿ ‡ ˆ Š – š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —  ‰
‹ … ¥ · † ‡ ’ ‰ · ˆ † ˆ ‰ … Œ Ÿ Œ ‰ ‰ ‹  › † — Œ “ ‹ • ’ ‹ † Œ † ‡ Œ Š  —  –
• Œ š ‰ — ˜ † ‡ ˆ ‰ ­ ˆ … ¥ — ˜ ‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ ¨
© ‡ ˆ ‰ Š ‹ Š Œ  Š  Œ ‰ Œ … † ‰ ‹ … Œ ‘ ‡ ‹ ’ ‰ † ˆ “ Œ Œ “ ‹ • ’ –
‹ † ˆ — … — ˜ † ‡ Œ š Œ š —  › ‰ ’  ‰ › ‰ † Œ š ˆ … ‹ Ÿ ‡ ˆ Š –
š ’ • † ˆ Š  — Ÿ Œ ‰ ‰ —    ¡ ¢ £ ¤ ‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ Ÿ — š Š — ‰ Œ ¥
— ˜ ¦ § Ÿ —  Œ ‰ ¨ © — † ‡ Œ  Œ ‰ † — ˜ — ’  ­ … — Ž • Œ ¥ ® Œ † ‡ ˆ ‰
ˆ ‰ † ‡ Œ Ô  ‰ † Ÿ ‡ ‹  ‹ Ÿ † Œ  ˆ ª ‹ † ˆ — … ˜ —  ‹ ¥ Œ … ‰ Œ – ¡ ¢ £
‹  Ÿ ‡ ˆ † Œ Ÿ † ’  Œ Ž ˆ † ‡ ‹ ¥ Œ † ‹ ˆ • Œ ¥ Œ ‘ Œ Ÿ ’ † ˆ — … š — ¥ Œ •
˜ —  Œ ‹ Ÿ ‡ Ÿ —  Œ ¨
À
‰ Ž Œ ‹  Œ ‰ Š Œ Ÿ ˆ ‹ • • › ˆ … † Œ  Œ ‰ † Œ ¥
ˆ … † ‡ Œ  Œ ‡ ‹ “ ˆ —  — ˜ † ‡ Œ š Œ š —  › ‡ ˆ Œ  ‹  Ÿ ‡ › · Ž Œ
Š  — Š — ‰ Œ ‹ † ‹ ‘ — … — š › — ˜ Ÿ ‹ Ÿ ‡ Œ š ˆ ‰ ‰ Œ ‰ ˜ —  † ‡ Œ
   
     
  
    "   
 %  ' (
 ' ) 

%   
  
    .
 1 3     5 '  6
' % 8  '   
        )     
<   '  
 6
 ( 8 
? ' <

 A  ' (  (   
   %  <   ' 6

  '  1 3 

  <    '       ' % <   
 %  A 6
  G  
' (  
)   %  <  '  )        
5
 6
  '  ' ( 
)
< < 6 A  ' )  N O P R N  
O  %  <  6
'  ( '  P  "  <   ' 
  '   W X Y Z      )

  
  < <
 \  " O P 1 P % ' 
<       
< 8 
 " )     '  . G    ? <
  % ?
 ' (  ' 
 _   6
 
     
  '  

 ' G

      <  6
       '  ?          
 _ %  <  ?   A
  `
   
1
a
.     
%     '    ?   '   ' (   

  

( ' < < ' )   G c
•
a

 ( '  %  
  <

  <    '  ' ( 

%
% '  8   ?  8 
% ' (   g 6  ' 
  ' ' 6
?  
  "     
  
)   <

5
  6
  G    < <
< ) '  A < '    1 3     '     
)   
%  k '   8 ' ( 
  '   < 8  ? <   

) '  A  _    "     ?

  
     < < 8 '

5
 
%  <   ' G   % %
 ) '  A < '    1
•
a


   ' 
<  5 '  ' % 8 ' ( 
 
   
%   
 ( '        " 1
•
a
  ' )   
%    ? ' <

 A ' ( 
 g 6  ' 
  ' ' 6 ?  
 \ 6  "   
   

?   1 q
  
 _ )


  
   %  k '  6
 8 ' (        '     ' '
 ? 8 
   

 '   ' < <

   
 '  '  
 
 )   

<  
        
_ )         
 ' '
%      

    8 ) '  A 1
3 

 ' ( 

   '  G    v
   ( ' < < ' )  1
O
  '  `   % %    v
 

< 
 ) '  A 1 O
 6
 '  w 
    ?
 ?  
x 8  ' %
 % <
%
   ' 
   
 ' ( 

)   %  <  '  1 a


   5 6
'  ' % 8 ' (      
%   
 ( '       "   
O
  '  y 1 P  O
  '  z )
  ' )  
  <

 6
( '  %   

  <    '  ' (   "  ' % ' 
 ? 8
 g  ' 
 1 {    < < 8 _ O
  '  g  '      '   %   
 '   <    '      '  <  
  ' %
(   
) '  A 1
| ~  €
 ‚

ƒ „ … † ‡
O ' %
) '  A    

  <  
 
 
(  < 
  ' (

 ' 

 
   '   ' ?      G   %  <   
  < 
   '      
 ' 
5 ' (  y 6 )  8 O "   X  y Z
     
 ' 
5 ' (   g 6  ' 
 " X g Z 1 3 


 
 ' %
' 
 

 ) '  A    
< 
   


 <   G )   

 ( '  %   
' ( 
%
% '  8
 
     8    "     
  
 1 q
 A %   
   a ' '  

 

  <  ' '   <  ' 
  


 %   ' ( )  

<  8  '  <   G
_    
  `
   
   (   
 "  X ` Z 1 3 
8  % <
%

   
 '  8 6 ?  
  ' 

 
 ' '  ' <    
` \ 6 %
   
  '  
  '  
) '  A _
  <     G
  "  ' % ' 
 ' ( Š  ' 
  '   ' 
 1
   ‹ Œ  Ž  X  w Z    8 

  <  `    
'  G    6
v   '     '  
 '    
 

  <  v   '  R   
  <  
 % _ 

 ( '  %   
' ( 
%
% '  8
 
     8 W ' (         
1 3 
8  ' ' 

%
      %    8   %    < < 8     G    `  <  
'
    ' 
  '  1 P     )  8 _ 
8 ' ?    ?
6

   <  v   '  ' ( 
 `    
_  A   G   '   6
 '   

%     ' (
    ' 
  '  

 8
% ' %
 1  ' )

 _ 
8  '  '  '    
 ' 

'    ? <
? ' <

 A  _       


 
' (

   
 ?   1
‘
   

  '   ) '  A _ 
8
  %  < 
  "  ' % ' 
 ' ( Š  ' 
 1 P  X  Š Z

   '    ' ' 
 
   <  ' 

 
  
    
)    
 ' 

 
 ' '  ' <   '  

' 
  
   
 6 ?          '   %
1 3 
8

  <  


  <  '  . G     '   )         ? <

  % ?
 ' (  ' 
  '   _    G   G (  ' % ` ' Š 1
 ' )

 _ 
 
G    '     <
   %
% '  8
  ?  8 
% < 
  
     %
   

   ( 6
(
   G  < 8 (  ' %  ' 
( '     ' )    8  _  ' 
 

  <   
 '  ' %    ? <
)   '    1
{    < < 8 _  ' %
' 
    '     
   


%
% '  8  
     8 ) 
  ' % ?     G    6
%  <   ' 
    G )   
  <   
%  <   
  6
  G _  <  '  G  % '  ' ( 
% ( '    '  

  '  ( '   
  6 <

< %
% '  8 
  <   ' 
X Š _  ` _  g Z 1
‘
% '  G 
% _ •    G  )  ‹ Œ  Ž 
X ` – Z
 ( '  %   ' % <
5  8    < 8    ' (     

 '   ' < <

 
  G 
 ? 8
5
    G  O P  '  6
 ' < <
 '   '   
  6 <

< %
% '  8 
  6
<   '  1 3 
8  
   
 '  8 6 ?  
 %
      %
' %        ' 

 
_    .     
%   
 ' % ' 
 ' ( %
% '  8 < 
  8   

<  8   6
   
 ) 
   
    G 
  
 '  8 1
— ™ š › œ  ž › Ÿ
 ƒ

‚   
€ 
ƒ
š › œ 
  ¡ ¢
£
€
 ‚ … † ¤  ¥

ƒ …
¦ ~  ž ›
\  " O P % ' 
<  
    
  
  ' )
  
{  G  
 1 P         
  
_ )
  
    6
286 Evaluación de Prestaciones, Modelado y Simulación
                            #   
&   #    * , .       #  0
1
2 2  #        #    
  7  .  2     9  . * <    #   #   ? #    2   @
            0 B    2 2              @
   2   E  .   .    # * <   9           .   
           . 2  0
CPU CPU CPU
L1 cache L1 cache L1 cache
Bank 1 Bank 2 Bank 3
Bank 1 Bank 2 Bank 3
1 2 N
1 2 N
Split−transaction Bus
L2 cache
Multibanked Bank M
Bank M
Interleaved
main memory
G H I J K M
N O
P Q M S T U W K X Q H Z M X Z J K M H \ ] ^ M \ M _ Z M ` a
1
 &       .   d       ,      2 #     
.    E  .     f    d   2        i * j l 2   @
          n f d i l p q r s 0 f d i l    2       
.               2 q w s     .     9       #  @
  #         &      .   .               2 
         2    2   .      #        @
    .    2   ?                  n    #   
                 E   #    #    #          @
    2    2   &   #  #                 
& #   #           2  &   #      @    .      @
  2  p   & #    #           .    .         @
          &   9   #       #         
            2      2     #     &   9     @
          2   .      #                 0
~  &  E      l j    #                @
      #     E    * ,    #   E     #    .   @
.    .   2   @             0 i   #      
   #  @   #                    .    ? 
     @    .        2 0
1
      l j  .  & 
#  E     2       .  #  l ‚  d i        ?      @
  2 q , ƒ s 0 l ‚  d i        2      .         „

     & #   #     . & #               #  
#  E   E  2  .       #  2            
.       #  2 .  E  2  .      .  #      
 #     #   &   #        #  2              2 
      E  .   ?  #  2    & #         †     .
    #            0 ‡ #      #            @
    ‰         #  l  d i        2 & #   #     
    9   . E     ?     #   #               
      2 2    #  & #          . &   #   ? ?  
            0
Š #      2        ?          .        2
               .        .    ?  .        
         ? #  &    ‹      ?   †           @
 ?  . 0 i    .    ?   #  * ,    #        2 2   
        2      &  2 2     †     n  #         # 
      * <    #        2 2   & #   #   2      
  †     p      .   †        #      2    @
             ‰  . 0 Š #       #        2 2  
     #    #              .   ?    .    # 
    2      .          #    &   †       
 #           #  E  2   #   ? #  #    @
 2    #     ?    2   †    0 i   #         
      .   ? &        †       .    &     
       2 2  &  .         .    2  #     E   
&           2    . 0 ‡ #    .    ?  .           
      2   9         d l j .    ?   q Πs 0

  Ž  

 ‘    ’ 
“  ” –
Ž — 
“
˜
™ š š
“
š   ›

œ ™
 – ˜  
š
Š              .          ?  #  2       
* ,    #            .      E  2     #     @
           #             0 * ,    # 
    2          .  E  .  .      #        @
?               .   ?    #    2           # 
* ,    #        2 2    #   #    .    .  #   
            ? .    0 l         7   2 2  #   
 #                  #    2 2  &   ? ¢
•
‡
controller
   #              #  * ,
   #        2 2   0 i     2 .    #     
        2  #    †             .    # 
   &  2 2    #                    ?
 #           .   ?    2 0
•
‡
bus
   2 .    #        9           # 
   .            #     9    0
•
‡
mem
   #         .  .   ?   .       
 #         & #   #    E  .     n      
    #   * ,    #        #  * <    # 
  9             p 0
B   #          .           2    2 & #   
 #  #           #       #       #   
&            ¤        #  * ,    #       
   .     l j    #        n     ?      2 2
   ¤        #     #            #  2  &  
XVI Jornadas de Paralelismo, JP '2005 287


 
    
   
    
     "     
 &
  (    +   + 

    -
  

. +
 
- -    0 2 
    "  ( 5 "
   -

   
" 
 
     +  &
 + 
    
               
   - 5


  
5   "  +  + 

   (  
     ( 
    B  &
     "  

 
   
   (   
 
  0 G 

     H          + 
  J K  L 2   

 

  &
      -  -
   H
   +    
M   
 N
O 0 J   
      H
- P (     
 Q O    
R    &
  &     
  N  
 
        M
   
5
   
 
    

     
   -  
 
 
     
 
  
 W     
0
X 0 J   
      H
- P (  
Q X    
R Z   Q X
   
  N   Q O    
  
    -
 
 
5
  -  
Q X        -  
(     0
[ 0 J   
      H
- P (     
   ( R J

   
  N 
  
 Q O    
     
Q X
   
  
  
(    
 
5   -     +  
P
 P    
-         
   ( 0
a 0 2     -        +
M   -
   
 R 2  
   
  N  
  +    M    
       -
 
(    
 
    e  W     
P +      

  "   
 

   (  
5    "    
f &
 +   
  
    

-
- 0 2    

    (  

 
        e  W 
. +
       
P + 
       -  
 

     
 

    

 
R     (    - M   
f  +   
  
   
  0 g       h   -      
 5  
G
mem
   &

 
     
 
  (   B
  P
  + 
-   
     

-
- 0
"
# %
i
j k l
i m
n o
p q i
s t
p
n s
2      
     5 "



   -
  
-

 &
      

  +         y J z   
 
-  
O {   

5   &   -

f
 +     5
  
      

"       + - P
         +  + 
| & y J z  0
G 
     
  + 
          z       } O ~ P + 
 "  
     (
  
      
   +  
- 0 2 
G  P
O "
   

 
   H M +          
  &
   
  + 
"
  

  +  
- 0 Q O    
  B

  
P

 
    
  +   
   
     +  &
P
     
 0
€

f

       
   
       
  
           
  + 
"  P
 
P +  5       -

 
  +  
 

 
       +  + 

    . +

G  P
O N   
     
  + 
   H M +       0
& ( * ( , - / - * 1 ( 4 5 -
6 7 8 : ; = > ? @ > = ; B C D
E C B G H ; I J K
E C M B B > @ G M N G P G N R S T U M R
E C V M N ; W @ R C @ R @ V ; N M Y B Z C @ R @ V ; \ M N M
E ] B G H ; ] ^ K
6 7 8 : ; = > ? E ] : M W _ B I
E ] M B B > @ G M N G P G N R I
E ] V M N ; W @ R ] @ R @ V ; B N M Y B Z I @ R @ V ; B \ M N M
E G W ; B G H ; b ] : R N ; B
^ ; 8 > = R V M N ; W @ R C ] d @ R @ V ; B
K 7 B e = : G N = M N G > W b @ R @ V ; B
K 7 B @ R @ V ; b @ R @ V ; B
K 7 B U G \ N f b ] : R N ; B
G  P
X N
‚

          -  
+    B
 + 
-  
    "   h 0
g h h
4 i j ( / i k l m l
h
5 / n i o -
K e p 6 q r T s t u S d v D : > \ G ; B w S N G 8 ; B N ; x B
q ^ b y
b I S d d W > \ ; B w \ ; Y = ; ; ]
C z { = ; 8 > N ; w ] z N G 8 ; B N ; x B
| | u ] z D J @ > 8 x V ; ~ \ > 7 : V ; B
 €
q e 6 C b d ~ C b d > @ ; M W
p e y ‚ ƒ C ^ _ ; R B w C d ] S = M \ G ~
t 6 r u p t
€
u t p q y ^ ; B f … ] J w z N G 8 ; B N ; x B
† e u q p T 6 r ˆ z C ] 8 > V ; @ 7 V ; B w S N G 8 ; B N ; x B
  
-   
      M     P   

 h 5 "
   &
+  
 
  
     
  + 
P +  "       -


 "   h 5   "      
  P         -
 (   B
 
 ( 
   -  
P +   ( 
- +        
. +   
 

  
     ( 
0 G    
 "   h  
. +   
 
    
 
P +  "   h   M    
  
 
. +
  (
     

  
      
  
    
Q O    
0
G  P
X


    
P
      h  "
  

+ 
-    + 
f

  
   0 G    
  
   &

  
   H  

          
      
 (  
  
+         -       M
  
   0 
‚
„ Š  L &
Z ΠG 5 g g G 5 K y 
‚
Š 5 „
‚
| 2    - €
‚
G  „ &
Š L Ž P
  M    
L z Q
‚
L Z & X P
      h
 +  
} O … ~ 0  J [ |       
- 
   (  

&

          
L
  & y P
      h } a ~ 0 Œ Š &
L G „ Œ y G Œ „  |      
+        ˆ +  - - ( &
      

       } O ‰ ~ 0 G 
 
+    B
   
 


          
P

    
      M    
    +    
   
  B
   -  +  P
     
  
 
P  
 
     
  + 
0
2  g  M + 
X "
   

 
 
  M
 
  (
    &   &  5 Z   Q X 5 J
   - 2      
 -    -
-
     
  
 
   -
    P
-   L
     a   
  


        0
‚

f

 
- 5 " 
  
&
      P +    + 
- 5  
      
 
     

288 Evaluación de Prestaciones, Modelado y Simulación
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
0
50
100
150
200
250
300
350
400
Latency
(cycles)
T_controller
T_bus
T_mem
$-to-$ Hit L2 Mem Inv

 


   
  

Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
Barnes
Em3d
FFT
Ocean
Radix
Unstruct
Water-nsq
0
50
100
150
200
250
300
Latency
(cycles)
T_controller
T_bus
T_mem
$-to-$ Hit L2 Mem Inv
   

 
 !  "
    $

%
    '         ) +   + )  -   ' $  "   $ &   "  ) ) ) +  1 3  )    /       + 4 1 & $  1   7   8
3 4 5 6 7 8 8 9 ; = > ? ? 8 7 @ 5 A C D F 3 6 7 8 8 @ H 5 = > ? ? @ D J 5 ?
> ? @ H 5 @ > = 5 ? J 5 A @ 7 @ @ H 5 M N ? O ? 5 5 P O 7 S S T 9 3 V > W
C 7 8 8 D X @ H 5 = > ? ? @ D J 5 Y > @ H 8 3 Y 5 6 8 7 @ 5 A C D > ? @ H 5
] A 4 = > ? ? X 7 ? @ H 5 6 5 > ? A 3 @ 7 : _ : < = > C 3 = J 3 A 5 A @
7 A a Y 5 a 3 A 3 @ H 7 4 5 @ 3 Y 7 > @ F 3 6 7 6 5 J 8 D T f 5
7 8 ? 3 ? 5 5 @ H 7 @ @ H 5 @ > = 5 ? J 5 A @ 7 @ @ H 5 C 3 A @ 6 3 8 8 5 6
> ? A 5 V 8 > V > M 8 5 Y H 5 A C 3 = J 7 6 5 a Y > @ H @ H 5 M N ? 8 7 W
@ 5 A C D T f 5 @ H > A h @ H > ? > ? 7 C 3 A ? 5 i N 5 A C 5 3 F N ? > A V
> A W 3 6 a 5 6 5 j 5 C N @ > 3 A C 3 6 5 ? X 7 ? 7 = 5 = 3 6 D > A ? @ 6 N C W
@ > 3 A > ? A 3 @ > ? ? N 5 a N A @ > 8 @ H 5 J 6 5 4 > 3 N ? 3 A 5 H 7 ?
C 3 = J 8 5 @ 5 a T
f H 5 A Y 5 N ? 5 7 A > a 5 7 8 > A @ 5 6 C 3 A A 5 C @ > 3 A A 5 @ W
Y 3 6 h X M N ? 8 7 @ 5 A C > 5 ? 7 6 5 a 6 7 ? @ > C 7 8 8 D 6 5 a N C 5 a
P O M S T r H 5 3 4 5 6 7 8 8 8 7 @ 5 A C D F 3 6 @ W @ 3 W @ X t > @ 9 P
7 A a ] A 4 = > ? ? 5 ? > ? 6 5 a N C 5 a M D 7 F 7 C @ 3 6 3 F ; w 7 J W
J 6 3 j > = 7 @ 5 8 D T x 5 a N C @ > 3 A ? F 3 6 y 5 = = > ? ? 5 ? 7 6 5
8 5 ? ? > = J 6 5 ? ? > 4 5 X 7 ? @ H 5 : _ : < = > C 3 = J 3 A 5 A @ > ?
H 7 6 a 8 > = > @ 5 a M D @ H 5 8 7 @ 5 A C D 3 F = 7 > A = 5 = 3 6 D T
f 5 C 7 A 7 8 ? 3 ? 5 5 @ H 7 @ @ H 5
Tmem
C 3 = J 3 A 5 A @ 3 F
@ H 5 8 7 @ 5 A C D > ? 7 J J 6 3 j > = 7 @ 5 8 D { w B V 6 5 7 @ 5 6 F 3 6 @ W
@ 3 W @ 7 A a y 5 = = > ? ? 5 ? T
}
? Y 5 H 7 4 5 6 5 = 3 4 5 a @ H 5
M N ? M 3 @ @ 8 5 A 5 C h X 6 5 i N 5 ? @ ? 7 6 6 > 4 5 7 @ 7 H > V H 5 6 6 7 @ 5
@ 3 C 7 C H 5 7 A a = 5 = 3 6 D C 3 A @ 6 3 8 8 5 6 ? 7 A a X @ H N ? X
@ H 5 ? 5 C 3 A @ 6 3 8 8 5 6 ? 7 6 5 = 3 6 5 8 3 7 a 5 a @ H 7 A > A @ H 5
M 7 ? 5 8 > A 5 7 6 C H > @ 5 C @ N 6 5 T r H 5 ? 5 6 5 ? N 8 @ ? a 5 = 3 A W
? @ 6 7 @ 5 @ H 5 J 3 @ 5 A @ > 7 8 ? 7 4 > A V ? 3 F F N @ N 6 5 J 6 3 J 3 ? 7 8 ?
N ? > A V 7 H > V H W J 5 6 F 3 6 = 7 A C 5 J 3 > A @ W @ 3 W J 3 > A @ > A @ 5 6 W
C 3 A A 5 C @ > 3 A A 5 @ Y 3 6 h J 6 3 4 > a > A V = 3 6 5 M 7 A a Y > a @ H
@ H 7 A 7 M N ? X 7 8 @ H 3 N V H a > C 5 6 5 A @ C 7 C H 5 C 3 H 5 6 5 A C 5
J 6 3 @ 3 C 3 8 ? 7 6 5 @ 3 M 5 > = J 8 5 = 5 A @ 5 a T
f 5 ? 5 5 @ H 7 @ 8 7 @ 5 A C > 5 ? 7 6 5 4 5 6 D 4 7 6 > 7 M 8 5 X 5 4 5 A
F 3 6 @ H 5 ? 7 = 5 7 J J 8 > C 7 @ > 3 A > F Y 5 C 3 = J 7 6 5 a > C 5 6 W
5 A @ = > ? ? @ D J 5 ? T r 3 M 5 @ @ 5 6 N A a 5 6 ? @ 7 A a @ H > ? 5 6 W
6 7 @ > C M 5 H 7 4 > 3 6 X Y 5 = N ? @ 7 A 7 8 D  5 @ H 5 ? @ 7 @ > ? @ > C ?
> A r 7 M 8 5 ? { 7 A a € T  3 @ H @ 7 M 8 5 ? J 6 5 ? 5 A @ ? @ 7 @ > ? W
@ > C ? ‚ N ? @ F 3 6 @ H 5 M 7 ? 5 7 6 C H > @ 5 C @ N 6 5 X ? > A C 5 @ H 5
6 5 ? N 8 @ ? @ H 7 @ 7 6 5 3 M @ 7 > A 5 a F 3 6 @ H 5 C 7 ? 5 Y > @ H 7 A
> a 5 7 8 A 5 @ Y 3 6 h 7 6 5 4 5 6 D ? > = > 8 7 6 T
] A r 7 M 8 5 { Y 5 ? H 3 Y @ H 5 @ 3 @ 7 8 A N = M 5 6 3 F 6 5 W
i N 5 ? @ ? 7 A a 6 5 J 8 > 5 ? ? A 3 3 J 5 a M D C 7 C H 5 C 3 A @ 6 3 8 8 5 6 ?
O C 3 8 N = A ? ; 7 A a P S T ƒ 3 8 N = A ? { 7 A a € C 3 A @ 7 > A ?
@ H 5 7 4 5 6 7 V 5 A N = M 5 6 7 A a J 5 6 C 5 A @ 7 V 5 3 F N ? 5 F N 8
6 5 i N 5 ? @ ? 7 A a 6 5 J 8 > 5 ? ? A 3 3 J 5 a M D 5 7 C H 9 ; C 3 A W
@ 6 3 8 8 5 6 T  D N ? 5 F N 8 6 5 i N 5 ? @ Y 5 N A a 5 6 ? @ 7 A a 7 6 5 W
i N 5 ? @ @ H 7 @ > = J 8 > 5 ? ? 3 = 5 7 C @ > 3 A 3 4 5 6 @ H 5 8 3 C 7 8
C 3 J D 3 F @ H 5 8 > A 5 7 @ @ H 5 9 ; C 7 C H 5 X 7 A a M D N ? 5 W
F N 8 6 5 J 8 D Y 5 = 5 7 A 7 6 5 J 8 D @ H 7 @ C 3 A @ 7 > A ? a 7 @ 7
@ H 7 @ @ H 5 C 7 C H 5 > ? Y 7 > @ > A V F 3 6 T „ > A 7 8 8 D X C 3 8 N = A
… ? H 3 Y ? @ H 5 A N = M 5 6 3 F N ? 5 F N 8 6 5 i N 5 ? @ ? ? A 3 3 J 5 a
M D 5 7 C H 9 P C 7 C H 5 M 7 A h O @ H 5 9 P C 7 C H 5 a 3 5 ? A 3 @
? A 3 3 J 6 5 J 8 > 5 ? S T r H 5 = 7 > A 6 5 ? N 8 @ > ? @ H 5 ? = 7 8 8
A N = M 5 6 3 F N ? 5 F N 8 6 5 i N 5 ? @ ? O 4 5 6 D > A ? > V A > ‡ C 7 A @
> A = 3 ? @ 7 J J 8 > C 7 @ > 3 A ? S T r H > ? > = J 8 > 5 ? @ H 7 @ > A
@ H 5 4 7 ? @ = 7 ‚ 3 6 > @ D 3 F 3 C C 7 ? > 3 A ? X > @ > ? A 3 @ A 5 C W
5 ? ? 7 6 D @ H 7 @ @ H 5 9 ; C 7 C H 5 C 3 A @ 6 3 8 8 5 6 ? ? A 3 3 J @ H 5
6 5 i N 5 ? @ ? @ H 7 @ 7 J J 5 7 6 > A @ H 5 M N ? X 7 ? @ H 5 ? 5 6 5 W
i N 5 ? @ ? 7 6 5 6 5 F 5 6 6 5 a @ 3 7 8 > A 5 @ H 7 @ > @ > ? A 3 @ > A @ H 5
C 7 C H 5 T f 5 C 7 A 7 8 ? 3 ? 5 5 X C 3 = J 7 6 > A V C 3 8 N = A ?
; 7 A a P X H 3 Y @ H 5 A N = M 5 6 3 F ? A 3 3 J 5 a 6 5 i N 5 ? @ ?
a 3 5 ? A 3 @ = 7 @ C H 5 j 7 C @ 8 D @ H 5 A N = M 5 6 3 F ? A 3 3 J 5 a
6 5 J 8 > 5 ? T r H > ? > ? C 7 N ? 5 a M D @ H 5 ] A 4 = > ? ? 5 ? X Y H > C H
a 3 A 3 @ A 5 5 a 7 6 5 J 8 D T
„ > A 7 8 8 D X r 7 M 8 5 € J 6 5 ? 5 A @ ? 7 C 8 7 ? ? > ‡ C 7 @ > 3 A 3 F
H 3 Y @ H 5 7 C C 5 ? ? 5 ? @ 3 @ H 5 9 ; C 7 C H 5 7 6 5 ? 3 8 4 5 a T
y 3 ? @ = 5 = 3 6 D 6 5 F 5 6 5 A C 5 ? 7 6 5 C 7 J @ N 6 5 a 7 @ 9 ;
C 7 C H 5 ? X Y H 3 ? 5 H > @ 6 7 @ 5 ? 6 7 A V 5 F 6 3 =  { T P B @ 3
XVI Jornadas de Paralelismo, JP '2005 289
                          !  # %  & '       # %  !     ,
 
   
   
    




                       
   

    

 !     
 ! 

    !     

" # % ' ) * + , - . / 0 1 1 3 0 3 4 1 / 0 1 1 5 0 6 3 7
8 5 9 0 5 8 3 8 4 8 0 6 1 7 1 1 0 8 4 5
:
4 ; 5 / < >
:
3 ; / / < >
:
8 ; 6 ? < >
) @ / B 1 0 ? 1 / 0 3 4 6 1 0 ? 6 6 0 6 9 /
9 5 0 ? / 6 3 9 ? 0 7 8 5 9 0 8 5 1 0 9 8 /
:
5 ; 9 9 < >
:
3 ; / < >
:
9 8 ; 8 8 < >
C C . 4 0 8 8 5 0 8 8 ? 4 0 8 9 1 0 1 1 4
6 6 / 8 3 0 8 3 3 3 4 8 0 6 6 9
:
5 ; 5 5 5 ? < >
:
3 ; 8 4 < >
:
9 8 ; 4 < >
E G
) # ' 4 0 9 1 ? 0 4 6 4 4 0 5 ? 8 0 ? 4 ?
8 7 0 4 7 3 / 8 3 0 6 6 1 4 ? 3 0 1 1 3
:
5 ; 4 / < >
:
3 ; 6 8 < >
:
9 9 ; 8 1 < >
% # B J K / 0 / 6 4 0 1 8 7 / 0 / 6 9 0 6 1 8
/ 0 5 / 5 8 5 1 0 9 / / 6 9 9 0 3 ? 9
:
5 ; 5 1 < >
:
3 ; 8 3 < >
:
9 8 ; / < >
- ' * . % -
G
. 8 9 0 3 7 5 0 ? 3 8 8 5 0 9 7 8 0 4 3 /
? 4 / 0 / ? 9 9 0 / 4 1 0 9 5 9 9 0 5 5 5 0 4 1 6
:
/ ; 1 6 < >
:
3 ; 7 6 < >
:
6 ; 3 8 < >
M # . ) % + ' * P / 0 9 9 4 0 ? / 6 / 0 9 5 5 0 1 3 9
9 9 6 0 4 8 3 9 1 6 0 1 4 6 9 3 5 0 1 3 ?
:
/ ; 3 ? < >
:
3 ; 8 1 < >
:
4 ; 9 7 < >
    .                1 2         4    7  %  ;  < ,
 
   
    Q S 
T V W  X
  Y Z


Z Y
 
W


T
 [ ] ^  _ ]
`
      
`
      
" # % ' ) * + , - . 7 3 ; 5 8 < 5 ; 6 6 < 5 ; 8 4 <
9 ? ; 3 / < 6 ; 3 8 < 5 ; 5 5 4 < 5 ; 5 6 <
:
7 1 ; 1 ? < >
:
9 1 ; ? 4 < >
:
5 ; 5 8 < >
:
5 ; 9 4 < >
) @ / B 7 / ; 8 < 5 < 5 ; 5 5 9 <
5 ; 6 3 < 9 5 ; / 1 < 9 4 ; ? 8 < 5 ; 9 / <
:
9 ; 7 / < >
:
/ ? ; 7 3 < >
:
4 1 ; 5 9 < >
:
5 ; 4 < >
C C . 1 8 ; 9 4 < 5 < 5 <
5 ; 5 5 5 7 < / ; 1 4 < / ; 1 < 5 ; 5 5 5 / <
:
5 ; 5 5 1 < >
:
4 5 ; / < >
:
6 1 ; 3 1 < >
:
5 ; 5 5 6 < >
E G
) # ' ? ? ; 3 8 < 5 < 5 ; 5 4 <
5 ; ? 6 < ? ; 4 6 < 9 ; 3 1 < 5 ; 8 4 <
:
7 ; 6 6 < >
:
7 4 ; 6 < >
:
9 6 ; 1 8 < >
:
8 ; 8 / < >
% # B J K ? ? ; 3 1 < 5 < 5 <
5 ; 9 3 < ? ; 8 6 < 8 ; ? 1 < 5 ; 5 9 <
:
9 ; 6 6 < >
:
7 8 ; ? 3 < >
:
8 4 ; 4 7 < >
:
5 ; 9 / < >
- ' * . % -
G
. ? 8 ; 6 4 < 5 < 5 ; 5 3 <
1 ; ? 8 < 3 ; 6 6 < 5 ; 5 8 < 9 ; 8 9 <
:
4 3 ; 9 4 < >
:
/ 3 ; ? 8 < >
:
5 ; 9 8 < >
:
3 ; 1 9 < >
M # . ) % + ' * P 1 6 ; ? 1 < 5 < 5 ; 5 9 <
8 ; 1 7 < 8 ; 9 9 < 5 < 5 ; 5 8 <
:
4 ? ; 9 1 < >
:
6 9 ; / / < >
:
5 < >
:
5 ; 6 ? < >
= . , > = b ,    ' ?   %              A      
      ?          '      #   ; %  & '       '  #
 C      ?  ! %       % 4 G I J L        # <  %
 C       % ! %       % 4 Q '         # <   R  % 
 %    %   R  %    %        ! !          ,  
      ' %    ' ?     % %   !   #        W    ? C
! %       #   I       . , X     A    !  %     [
 ;   7  %          ' ?   %                1 2
        # ^    %   `    ^    !  %      ;   7  %
         ' ?   %   ?      ,
b  %   %    ! !          4 Q
f
L c d I [ J e ^
e c I L e e L d g   # X
f
d L [ c I h <    ; [
        ' ?   %   ?       %         #  C   [
    % 1 2      4 i [   [ i ?      < , b  %    %  [
?      ;  ! !          ^ ?    ?       %         #
 C    1 i      ^  W   !             d G g ^
  % A     k = , l 2 b      ?      %     ?   
?  ?  % C , n         ! !          ^     ' ?   %
  n  7 ?      %  ! %         ?     %           
     ,
j p
q
r
s
t
u v w q
r
v
n      !  !  % A    7  ! %       #  1 2     
?      W    ? C        ! [     # g [ G }
4 #        ! [ ? '    ! %       % <     #     A   
?       %         # ,  ' % %   '    !      ' 
       ?             `       `   #    % [
       ' %          %  #  '  ^      ' #   ;    
     C !        %           #       ! %  7  # 
   ' ;     # A  #     %  G }   ? !    #  
2 ‚   %   , X    7     A           ! [     #
    %     ! %         # '       ? '   '     [
    % C A  % `               %     %  ^     
?  „  %   C       !  #  %            %        [
  %   # A                       , Q C   ? [
'      ;  !  %         %              A  % ` ^ A 
  7              !          %  # '        [
290 Evaluación de Prestaciones, Modelado y Simulación
     
              
 
 "  

       % & (   *  +      ( 
     - -    

     

  -    4 (   ( (         -    9
   (  * (   ;   
          
    
   ;
4
 > %
?
      4
 > B 4  -  
 F   9
 
  9        -    *
 ;
 ;
 9   
   


   4  (  
   Q  9   -      


(    S      - 
          
  
9  - ( 
   -  9   -
 9     -  
   9      (   *

  
 
   
  % X      - 
       9  

9  -   * 
  9     
  ;
;
      ;

    
   4
 >    9  +  -    (      ;

      % & (        S     
  
9  ^   ;

    (  
(          (      B 
 4  - -
          
9    *      (  ; 
(       
;


-   -
  9
(       -      
  b d e
   (       %
f g h
i
j 
k l
m  n
l i
o p
& (   4
 > (        
  9   (  q   ;
  ( d      
 b        &   
-
*     9 ( 
  
    
 s t  9   t   9  u   9   *   
& v b w " " x ; " y  z { ; b " | ; " x %
} l

l
~
l i
g
l
p
  €  %
?
%    

B  % (     (
 -

B ‚ % d  ;
      B
?
% 
4  Q  > B q %   9    B
 % q  
B q % q   ( B ‚ % q   B   9  %    * ( ;
   %  e     (  …
?
q   -   - 
?
  (      
    9
 q   * -  ; b (  d  -  
      *  %
v      ‡   " ˆ $ & ( ˆ * ‰ , - / 1 ‡  ( 4  / 1 6 ˆ Š 
8
  $ : ˆ Š  ˆ 6  Š B  *   w y w > w ‹ x B @    w " " " %
 w €  %    >       9 Œ % X

9 %  d    *   *
X    Π -        *  b (  ; d  -  
   

b   (    % v      ‡   D " ˆ $ & ( ˆ * ‰ , - / 1 ‡
 ( H :    Ž   $ : ˆ Š  ˆ 6  Š B  *   x  ‹ > x x " B Œ  ;
      w " " { %
 x €
?
% b (   -   4
 ( %  & (  q   t    -    v  ;
  
     % v      ‡   , 4 M M O Q : R $
 Š     / Ž (  Š U Š ˆ V   W : ( R Ž ( X 4  / 1 6 ˆ : ( R
4  (  Š  Š (  Š B  *    >  { B 
+      w " "  %
 { € Œ %  % b  - -   B
?
% Π      B q % b %
- 9     B
?
%     (      (  B q %      B q %     B
& % +
    >   B   9  %   -   > %  e    - ;
-  - e 
*       *   q -  ; b  % v      ‡  
& ( ˆ * ‰ , 4 O ] ] D Q : R $  Š     / Ž (  Š U Š ˆ V   W

: ( R Ž ( X 4  / 1 6 ˆ : ( R 4  (  Š  Š (  Š B  *  
w | w > w ’ x B 
+       ‹ ‹ x %
 z € Œ %  % b  - -   B @ % e % q   * ( B   9
?
%   %
 Ž  Ž ‰ ‰ Š ‰ 4  / 1 6 ˆ Š 
8
  $ : ˆ Š  ˆ 6  Š

8
Q Ž  X

V Ž  Š  ,   ˆ V Ž  Š
8
1 1   Ž  $ % d
 *       ;
    e   -   (    B v   % B  ‹ ‹ ‹ %
 | € d %  >    B t % Œ  ( - *    B   9 e % q   ;
    %   +  -   

 q 

;     * 
‚  9   
 &   (   S    
 b (  ;
d  -  
   
   % v      ‡   O a ˆ
   W a $  1  (
6 1 ‰ :  Ž ˆ : ( R 
Š   ( a ˆ  6  ˆ

: ( R Ž ( X
Š  6 ( W : ( R B  *   w >   B d  
w " " w %
 ’ €  % “   
 9 B  %
?
% “      B d % q   B
d %  % e    (  B d % b (   B   9  % ” -  >
;
  %  & (  q   
 9 “  9   b d e  % &   
H :    B w " s w u … ’  > y { B d    ( w " " " %
 y €  % “   
 9 B d % X  - -   B   9  % ” -  >
;
  %  Π  q    -  
 q 
 
 
b (  d  -  
   
  % v      ‡   ˆ $ Š  ˆ $
& ( ˆ * ‰ , - / 1 ‡  (
8
  $ : ˆ Š  ˆ 6  Ž ‰ , 6 1 1   ˆ   
 Ž  Ž ‰ ‰ Š ‰  Ž ( R 6 Ž R Š a Ž ( X c 1 Š  Ž ˆ : ( R , - a

ˆ Š / a B  *   z y > | ‹ B ” 
    ‹ ‹ y %
 ‹ € b % @ % “  * (   B  % q % e % e   B e % ‚   ;
*    (   B   9 q %  %
?
9 +  % ‚ q v d … q   ;
 -    * q (    9 ; d  
  d  -  
   
 
4  ( v  e e 
   
  % &    4  / 1 6 ˆ Š  B
x z s w u … | y > ’ | B t        w " " w %
  " € ‚ %   - -  B  % q   (  
 B   9 @ % d % &   9 -   %
v  d e
4   z b (  …
?
Π  - ; b
  d  - ;
 (    9  9 e 
   
 % &    H :    B
w { s w u … { " > { ’ B d    ( ;
?
  - w " " { %
   €  %    4  - - % -   q e
?
‚ b v  d   
  e   ;
9     
 % d   
% ‚ 
 B %  ; x B 
+   ;
   w " " x %
  w €  %     (      9 @ % &
   - -   % 
?
b (  ;
d  -  
   

?
  (       4  ( q   ;
 -   +  d  -  (    9   *  % &      Ž ( a

Ž  ˆ :  ( a c ( 4  / 1 6 ˆ Š  a B { y s ‹ u … y | | > y y " B
q        ‹ ‹ ‹ %
XVI Jornadas de Paralelismo, JP '2005 291

     

              $
%
 $ (   +  -  / - 1 2 (    1  (
6 7 9 ( 7 (  (  ( 7 6  ( @ 1 1 - 1 2 ( % (  6  D
E  F F 7 6   % I  L    N     O    O  P
    N   ! " #   R      S  R '    * O R 
+
  " O R O *  R  T  - ( 
V W /
X Y  [ (      D
\ ] ] ^

^ 

% 6  2 6  6   1 % (  `  b [  F   d 
 $

 2 6  $ 2   D 2 4 5 g g h i [ F 1 (  -
 6 6 T  7 6  l ( $  m ( $ 5 (  - D  6    T n
1 6  % I  (   (   2 L    N   7 O 
  O  P     N   ! " # 
 R      S  R '  

 * O R 
+
  " O R O *  R  T  - (  X Y / p W  4     D
\ ] ]


Y    %  ` 2 (  r ( (   9  2      % 9
@ F F  4 l      

l 6 - (     $    F 1 /
2 5 u m ( 1   T T 6  1 7 6  L   ( -  F  

T T F m  n
1 6  6 9  1    1 ( $ n % (  6  D %  m 2 (  2
L    N    O    O  P     N     "  "

 P R = S  >   S O " R    S  S P P R P    #  S  "  # 
T  - (  W X / V p  4  F D
p p Y

W  4 1  1 ( C    b  6 F 6 2  

 2    $
g  % 6 w  D 2

 m  F   F (

T T  6  m 2 1 6
g 2  (  $ n  (  ( F  T ( m  F  1 6 2 L    N  
G 7 O    O  P     N   '    * O R 
+
  " O R

O *  R  T  - ( 
/
\  4  ( \ ] ] ]

V  I  w (  / ( D  $

4   1 2

 F    6 7
 6  T  1  F (   m 2 (  6   1 ( m D I  6 1 6 m 6 F 
 $ 1 2 (    T T 6  1  D 1 2 ( L 5 5 5 [  1   ( n
   L    N    K O    O  P     N   '  

 * O R 
+
  " O R O *  R  T  - (  ^
^ / ^ \   4  (

p X W

X  % g  `  2    @ g  `  6  5
 ( ` 6   $
   /  ` 2

 2   ( $ n     6 1  6 F % ( m 2 n
    $    m 2 (  6 2 (  ( m ( I  6 1 6 m 6 F
7 6   @ - 2 n T (  7 6    m ( + n m 2 T %  F 1 n
T  6 m (   6  2 L    N   G  >   O  P '    R 

R  R   ! " # 
 R      S  R '    * O R 
+


 " O R O *  R  T  - (  
^ /  \ \  [ (      D
p p W

p    E 6 6  % + 2     5 g 6   (  4 I
 - 2   $

1  T 1  2 g 2 (  I 

 @ n \
T  6 -     i  2    m 1 (  /  1 6  $ % ( 1 2 6 $ n
6 F 6 - m  F  6  $ (   1 6  2 L    N   G G  >
  O  P     N   '    * O R 
+
  " O R O *  R 
T  - (  \ ^ /  W  4  (
p p Y
\ ]  h h   -  w    9 @  -   L w    
P 9 b   F     `    $ @ g   ` 
2  6  T F (  1 D

 F D   6 7

  m 2 (  6 n
1  6 F F (  7 6   T ( m  F  1  ( %  F 1 1 2  (  $ -
 2 T %  F 1 T  6 m (   6   2 L    N     O 
  O  P '    R  R  R   ! " #   R      S  R
'    * O "  #  T  - (   p  / ^ ] ^  9 ( m (   ( 
\ ] ] 
292 Evaluación de Prestaciones, Modelado y Simulación
Adaptación de un Simulador de Potencia para Unidades
Funcionales en Procesadores de Alto Rendimiento
Guadalupe Miñana, Oscar Garnica, José Ignacio Hidalgo, Juan Lanchares
Departamento de Arquitectura de Computadores y Automática
Universidad Complutense de Madrid
guamiro@fdi.ucm.es
José Manuel Colmenar
Ingeniería Técnica en Informática de Sistemas
CES Felipe II, Aranjuez (Madrid)
jmcolmenal@csfelipesegundo.com
Resumen
Una optimización en el diseño, o cualquier
modificación en la arquitectura de los
procesadores, se aceptada si una herramienta de
simulación de potencia indica una reducción en el
consumo sin un incremento significativo en el
tiempo de computación. Por ello, la precisión en
las estructuras, la velocidad y la exactitud de la
microarquitectura simulada son de importancia
crítica para los investigadores. SimpleScalar se ha
convertido en la principal herramienta de
simulación y modelado de sistemas de alto
rendimiento. Existen varios simuladores que
añaden a dicha herramienta un modelo para el
cálculo de consumo de las distintas estructuras del
procesador. Wattch es uno de ellos y el más usado
en los artículos científicos presentados en
conferencias de arquitectura de computadores
internacionales. Sin embargo, este simulador
estima el consumo en las UFs de manera poco
precisa. Por ejemplo tiene modeladas las UFs para
calcular el consumo de distinta forma a como
están modeladas funcionalmente. En este artículo
se presenta una versión del Wattch a la cual le ha
añadido algunas modificaciones para estimar el
consumo en las UFs con más precisión.
1. INTRODUCCION
Existen numerosas herramientas de diseño
automático para minimizar el consumo de
potencia. Algunas están diseñadas
específicamente para el campo de la potencia
mientras que otras tienen un carácter más general
y se usan sobre todo para otras optimizaciones.
Existen distintos niveles de abstracción en los que
se utilizan las herramientas de análisis.
Los modelos de bajo nivel se basan en el
estudio de las capacidades de difusión, de puerta y
de las líneas a partir de las descripciones
completas del circuito o del layout. Se realiza una
simulación analógica utilizando modelos muy
detallados de los dispositivos y resolviendo una
gran cantidad de ecuaciones para obtener una
precisión muy elevada. Son modelos capaces de
obtener valores de la potencia estática y la
dinámica con un margen de error muy pequeño.
Todo esto conlleva un coste computacional
elevado y que solo sean prácticos para diseños de
hasta 100K transistores. Los modelos más
utilizados son los de los simuladores Hspice y
PowerMill (Sypnosys) que es unas diez veces más
rápido que el primero.
Los modelos de nivel medio trabajan a nivel
RTL. Para ello definen estructuras en VHDL o
Verilog y calculan el consumo. Un ejemplo de
este nivel de abstracción se puede encontrar en
[6]. En el se explica una metodología simple para
calcular el consumo dinámico. Su principal
defecto es que no tiene en cuenta el consumo
estático y como ya se ha dicho para las
tecnologías actuales es impensable obviar el
efecto de las corrientes de leakage. La idea
fundamental es utilizar eventos en VHDL para
detectar la actividad de los dispositivos lógicos.
Es importante conocer los modelos de niveles
de abstracción inferiores porque al realizar
mejoras orientadas a reducir el consumo de
potencia, siempre debemos tener en mente las
consecuencias físicas que producen y además nos
pueden orientar a la hora de hacer el diseño.
Nuestro interés se centra en una mayor medida en
los modelos de alto nivel que utilizan las
herramientas y en especial las basadas en
SimpleScalar.
Podemos encontrar en la literatura varios
simuladores de alto nivel. Así tenemos a
Myrmigki que es un simulador específico para
microcontroladores y microprocesadores
familiares. Para sistemas empotrados se simula
sobre la base del HITACHI SH3, y es extensible a
otros sistemas por su diseño modular. Estima que
es un estimador de potencia, área y latencia para
bancos de registros segmentados y multi-puerto.
Simple Power [4][5]que es una herramienta de
simulación basada en la ejecución de programas
(execution-driven) y que suministra información
del consumo en cada ciclo de reloj (cycle-
accurate). Funciona a nivel de transferencia entre
registros (RTL) y utiliza modelos de energía
sensibles a las transiciones. El simulador Step-
Power que hace una estimación del consumo en
cada ciclo. Para un Vsupply constante, el consumo
es proporcional al consumo de corriente (di/dt),
De esta forma lo que calcula es la variación de
potencia por ciclo, que traducido da nombre a la
herramienta, StepPower [6][7]. No cuenta el ruido
de conmutación y utiliza el modelo de Wattch cc3.
Es un modelo que está en desarrollo y que debe
incorporar la estimación del consumo debido a los
fallos en la predicción y en las distintas
variaciones de acceso a la memoria caché.
Por último tenemos Wattch que es un
conjunto de cuatro modelos [2]. Cada modelo
considera una situación distinta de activación o
funcionamiento. El primer modelo supone que
todas las partes del sistema están activas en todo
momento. El segundo considera que se produce
un consumo del 100% cuando hay un acceso y 0%
cuando no lo hay. La tercera forma de considerar
el sistema es estimando un 10% de consumo
cuando no hay acceso a una parte y un consumo
lineal cuando si lo hay. Finalmente se dispone de
un modelo intermedio entre los dos anteriores.
Está basado en SimpleScalar 3.0, concretamente
en la herramienta sim-out-of-order e implementa
un pipeline de 5 etapas. Se ha realizado una
validación del modelo de estimación del
procesador dividiéndolo en cuatro tipos de
bloques. La primera son las estructuras en array
que incluyen las caches de datos e instrucciones,
los arrays de etiquetas en la caché, todos los
registros, RAT (register alias tables), predictores
de saltos y una gran parte de la ventana de
instrucciones y de la cola de load/store. Las
memorias totalmente asociativas direccionables
por contenido constituyen el segundo grupo y son
la lógica de wake-up de la ventana de
instrucciones y del buffer de reordenamiento, los
módulos de comprobación del orden de load y
store, o los TLBs entre otros. El tercer tipo de
bloque modelado es el referente a la lógica
combinacional y cableado, donde estarían las
unidades funcionales, la lógica de selección de la
ventana de instrucciones, el comprobador de
dependencias y los buses de resultado. Por último
se modelan las señales de reloj (incluyendo
buffers, líneas de reloj y cargas capacitivas). Sin
embargo, este simulador estima el consumo en las
UFs de manera poco precisa. En este artículo se
presenta una versión del Wattch a la cual le he ha
añadido algunas modificaciones para estimar el
consumo en las UFs con más precisión.
El resto del capítulo está organizado de la
siguiente forma: La sección 4.1 presenta el
simulador FU-Wattch y las incorporaciones
hechas para estimar el consumo en las UFs con
mas precisión. La sección 4.2 muestra algunos
resultados experimentales que validan el
simulador FU-Wattch. La sección 4.3 presenta
una comparación entre el consumo estimado por
Wattch y el consumo estimado por FU-Wattch,
donde se puede apreciar la mejora que se realiza
con el nuevo simulador.
2. SIMULADOR FU-WATTCH
2.1. UNIDAD DE EJECUCION
Se ha elegido un modelo de UFs similar a la
clásica organización del Alpha 21264 [12] pero no
idéntico. La razón de esto es poder simular
procesadores más generales. La Figura 1 muestra
un esquema del modelo que se ha elegido. En ella
se puede ver que la unidad de ejecución está
compuesta por una unidad de enteros y otra de
punto flotante. La unidad de enteros esta formada
por cuatro clusters, similares al modelo de clusters
del Alpha 21264. Cada uno de ellos contiene un
sumador de 64 bits (ADD), una unidad lógica
(LOGIC), y una unidad de desplazamientos
294 Evaluación de Prestaciones, Modelado y Simulación
(SHIFT). En uno de los cuatro clusters además
hay un multiplicador (MULT). Por otro lado la
unidad de punto flotante tiene dos clusters. Uno de
ellos está compuesto por un sumador (FP ADD) y
el otro por un multiplicador (FP MULT) ambos en
p.f.
Para estimar el consumo en las UFs con el
modelo que se acaba de describir se han
distribuido las instrucciones como muestra la
Tabla 1. En ella se puede ver que, por ejemplo a
efectos de cálculo de consumo, todas las
instrucciones lógicas son procesadas como si
fueran ejecutadas en la unidad lógica. Esto
significa que habrá consumo dinámico y estático
en la unidad lógica mientras que el resto de
componentes solo aportarán consumo estático.
2.2. MODIFICACIONES HECHAS A
WATTCH
Como ya se ha comentado anteriormente, FU-
Wattch es una versión modificada del Wattch
donde se han incluido algunas mejoras que
permiten obtener valores de consumo en las UF
que son más próximos a los valores mencionados
en la literatura que los que se obtienen con el
Wattch original. A continuación se explican las
modificaciones que se han implementado y sus
justificaciones:
1. En términos de consumo de potencia, Wattch
modela la Unidad de Ejecución de Enteros
como un sumador. Para simular de manera más
real el comportamiento funcional de dicha
unidad se le han incluido mas componentes, de
manera que en FU-Wattch la unidad de enteros
esta compuesta por sumador, unidad lógica y
unidad de desplazamiento, como representa la
figura 1.
2. Por otro lado, en términos de rendimiento,
SimpleScalar considera la operación de
multiplicación de enteros. Sin embargo a la
hora de calcular el consumo cuando se ejecuta
una instrucción de multiplicación de enteros,
Wattch aplica la misma unidad que para el resto
de instrucciones de enteros, un sumador. En
FU-Wattch se ha incluido tanto consumo
estático como dinámico de multiplicadores (ver
figura 1).
3. Lo mismo ocurre con las instrucciones de Punto
Flotante. Todas ellas, sin importar que tipo de
unidad funcional necesiten, son modeladas, en
términos de consumo, como operaciones de
suma. En FU-Wattch se ha incluido en el
modelo de consumo de las unidades funcionales
un sumador y un multiplicador de punto flotante
(ver figura 1).
4. Wattch muestra un solo valor de consumo. En
dicho valor, solo si se usa el modelo cc3 (Linear
Clk gating w/ 10%) [2], esta incluido el
consumo estático. En este modelo cuando no se
producen accesos a una estructura se tiene en
cuenta el consumo estático que viene
representado por el 10% del consumo total de
dicha estructura. En el caso de las UFs, cuando
no se accede a ninguna UF se tiene en cuenta el
consumo estático de todas pero cuando quedan
algunas UFs sin usar, el consumo estático de
dichas UFs no se tiene en cuenta. Esto hace que
el consumo estático en las UFs no este bien
estimado. Este defecto se corrige en FU-
Wattch, de manera que ahora se tiene en cuenta
el consumo estático de las UF en todos los
casos. Además se ha separado el consumo en
sus dos componentes: dinámica y estática, con
lo que FU-Wattch muestra dichos valores en
dos variables distintas.
Por último, Wattch tiene implementada la
técnica de clock gating. FU-Wattch tiene adaptado
el clock gating de manera que solo se tenga en
cuenta el consumo dinámico en las unidades
funcionales que estén ejecutando alguna
instrucción. Es decir, si solo se esta ejecutando
una instrucción lógica, sólo hay consumo
dinámico en la unidad lógica, aportando el resto
de UFs (sumador, unidad de desplazamiento,
multiplicador….) solamente consumo estático.
Figura 1. Modelo de la unidad de ejecución
que he implementado
Float point Unit
FP ADD
FP MULT
Integer Unit
ADD
LOGIC
SHIFT
MULT
ADD
LOGIC
SHIFT
ADD
LOGIC
SHIFT
ADD
LOGIC
SHIFT
XVI Jornadas de Paralelismo, JP '2005 295
UFs para
enteros
Tipo de instrucción de enteros
Desplazador
• Instrucciones de desplazamiento
• Instrucciones de Manipulación de
Byte
Unidad Lógica
• Lógicas
• Integer Conditional Move
• Comparaciones Lógicas
Sumador
• Aritméticas de enteros
• Comparaciones Aritméticas
• Calculo de la direcciones efectivas
para las instrucciones de L/S
• De Control
Multiplicador • Multiplicación de Enteros
UFs para FP Tipo de instrucción de P.F
Sumador
• Aritméticas en Punto Flotante
(salvo multiplicación, división y
raiz cuadrada)
Multiplicador
• Mulitiplcaciones en Punto Flotante
• Divisiones en Punto Flotante
• Raices Cuadradas
Tabla 1. Unidades Funcionales y sus
instrucciones asociadas
3. VALIDACIÓN DEL SIMULADOR
FU-WATTCH
Para validar la precisión del modelo de consumo
en las UFs del simulador FU-Wattch, se han
ejecutado algunos benchmarks del conjunto SPEC
CPU2000 sobre dicho simulador y sobre el
simulador Sim-Alpha [1] con el fin de comparar
ambos resultados. El objetivo de esta sección es
poder comparar los resultados estimados con los
dos simuladores con valores reales de consumo de
la arquitectura Alpha aportados en la literatura [2].
Se ha elegido el Sim-Alpha para esta comparación
porque aunque ambas herramientas simulan la
arquitectura del Alpha 21264, la precisión del
Sim-Alpha es mayor.
Sim-Alpha es un simulador basado en
SimpleScalar [3][4] pero que simula de manera
más precisa que el Simplescalar las características
del Alpha 21264 como se demuestra en [1]. De
manera que, en términos de funcionalidad, simula
perfectamente el modelo de UFs de la arquitectura
Alpha 21264 [12]. Para que este simulador haga
estimaciones de consumo se le ha incorporado el
mismo fichero para calcular el consumo que usa
FU-Wattch, adaptado a las UFs de la arquitectura
Alpha 21264 (ver Figura 2).
Por otro lado también se ha adaptado el
modelo de UFs del FU-Wattch (que como se ha
comentado anteriormente este modelo es similar
pero no igual a la clásica organización del Alpha
21264) para que los dos simuladores simulen las
mismas UFs. Para ello al modelo usado en FU-
Wattch (ver Figura 1) se le ha añadido una unidad
para el calculo de raíces cuadradas (FP SQRT),
una unidad de división (FP DIV), dos unidades
para calcular las saltos condicionales (BRANCH),
dos sumadores de enteros para generar la
dirección efectiva de las instrucciones Load y
Store (ADDL/S) y una unidad para ejecutar
instrucciones especiales como PERR, MINxxx, ..
(MVI/PLZ).
Una vez adaptados los dos simuladores, Sim-
Alpha con cálculo de potencia en las UFs y FU-
Wattch con el modelo de UFs de la arquitectura
del Alpha 21264, se han ejecutado algunos
benchmarks del conjunto SPEC CPU2000. Con
los benchmarks elegidos se ha intentado cubrir
todo el rango de comportamientos. Además como
la simulación completa de cada uno de ellos puede
llevar semanas, se ha usado la herramienta Sim-
point [16] para seleccionar un conjunto de
instrucciones que sea representativo de la
ejecución total del programa. De esta forma de
cada benchmarks se han simulado 100M de
instrucciones elegidas con sim-point. Como
entradas se han tomado las entradas de referencia.
Figura 2. Modelo de la unidad de ejecución
de la arquitectura del Alpha 21264.
Float point Unit
FP ADD
FP MULT
FP SQRT
FP DIV
Integer Unit
MVI/PLZ
ADD
LOGIC
SHIFT
BRANCH
MULT
ADD
LOGIC
SHIFT
BRANCH
ADD
LOGIC
ADDL/S
ADD
LOGIC
ADDL/S
296 Evaluación de Prestaciones, Modelado y Simulación
Figura 3. Consumo Total en la unidad de
ejecución obtenido con Sim-Alpha y FU-Wattch.
(a) muestra los resultados para INTSPEC 2000.
(b) muestra los resultados para FPSPEC 2000.
La Tabla 2 resume el número, tipo y consumo
de las distintas UFs que se ha usado en las
simulaciones. Los valores de consumo se han
obtenido de literatura [2] y el número y tipo de
UFs representan a la arquitectura Alpha 21264
[12]. Como porcentaje para representar el
consumo estático se ha usado el 25% del consumo
total, siendo el restante 75% el consumo
dinámico. Esto es así no solo para las UFs sino
para todas las estructuras del procesador. Esto se
ha hecho así porque es el porcentaje de consumo
estático que indican en la documentación del
Alpha 21264, cuya arquitectura estamos
simulando [12].
La Tabla 3 muestra las principales
características del procesador que se ha simulado
en FU-Wattch. Para el simulador Sim-Alpha se
han usado los mismos parámetros salvo las
particularidades relacionadas con las diferencias
entre sus algoritmos.
Los resultados de las simulaciones se pueden
ver en las Figuras 3 y 4 La Figura 3 muestra el
consumo total en la unidad de ejecución (medido
en watios), obtenido con los simuladores Sim-
Alpha y FU-Wattch, para todos los benchmakrs.
Mientras que la Figura 4 muestra el porcentaje
que representa dicho consumo respecto al
consumo total del procesador. En el caso del Sim-
Alpha para calcular este porcentaje se ha usado el
consumo total del procesador obtenido con FU-
Wattch ya que Sim-Alpha solo tiene incorporado
el consumo en las UFs. .
Tipo de UF
Consumo
por
unidad
Nº de
UFs
disponibles
Sumador de
Enteros(64bits)
1.16503W 4
Unidad Lógica 0.104394W 4
Unidad de
Desplazamiento
0.505265W 2
Mulitiplcador
de
Enteros(16bits)
0.897785W 1
Unidad para L/S 1.16503W 2
Unidad para
Branco
1.7703W 2
Unidad Especial 1W 1
Sumador de
Punto Flotante
3.57026W 1
Mulitiplcador
de Punto
Flotante
3.57026W 1
Divisor de
Punto Flotante
3.57026W 1
SQRT de Punto
Flotante
3.57026W 1
Tabla 2. Consumo estimado (W) de cada Unidad
Funcional a 5V, 733MHz y 180nm.
Como podemos observar en ambas figuras, los
resultados obtenidos con el simulador FU-Wattch
son muy cercanos a los obtenidos con Sim-Alpha.
Las pequeñas diferencias en los resultados son
debidas a que, aunque las dos herramientas
simulan la arquitectura del Alpha 21264,
presentan diferencias en el algoritmo
implementado. Por otro lado, el porcentaje de
consumo que representan las UFs respecto al resto
del procesador en ambos casos es prácticamente
el que se encuentra en la literatura del Alpha
(a)
(b)
0
2
4
6
8
10
12
ammp
applu
apsi
art
equake
facerec
galgel
lucas
mesa
mgrid
sixtrack
swim
wupwise
FU-Wattch Sim_Alpha
0
2
4
6
8
10
12
bzip2
crafty
eon
fma3d
gap
gcc
gzip
mcf
parser
perlbmk
twolf
vortex
vpr
FU-Wattch Sim_Alpha
XVI Jornadas de Paralelismo, JP '2005 297
21264 (alrededor del 20 %), [2]. Estos resultados
validan las incorporaciones introducidas en
Wattch
.
Parameter Value
Processor Core
RUU size 80 instructions
LSQ (ld/store
queue)
size 32
Fetch Queue
Size
4 instructions
Fetch width 4 instructions/cycle
Decode width 4 instructions/cycle
Issue width
6 instructions/cycle (out-of-
order)
4 integer, 2 p.f
Commit width
11 instructions/cycle (in-
order)
Functional units
4 Integer Clusters , 2 FP
clusters
Branch Prediction
Branch Predictor
Combining
bimodal predictor: table size
4K
2-level predictor l1size 1K;
l2size 1K; hist_size 3
meta_table_size 4K
BTB num_sets 512; associativity 4
Return-address
stack
32-entry
Mispredict
penalty
7 cycles
Memory hierarchy
L1 data-cache dl1:512:64:2:L ; lat 3
L1 instruction-
cache
l1:512:64:2:L ; lat 2
L2 Unified
ul2 :32768:64:1:L ; dl2lat
6 ; il2lat 12
TLBs dtlb:1:8192:128:l lat 50
Tabla 3. Configuración Base del procesador
simulado
4. COMPARACION DE LOS
SIMULADORES WATTCH Y FU-
WATTCH
Con el objetivo de valorar la mejora introducida
por FU-Wattch en esta sección se muestra una
comparación entre los resultados obtenidos con el
simulador original –Wattch- y FU-Wattch. En
estas simulaciones se han usado los mismos
benchmarks y la misma configuración del
procesador (ver Tabla 3) que en la sección
anterior. La única diferencia en la configuración
es el comportamiento de las UFs en cuanto a
consumo se refiere. En FU-Wattch el modelo de
UFs es el descrito en la Sección 1 (ver Figura 1)
que como ya se ha comentado es similar a la
clásica organización del Alpha 21264 [12] pero no
idéntico ya que el objetivo es usar un modelo que
simule procesadores más generales. Por otro lado
Wattch mantiene el modelo original, que, como ya
se ha dicho anteriormente, consiste en modelar, en
términos de consumo, las UFs como sumadores
de enteros y de punto flotante. Insisto en que esta
diferencia en el modelo de las UFs solo es en el
comportamiento frente a la estimación del
consumo ya que el comportamiento funcional de
dichas unidades es idéntico.
La Tabla 4 resume el número, tipo y consumo
de las distintas UFs para cada uno de los
simuladores. Al igual que en la sección anterior,
los valores de consumo se han obtenido de la
literatura.
Tipo de UF
Consumo
/unidad
FU-
Wattch
Wattch
Sum. Enteros
(64bits)
1.16503W 4 4
Unidad Lógica 0.104394W 4 0
Unidad de
Despalzamiento
0.505265W 4 0
Mul. Enteros
(16bits)
0.897785W 1 0
Sumador de
Punto Flotante
3.57026W 1 1
Mul. PF 3.57026W 1 0
Tabla 4. Consumo estimado (W) de cada
Unidad Funcional a 5V, 733MHz y 180nm.
298 Evaluación de Prestaciones, Modelado y Simulación
Figura 4. Porcentaje del consumo de la
unidad de ejecución respecto al consumo total del
procesador obtenido con Sim-Alpha y FU-Wattch.
(a) muestra los resultados para INTSPEC 2000.
(b) muestra los resultados para FPSPEC 2000.
La Figura 5 muestra el porcentaje que
representa el consumo de las UFs respecto al
consumo total del procesador, estimado con
Wattch y con FU-Wattch, para todos los
benchmarks. En estas gráficas se puede apreciar
que hay una gran diferencia entra los valores
obtenidos con cada uno de los simuladores. Con
Wattch el porcentaje medio es un 8% para los
benchmarks de enteros y un 10% para los de
punto flotante. Mientras que con FU-Wattch estos
porcentajes son el 11% y 13,5% respectivamente.
5. CONCLUSIONES Y TRABAJO
FUTURO
En este artículo hemos presentado una versión
modificada de la herramienta de simulación de
potencia Wattch. El objetivo de la modificación
ha sido conseguir un modelo más preciso para
estimar los consumos de potencia tanto estáticos
como dinámicos en los clusters de las unidades
funcionales o aritmeticológicas.
Los resultados experimentales demuestran que los
resultados del simulador son más reales en
términos de porcentajes de potencia total
consumida por las unidades funcionales en el
procesador. También hemos comprobado que
nuestros resultados son mas razonables
comparados con los valores de Wattch.
El principal objetivo de este artículo ha sido
obtener una herramienta más realista para
examinar nuevas arquitecturas y organizaciones
de las unidades funcionales. Estamos trabajando
en el examen de nuevos modelos de clusters con
especial énfasis en las unidades aritmeticológicas
y su diseño en potencia.
Figura 5. Porcentaje del consumo de la unidad de
ejecución respecto al consumo total del
procesador obtenido con Wattch y FU-Wattch. La
Figura (a) muestra los resultados para INTSPEC
2000. Figura (b) muestra los resultados para
FPSPEC 2000
Agradecimientos
Este trabajo ha sido financiado por el proyecto del
Ministerio Español de Ciencia y Tecnología TIC
750/2002
(a)
(b)
0%
5%
10%
15%
20%
25%
bzip2
crafty
eon
fma3d
gap
gcc
gzip
mcf
parser
perlbmk
twolf
vortex
vpr
FU-Wattch Sim_Alpha
0%
5%
10%
15%
20%
25%
ammp
applu
apsi
art
equake
facerec
galgel
lucas
mesa
mgrid
sixtrack
swim
wupwise
FU-Wattch Sim_Alpha
(a)
(b)
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
ammp
applu
apsi
art
equake
facerec
galgel
lucas
mesa
mgrid
sixtrack
swim
wupwise
Wattch FU_wattch
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
bzip2
crafty
eon
fma3d
gap
gcc
gzip
mcf
parser
perlbmk
twolf
vortex
vpr
Wattch FU_wattch
XVI Jornadas de Paralelismo, JP '2005 299
Referencias
[1] R. Desikan, D. Burger, S. W. Keckler and
T.Austin. Sim-Alpha: a Validated, Execution-
Driven Alpha 21264 Simulator. Technical
Report TR-01-23, Department of Computer
Sciences, University of Texas at Austin, 2001.
[2] D. Brooks, V. Tiwari, and M. Martonosi.
Wattch: A framework for architectural-level
power analysis and optimizations. In
Proceedings of the 27th Annual International
Symposium on Computer Architecture, June
2000.
[3] D. Burger, T. M. Austin and S. Bennett.
Evaluating Future Microprocessors: the
Simple.Scalar Tool Set. Technical Report
1308, Computer Sciences Department,
University of Wisconsin, Madison, WI, July
1996.
[4] T. Austin, E. Larson and D. Ernst.
SimpleScalar: An Infrastructure for Computer
System Modelling. Computer, v.35 n.2, p.59-
67, February 2002.
[5] W. Ye, N. Vijaykrishnan, M. T. Kandemir, M.
J. Irwin: The design and use of simplepower:
a cycle-accurate energy estimation tool. DAC
2000: 340-345
[6] W. El-Essawy, D.H. Albonesi, and B. Sin-
haroy. A Microarchitectural-Level Step-Power
Analysis Tool. International Symposium on
Low Power Electronics and Design, pp. 263-
266, August 2002
[7] N. S. Kim, T. Austin, T. Mudge and Dirk
Grunwald. Challenges for Architectural Level
Power Modeling. Power Aware Computing.
Eds. R. Melhem and R. Graybill, Kluwer
Academic Publications, 2002.
[8] D. Brooks, J. D. Wellman, P. Bose, and M.
Martonosi. Power Performance Modelling and
Tradeoffs Analysis for a High-End
Microprocessors. Power Aware Computing
Systems Workshops at ASPLOS-IX. Nov
2000.
[9] D. Brooks, P. Bose, and M. Martonosi. Power-
Performance Simulation: Design and
Validation Strategies. ACM SIGMETRICS
Performance Evaluation Review, 2004.
[10] S. Dropshot, V. Kursun, D. H. Albonesi, S.
Dwarkadas and E. G. Friedman. Managing
static leakage energy in microprocessor
functional units. International Symposium on
Microarchitecture, Proceedings of the 35th
annual ACM/IEEE international symposium
on Microarchitecture. Pp 321 – 332. 2002.
[11] J. Frenkil. Tools and methodologies for low
power design. Proceedings of the 34th annual
conference on Design automation conference,
p.76-81, June 09-13, 1997, Anaheim,
California, United States.
[12] R. E. Kessler. The Alpha 21264
Microprocessor. In IEEE Micro, April 1999.
[13] S. Borkar. Design Challenges of Technology
Scaling. In IEEE Micro, July 1999.
[14] J. L. Henning. SPEC CPU2000: Measuring
CPU Performance in the New Millennium.
Computer, v.33 n.7, p.28-35, July 2000
[15] MinneSPEC: A New SPEC Benchmark
Workload for Simulation-Based. Computer
Architecture Research. Information available
at:
http://www.arctic.umn.edu/~lilja/spec2000/ind
ex.html.
[16] E. Perelman, G. Hamerly and B. Calder.
Picking
300 Evaluación de Prestaciones, Modelado y Simulación
Simulating complex systems with a low-detail model
R. Nou, J. Guitart, V. Beltran, D. Carrera, L. Montero‡, J. Torres, E. Ayguadé
{rnou, jguitart, vbeltran, dcarrera, torres, eduard}@ac.upc.edu, lidia.montero@upc.edu‡
Barcelona Supercomputing Center (BSC) Dept. of Statistics and Operations Research‡
Computer Architecture Department Technical University of Catalonia
Technical University of Catalonia Pau Gargallo 5
C/ Jordi Girona 1-3, Campus Nord UPC E-08028 Barcelona
E-08034 Barcelona (Spain) Spain
Abstract
In this paper we show how modeling and sim-
ulating a complex system such as a web-server
can help to evaluate dierent metrics and pro-
posals to improve the performance without ne-
cessity of using a real system. Many times
the system is unavailable or requires spending
time and resources to generate results. With
simulation and concretely with a coarse-grain
simulation as we propose can solve with great
success this problem. In this article we have
been able to simulate the metric and behav-
iour of a web server with SSL security, the el-
lapsed time required by the simulation on a
desktop machine is only 1/10 of real time. We
have also been able to measure, for example,
the performance enhancements with 8 CPUs
without having an available machine of simi-
lar features.
Keywords: Performance Prediction, Mod-
elling, Simulation, webserver, RUBiS, dy-
namic web sites.
1 Introduction
We can view an Application Server based on
the J2EE platform as a complex system, sev-
eral things happen at the same time, and
there are many levels involved; from threads
to TCP/IP, including cryptographic and se-
curity issues. These systems are widely ex-
tended nowadays and they are used in many
commercial environments, in most of complex
web applications currently online and in many
B2B links. At the same time, all informa-
tion that is condential or has market value
must be carefully protected when transmitted
over the open Internet. Security between net-
work nodes over the Internet is traditionally
provided using HTTPS[16]. This widespread
diusion of dynamic web content and SSL in-
creases the performance demand on applica-
tion servers that host the sites, leading some-
times these servers to overload.
During overload conditions, the response
times may grow to unacceptable levels, and
exhaustion of resources may cause the server
to behave erratically or even crash causing de-
nial of services. In e-commerce applications,
which are heavily based on the use of secu-
rity, such server behaviour could translate to
sizable revenue losses. For instance, [19] esti-
mates that between 10 and 25% of e-commerce
transactions are aborted because of slow re-
sponse times, which translates to about 1.9
billion dollars in lost revenue.
These systems are known to be very com-
plex to characterize. This inherent complex-
ity makes it extremely dicult for systems de-
velopers and managers to estimate the size
and capacity of the deployment environment
needed to guarantee good system usage like
maintain a throughput. Managers are often
faced with questions such as the following:
What are the maximum load levels that the
1
system will be able to handle? What would
the throughput and resource utilization be un-
der the expected workload? How would per-
formance change if load is increased? Does
the system scale? Taking performance mea-
surements is relatively simple if the system is
running. However, how to take performance
measurements when the system does not ex-
ist, or we cannot aord for it?
In this case we can estimate the perfor-
mance measurements by means of some kind
of performance model. Dierent approaches
have been proposed in the literature for perfor-
mance analysis and prediction models for this
type of e-business systems. Most of them ex-
ploit analytical models which analysis is based
on Markov Chain Theory [6]. Queuing Net-
works and Petri Nets are among the most pop-
ular modeling formalisms that have been used.
But due the complexity of today e-business
systems, the analytical methods for solving are
not allowed. Only by simplifying the system
we can obtain treatable models. On the other
hand these systems cannot model, in an easy
way, timeouts behaviour.
The simulation model is an abstract rep-
resentation of the system elements and their
interactions, and an alternative to analytical
mathematical models. The main advantage
of simulation is that it overcomes the limita-
tion of complex theoretical models, while the
methodological approach to simulation mod-
els and the analysis of simulation results is
supported by statistical principles developed
in the last 30 years.
There are several works on simulating sys-
tems to extract information about them [17,
18], but there are a lack of resources modeling
application servers and problems like the one
we are facing.
In this paper we use a benchmark that rep-
resent a real-world application and demon-
strate the benets of this approach. Once the
simulation model is validated and it is consis-
tent with real measurements, then the simu-
lation is a powerful performance analysis and
prediction tool for this type of complex sys-
tems.
The rest of the paper is organized as fol-
lows: Section 2 introduces the analyzed sys-
tem, a web server with SSL security, section
3 explains simulation environment and tools
used. On Section 4 we describe experimen-
tal environment. Inside Section 5 we explain
all the blocks that build the model simulated.
Section 6 compares simulation results with ex-
perimental results. In Section 7 we show some
interesting results that can be obtained from
simulated models. More information and fur-
ther experiments can be found on report [14].
2 Secure dynamic web applications
2.1 Dynamic web applications
Dynamic web applications are a case of multi-
tier application and are mainly composed of
a Client tier and a Server tier, that consist of
a front-end web server, an application server
and a back-end database. The client tier is re-
sponsible of interacting with application users
and to generate requests to be attended by the
server. The server tier implements the logic of
the application and is responsible of serving
user-generated requests.
When the client sends to the web server
an HTTP request for dynamic content, the
web server forwards the request to the appli-
cation server (as understood in this paper, a
web server only serves static content), which is
the dynamic content server. The application
server executes the corresponding code, which
may need to access the database to generate
the response. The application server formats
and assembles the results into an HTML page,
which is returned as an HTTP response to the
client.
2.2 SSL protocol
The SSL protocol (explained in [8])provides
communications privacy over the Internet.
The protocol allows client/server applications
to communicate in a way that is designed to
prevent eavesdropping, tampering, or message
forgery. SSL increases the computation time
necessary to serve a connection remarkably,
due to the use of cryptography to achieve their
objectives. This increment has a noticeable
302 Evaluación de Prestaciones, Modelado y Simulación
impact on server performance, which has been
evaluated in [9]. This study concludes that
the maximum throughput obtained when us-
ing SSL connections is 7 times lower than when
using normal connections. The study also no-
tices that when the server is attending non-
secure connections and saturates, it can main-
tain the throughput if new clients arrive, while
if attending SSL connections, the saturation
of the server provokes the degradation of the
throughput.
More information about the impact of using
SSL on server performance can be found in [9].
We have measured the computational demand
of a full SSL handshake in a 1.4 GHz Xeon
machine to be around 175 ms, the resumed
handshake only takes 2 ms. It seems logical
that some admission control can be used using
this two handshakes as criteria [10]. Succesful
simulation of this admission control could be
found in report [14].
3 Modeling proposal
Before we look at our simulation approach we
include a brief introduction to the modeling
paradigm, the simulation tools and the tools
to obtain the information we needed.
3.1 Modeling paradigms
A simulation model works replaying, with
more or less detail, the typical behaviour of
the system under study. We need to create
the behaviour of every component of the sys-
tem to start the simulation, we need also to
dene what data we want to extract from the
system. Finally we need to specify when the
simulation will nish.
3.2 Simulation tool
Simulation [11, 15] is the modeling technique
of choice when obtaining exact or adequately
accurate analytic models is very dicult for
the system to be modeled. Simulation models
mimic the behaviour of a real system through
computer programs that randomly generate
events such as arrivals of requests and move
these requests around through the various sim-
ulated queues. Several counters accumulate
metrics of interest such as total waiting time
in a queue and total time a resource was busy.
These counters can be used at the end of the
simulation to obtain average waiting times, av-
erage response times, and utilization of the
various resources
Simulation is usually much more computa-
tionally intensive than analytic models. On
the other hand, simulation models can be
made as accurate as desired or focus over some
specic target.
To the best of our knowledge, there are not
any simulation packages that are specically
oriented for this type of systems. We de-
cided to use Objective Modular Network Test-
bed in C++ (OMNet++) [3]. OMNeT++
is an object-oriented modular discrete-event-
driven simulator based on C++. The simula-
tion package can be used to model: communi-
cation protocols, computer networks and traf-
c modelling, multi-processors and distributed
systems, etc. All of this without apparently
limitations, because we are programming the
several services we need.
3.3 Performance analysis framework
In order to obtain service times for simula-
tion (Tables 1) we propose use a performance
analysis framework developed in our research
center. This framework, which consists of
an instrumentation tool called Java Instru-
mentation Suite (JIS [7]) and a visualization
and analysis tool called Paraver [4], consid-
ers all levels involved in the application server
execution (operating system, JVM, applica-
tion server and application), allowing a ne-
grain analysis of dynamic web applications.
For example, the framework can provide de-
tailed information about thread status, system
calls (I/O, sockets, memory & thread manage-
ment, etc.), monitors, services, connections,
etc. Further information about the implemen-
tation of the performance analysis framework
and its use for the analysis of dynamic web
applications can be found in [7].
XVI Jornadas de Paralelismo, JP '2005 303
Event Time
SSL connection 170ms
Reuse SSL 2ms
Connection, request 3ms
Page Prob Dynamic Static
RUBiSlogo.jpg 35,6% 0ms 3,65ms
Bidnow.jpg 26,1% 0ms 0,17ms
SearchItems 14,3% 18,2ms 2,8ms
ViewItem 11,0% 0,7ms 2,1ms
ViewUserInfo 3,0% 5,8ms 11,7ms
Buyitnow.jpg 2,2% 0ms 0,2ms
Table 1: CPU times to process a request
3.4 Input information for the simulation
We used all the information extracted from
data sheets of a real system benchmark and
we obtained good results with a simplied set
of data. In later stages we improved the accu-
racy of the input model, using more real input
to validate results. Our target was to achieve
a similar graphics, but not the same values,
for that we would need to program (with accu-
racy) for example HTTPProcessor and session
persistence. We can nd in Tables 1 some of
the data we used to simulate the system.
Some experimental data and statistical
analysis gave us client arrival rate, # of re-
quest per client and the ratio between static
and dynamic requests. Although we obtained
a good approximation over real system with
only this data, we had service times for all
kind of requests and his % of appearance as
shown in Table 1 so we added a high detail
level using them.
4 Benchmark and platform
The system we are going to simulate composes
of an application server (Apache Tomcat) serv-
ing pages and accessing data on a mySQL
database. Finally we have several clients ac-
cessing the application server. This kind of
environment is frequently modeled [12], but
we add several new components to simulation,
that as we know haven't been added before.
First a SSL protocol between clients and ap-
Figure 1: OMNET++ Model layout
plication servers, and lastly and the harder to
get on an analytical model, are timeouts.
4.1 Auction site benchmark (RUBiS)
The RUBiS (Rice University Bidding System)
[5] benchmark servlets version 1.4 on Tomcat
will be the generator of the workload we are
using to study the system. Httperf, a web
perfomance measurement tool, is used with
this workload. Httperf [13] allows the creation
of a continuous ow of HTTP/S requests is-
sued from one or more client machines and
processed by one server machine. The work-
load is divided by sessions, every session issues
several request (burst and not-burst) with a
thinktime between request.
4.2 Experimental environment
We use Tomcat v5.0.19 [2] as the applica-
tion server. In this paper we use Tomcat
as a standalone server (serving dynamic and
static web content). Tomcat is congured
with 100 HTTPProcessor. In order to pre-
vent server overload in secure environments,
[10] have incorporated to the Tomcat server a
session-oriented adaptive mechanism that per-
forms admission control based on SSL connec-
tions dierentiation. Further details could be
readed on [10].
5 Model description
The system was modeled using ve black boxes
(Figure 1): Client that simulates httperf and
304 Evaluación de Prestaciones, Modelado y Simulación
RUBiS workload, accessProcessor that sim-
ulates operating system backlog of connec-
tions and allow setting up admission policies.
HTTPProcessor manages connections using
SSL hand-shake and reusing SSL. HTTP-
processor also processes requests and sends to
mySQL as needed. To conclude a replyProces-
sor gets the reply from mySQL or HTTP-
Processor and sends it to the client.
We do not want to build a system with a
great level of detail; we do not include threads
in our model although we modeled a simpli-
ed HTTP 1.1 scheme. Our objective was to
achieve an approximation to the real system
values, without using a large processing time.
5.1 Modeled blocks
Client (client), programmed to generate
statistically the same workload as the real sys-
tem. We found using statistical analysis, that
our original workload is distributed 1/3 and
2/3 between dynamic and static requests, also
client arrivals follows an exponential distribu-
tion of a mean of 7 seconds.
This block also manages timeouts; they are
easily modeled using the API on OMNet++.
As a side note, we can generate more clients
that in the real system, because we have not
any client limitation.
accessProcessor (accproc): a queue
(FIFO) that sends request to HTTPProcessor
(and if it is required, do some admission con-
trol). From here is easy to control limitation
policies on HTTPProcessor so we can fast
test several policies just changing the code on
it. Inside this block we had modeled typical
linux buers behaviour (backlog).
HTTPProcessor (reqproc): it uses a
Processor Sharing scheduling to simulate
threads. This block provides information to
accessProcessor to simulate persistence and
HTTP 1.1 behaviour.
mySQLProcessor (mysql) : emulates the
behaviour of a database. As we focus on
TOMCAT with SSL this MySQL block is not
modeled with detail. We used a Processor
sharing scheme to model the original behav-
iour.
replyProcessor (replyproc): this block
simply sends the reply to the client and it
doesn't do any processing on it, on real sys-
tem it is included inside Tomcat.
5.2 Execution
To produce the results, several simulations
with dierent random seeds had been exe-
cuted. this results was processed statistically
and presented in a graphical form. The execu-
tion was done on a standard desktop computer
in less of half an hour. Real system needed a
day to produce the same results.
6 Model building
In this section we present the validation of
the model comparing the results obtained with
real life system. In order to improve the accu-
racy of the performance, we rened the simu-
lation model (workload, service times but also
behaviour). One of the most important be-
haviours was how httperf managed timeouts.
In order to match the real system we used 100
HTTPProcessors on our simulation.
6.1 Comparing the original Tomcat be-
haviour
Figure 2 shows the Tomcat throughput as a
function of the number of new clients per
second initiating a session with the server.
When the number of clients that overload the
server has been achieved, the server through-
put degrades until approximately the 20% of
the maximum achievable throughput while the
number of clients increases.
The cause of this great performance degra-
dation on server overload has been analyzed
in [9]. They conclude that the server through-
put degrades when most of the incoming client
connections must negotiate a full SSL hand-
shake instead of resuming an existing SSL con-
nection. In our simulation as can be seen on
XVI Jornadas de Paralelismo, JP '2005 305
0
10
20
30
40
50
60
70
80
90
0 5 10 15 20 25 30 35
replies/sec
New clients/s
R
eply rate - Simulation vs O
rig
inal
Simulation Original
Figure 2: Comparing throughput with simulation
Figure 2 we achieved a similar shape (and ap-
proximate values).
Response time is tightened with persistence
optimization on HTTP 1.1, which has not
been fully modeled on our simulation, so we
had not shown this kind of graphic. We should
know our model limitations and use only for
what it is intended for. The results were ful-
lling, but future work will try to simulate the
exact behaviour.
7 Results
This kind of coarse-grain simulation allows us
run tests over hardware or systems that are
not available and obtain performance predic-
tions. We will demonstrate that the simula-
tion with that simple model, using low level
of detail, adapts well to the real system. Its
low complexity allows us to simulate long time
tests without a high computational cost. An
example is to test a large range of admission
policies in low execution time.
Although if it is necessary, this simulation
model can be extended in any detail level in
order to obtain any type of information.
In order to illustrate utility of the simulation
proposed we will show some tests examples
that we can not do with the real system (be-
cause are not available or the execution time
make it impossible to run). There are a great
number of questions that can be answered by
0
50
100
150
200
250
300
350
400
450
0 5 10 15 20 25 30 35
replies/sec
New clients/s
reply rate - Simulation for several CPUs
1 CPU SIM
2 CPU SIM
3 CPU SIM
4 CPU SIM
5 CPU SIM
6 CPU SIM
7 CPU SIM
8 CPU SIM
Figure 3: Throughput with simulation
simulation.
7.1 Scalability of the application
Our simulation model is very simple, however
it can describe with great approximation real
model system. For example assume that we
need to know the behavior of our application
with a system with more that one CPU. We
have this information for one CPU, and we
have obtained the parameters from this exe-
cution. What will be the behaviour for more
CPUs? In Figure 3 we show the obtained
throughput for 1 to 8 CPUs. Because we have
a 4-vias multiprocessor system we already run
the real application in order to conrm the
estimation obtained thought the simulation.
The Figure 4 shows the throughput of the real
system for several CPUs. We can see that
very similar shapes are achieved. In this case,
although we considerate to create some ex-
tra blocks to simulate Operating System con-
tention on more than 1 CPU, we conclude that
model adapts ne.
To carry out a real run we need to consume
as minimum 200 minutes (on the other hand
we have the diculty to obtain or to maintain
such resources during the execution time), this
run provides us with a line (i.e. 1 CPU REAL
of Figure 4), we can do the same on simu-
lation (on the same machine) in less than 3
minutes. Aproximately two orders of magni-
tude less with the help of simulation to achieve
306 Evaluación de Prestaciones, Modelado y Simulación
0
50
100
150
200
250
300
0 5 10 15 20 25 30 35
replies/sec
New clients/s
reply rate - several CPUs
1 CPU 2 CPU 3 CPU 4 CPU
Figure 4: Throughput (Real System)
the same results.
7.2 Advantages of simulation
In simulation we can adapt the model to help
us to extract this and other kind of data. We
can accomplish tests that would cost resources
or be dicult to implement on the real sys-
tem easily or unaordable, simulation gives
us more exibility to add variables and count
thinks like the maximum number of opened
sessions on an instant, how the system works
with more processors, or what is the eect of
modifying pool size. This can help us to eval-
uate system modications in a fast and quite
reliable way.
Simulation time with nowadays computers
is greatly reduced. In our case a simulation
with this great number of messages would be
intractable a few years ago. Another impor-
tant factor is memory usage. This gives us
the possibility to test several QoS policies in
real time without having it implemented and
running on a real machine. We can feed the
simulator with the same workload as the real
one, an look its progress inside the system in
every moment.
8 Conclusions
In this paper we have presented a method to
simulate an existing system and to show how
we can obtain some experimental data without
the need to use neither resources nor the time.
In this work we used only data from 1 CPU
real system run, and from his sample work-
load. Our model uses OMNET++ to describe
the servers, services and clients behaviour with
all the detail we could need, and achieves to
predict the shape of the real system plots. Al-
though that we do not modelled the system
with deep detail to predict real numbers, we
found that they are very similar and enough
to make some predictions and take the results
seriously.
To nd more specic results we will need a
more detailed model (i.e. OS contention with
more than one CPU), however some questions
that we can answer with further exploration
can be: can we know the optimal number
of opened sessions? How behaves analyzing
backlog queue using known services times from
tomcat? How can response time be aected
switching from a FIFO to LIFO queues? How
would aect to the application server scalabil-
ity the addition of more resources?. Answer to
these questions could be achieved using this
simple model. A simple model produces re-
sults in less time that a complicated one.
Using simulation gives us more exibility
and capability to extract data and run some
test that could be unaordable with real re-
sources. We can measure what throughput
we could achieve (at least an approximation)
with the addition of more processors, threads
or with a change of the number of clients. We
did not need the real system for this, only sim-
ulation.
Future work will include simulating the ex-
act behaviour of HTTPProcessor, possibly at
thread level to see how we can obtain all the
response time data, also we should test sev-
eral QoS policies involving backlog queue, and
assignation of requests to HTTPProcessors.
9 Acknowledgements
This work is supported by the Ministry
of Science and Technology of Spain and
the European Union (FEDER funds) under
contract TIN2004-07739-C02-01 and by the
CEPBA (European Center for Parallelism
XVI Jornadas de Paralelismo, JP '2005 307
of Barcelona). For additional information
about the authors, please visit the Barcelona
eDragon Research Group web site [1].
References
[1] Barcelona edragon research group.
www.cepba.upc.es/eDragon.
[2] Jakarta tomcat servlet container.
jakarta.apache.org/tomcat.
[3] Omnet++. /www.omnetpp.org.
[4] Paraver. http://www.cepba.upc.es/paraver.
[5] C. Amza, E. Cecchet, A. Chanda, A. Cox,
S. Elnikety, R. Gil, J. Marguerite, K. Ra-
jamani, and W. Zwaenepoel. Specica-
tion and implementation of dynamic web
site benchmarks. WWC-5,Austin,Texas,
USA., November 25 2002.
[6] G. Bolch, S. Greiner, H. De Meer, and
K. S. Trivedi. Queueing networks and
markov chains. Modelling and Perfor-
mance Evaluation with Computer Science
Applications. Wiley, New York, 1998.
[7] D. Carrera, J. Guitart, J. Torres,
E. Ayguadé, and J. Labarta. Complete
instrumentation requirements for perfor-
mance analysis of web based technologies.
ISPASS'03, pp. 166-176, Austin, Texas,
USA, March 6-8 2003.
[8] T. Dierks and C. Allen. The tls protocol,
version 1.0. RFC 2246, January 1999.
[9] J. Guitart, V. Beltran, D. Carrera, J. Tor-
res, and E. Ayguadé. Characterizing se-
cure dynamic web applications scalabil-
ity. IPDPS'05, Denver, Colorado, USA,
April 4-8 2005.
[10] J. Guitart, V. Beltran, D. Carrera, J. Tor-
res, and E. Ayguadé. Session-based adap-
tative overload control for secure dynamic
web application. ICPP-05,Oslo,Norway,
June 14-17 2005.
[11] A.M. Law and W.D. Kelton. Simulation
Modeling and Analysis. McGraw Hill,
2003.
[12] Daniel A. Menacé, Virgilio A. F. Almeida,
and Lawrence W. Dowdy. Performanceby
Design. Pearson Education, 2004.
[13] D. Mosberger and T. Jin. httperf: A
tool for measuring web server perfor-
mance. WorkshoponInternetServerPer-
formance(WISP'98)(inconjunctionwith
SIGMETRICS'98), pp. 59-67. Madison,
Wisconsin, USA, June 23 1998.
[14] R. Nou, J. Guitart, V. Beltran, D. Car-
rera, L. Montero, J. Torres, and
E. Ayguadé. Simulating and modeling se-
cure web applications. Research Report
UPC-DAC-RR-2005-31, 2005.
[15] B.l. Fox P. Bratley and L.E. Schrage.
A Guide to Simulation. Springer-Verlag,
1987.
[16] E. Rescorla. Http over tls. RFC 2818,
May 2000.
[17] C. Stewart and K. Shen. Performance
modeling and system management for
multi-component online services. NSDI,
2005.
[18] B. Uragonkar, G.Paci, P. Shenoy,
M. Spreitzer, and A. Tantawi. An analyt-
ical model for multi-tier internet services
and its applications. SIGMETRICS'05,
Alberta, Canada, June 6-10 2005.
[19] T. Wilson. E-biz bucks lost un-
der ssl strain. Internet Week Online.
www.internetwk.com/lead/lead052099.htm,
MAy 20 1999.
308 Evaluación de Prestaciones, Modelado y Simulación
Simulador de referencias a memoria en sistemas caché multinivel a
través de Internet
M. A. Herrera, J.M. Palomares, E. Herruzo, J.I. Benavides
Área de Arquitectura y Tecnología de Computadores
Depto. Electrotecnia y Electrónica
Escuela Politécnica Superior
Univ. de Córdoba
14071 Córdoba
i62hedim@uco.es, jmpalomares@uco.es, el1hegoe@uco.es, el1bebej@uco.es
Resumen
Se presenta un sistema web que aloja un si-
mulador que nos muestra el contenido de un
sistema Caché Multinivel tras la ejecución de
un programa introducido por el usuario. Di-
cho programa estará escrito en código C y será
compilado por el propio sistema. Gracias a In-
ternet, se permite el uso del mismo por varios
usuarios diferentes, secuenciándose el acceso.
Este sistema proporciona mayor cercanía a los
estudiantes e investigadores que necesiten sa-
ber la evolución del contenido de una determi-
nada Caché, completamente configurable, ya
que no requiere el aprendizaje de un lenguaje
nuevo, sino que hace uso de un lenguaje bien
conocido y ampliamente utilizado.
1. Introducción
Este sistema, basado en un proyecto fin de
carrera[1], se ha realizado como una herra-
mienta docente de apoyo para el aprendizaje
del funcionamiento de los sistemas Caché Je-
rárquicos Multinivel[2, 3]. Estos sistemas han
tenido una gran relevancia en todos los pro-
cesadores comerciales modernos, que han in-
cluido varios niveles de caché para aumentar
las prestaciones. Los alumnos de las asignatu-
ras relativas a Arquitectura de Computadoras
han de llegar a comprender y manejar con sol-
tura el concepto de sistemas caché para una
completa formación. Para el estudio de estos
sistemas Caché existen un gran conjunto de
herramientas software, básicamente simulado-
res, que permiten a los estudiantes practicar
con estos conceptos. Estos simuladores se ins-
talan y ejecutan localmente en cada ordena-
dor, de tal manera, que se necesitan laborato-
rios con bastantes ordenadores para que todos
los alumnos puedan realizar sus prácticas. Una
queja generalizada por parte del alumnado es
que no suelen tener tiempo suficiente sólo con
las horas de prácticas asignadas en el hora-
rio, por lo que necesitan aulas de libre acceso
con los simuladores instalados para que ellos
puedan finalizar sus prácticas fuera de las ho-
ras oficiales. Por otra parte, en la actualidad,
la gran mayoría de alumnos poseen, al menos,
un ordenador personal en sus casas y muchos
de ellos tienen acceso a Internet. Este hecho
permite que los alumnos puedan acceder a los
sistemas informáticos de manera remota, por
lo que, se podría evitar la imperiosa necesidad
de tener que abrir los laboratorios de libre ac-
ceso, ya que podrían acceder mediante Inter-
net. Así pues, en este trabajo presentamos una
doble vertiente, un simulador del contenido de
memoria caché y un sistema basado en Inter-
net que aloja dicho simulador, permitiendo su
uso a todos los usuarios registrados.
2. Instalación y Administración
El sistema está dividido en dos partes bien di-
ferenciadas, el sistema web y el simulador. El
sistema web se basa en un servidor web, que
debe ser compatible con el lenguaje PHP y
un servidor de bases de datos MySQL. Para
la parte del simulador se requiere la instala-
ción de un compilador de C. Este compilador
permitirá la compilación y posterior ejecución
dentro del simulador de los programas fuentes
introducidos por los usuarios. El sistema web
se puede instalar tanto bajo el Sistema Ope-
rativo Windows, como bajo Linux. Si el S.O.
sobre el que se instalará el sistema es Linux,
deberemos seleccionar los paquetes de instala-
ción necesarios para instalar el servidor web
Apache, con el módulo de extensión de PHP
y el servidor MySQL. También se requiere la
instalación del compilador de C de GNU (gcc)
con las librerías habituales. Por el contrario,
si el S.O. elegido es Windows, se requiere la
instalación de un servidor web que permita la
ejecución de código PHP. Nosotros recomen-
damos la instalación del sistema AppServ, que
incluye el servidor Web de Apache compilado
con la extensión de PHP y con el servidor de
bases de datos MySQL. Adicionalmente, como
compilador de C para Windows, recomenda-
mos la instalación de los sistemas integrados
Dev–CPP o bien de DJGPP. La instalación
del sistema se puede realizar una vez que se
han instalado y configurado todos los progra-
mas para un funcionamiento estándar. En este
paso, se construye una base de datos dentro del
servidor MySQL, en la cual se almacenarán los
usuarios registros permitidos en el sistema. Es
imprescindible que exista un administrador, el
cual se encargará de la puesta a punto del sis-
tema y controlará todos los aspectos de tipo
funcional del mismo. Este administrador po-
drá:
• Crear nuevos usuarios.
• Modificar la información asociada de to-
dos los usuarios.
• Dar de baja a un usuario en el sistema.
• Comprobar las estadísticas del sistema.
Todas estas operaciones se realizan desde el
propio sistema web, sin necesidad de acceder
a ningún otro programa diferente al propio sis-
tema.
3. Utilización por un Usuario Regis-
trado
Una vez que un usuario registrado entra en el
sistema, éste le muestra la página principal de
simulación (ver Fig. 1) en la cual se indican
los parámetros que permiten la configuración
del sistema caché. Se pueden configurar el nú-
mero de niveles de la jerarquía, qué niveles de
jerarquía se usarán, el número de conjuntos,
bloques por conjunto, palabras por bloque y
la asociatividad de la caché. Todos estos datos
se pueden grabar para su carga. Estos ficheros
se almacenan en el servidor en directorios
diferentes para cada usuario de manera que
no haya posibilidades de mezcla entre dis-
tintas configuraciones de diferentes usuarios.
Tras la configuración del sistema caché, el
usuario tiene que introducir el programa que
se desea simular escrito utilizando código
ANSI–C [4]. Existen algunas restricciones:
Las matrices tendrán que estar definidas de
manera estática, el nombre de las matrices
no puede tener más de 8 caracteres y no se
pueden definir más de 30 matrices. Podemos
indicar de manera manual la dirección de
inicio de cada una de las matrices, para ello,
simplemente hay que añadir una variable por
cada una de las matrices que se deseen ajustar:
“int direc_<NombreMatriz> = Start_address;”.
int A[20];
int B[50];
int direc_A = 0x0120;
int direc_B = 0x06F0;
Algoritmo 1: Ejemplo de definición de matrices
4. Simulación
El fichero en C que contiene el programa que
deseamos simular se transfiere al servidor y se
almacena en un directorio del mismo. Este fi-
chero es procesado, eliminándose los espacios
310 Evaluación de Prestaciones, Modelado y Simulación
Figura 1: Pantalla principal de configuración del sistema caché
en blanco innecesarios y los comentarios. Tam-
bién se añade automáticamente una línea al
principio del fichero que incluye las librerías
necesarias para el procesamiento de simulación
y otra línea al final del código que indica que
se debe finalizar la simulación. Tras esto se
realiza una búsqueda exhaustiva de todas las
matrices declaradas estáticamente, como se ha
indicado previamente. Se calcula la función de
acceso de cada una de las matrices. Una vez
que ha sido modificado el fichero de entrada,
se compila con el compilador de C y si no se
producen errores, se ejecuta y se capturan los
resultados generados por el fichero modificado.
Se produce una página web dinámica (ver Fig.
2) con los resultados que se pueden obtener de
manera independiente en cada nivel de la ca-
ché configurada. Se presentan el conjunto de
aciertos y fallos de caché que se han generado
en cada nivel tras la ejecución del código. Se
contemplan tres tipos de fallos de caché: for-
zosos, de capacidad y de conflicto. También se
puede obtener el estado final en el que queda
el contenido de los diversos niveles de caché. Si
la página de respuesta es menor de 512 KB.,
se podrá ver online, en otro caso, se permite
descargarlo comprimido o incluso enviarlo por
email.
5. Aspectos educativos
Se desea que este sistema web de simulación
se utilice en cursos sucesivos dentro de la titu-
lación de segundo ciclo de Ingeniero en Infor-
mática en la Universidad de Córdoba. Hasta
el momento actual, se ha estado utilizando en,
al menos en 5 asignaturas de varias titulacio-
nes, un programa simulador de memoria caché
multinivel llamado SiCAM [5]. Este simulador
requiere que los usuarios introduzcan el códi-
go a simular escrito en lenguaje ensamblador
MIPS. Unido al hecho en sí de comprender
el concepto de caché, para muchos estudian-
tes, el escribir el código a simular en ensam-
blador MIPS ha producido una dificultad adi-
cional. Esto es debido a que, en general, los
alumnos no están acostumbrados a programar
en ensamblador y menos aún en ensamblador
MIPS. Otro aspecto que mejora este sistema
web frente al simulador SiCAM es que permite
a los alumnos ver el contenido de la caché al
finalizar la simulación del código, a la vez que
pueden obtener una gran cantidad de datos es-
tadísticos (aciertos y fallos de caché: forzosos,
de conflicto y de capacidad). Por último, va
a permitir a los alumnos acceder al simulador
por Internet, no necesitando instalar de mane-
ra local el simulador.
XVI Jornadas de Paralelismo, JP '2005 311
Figura 2: Pantalla de resultados de simulación
6. Conclusiones
Se presenta un sistema web que aloja un simu-
lador del contenido de referencias de una caché
jerárquica multinivel. Este simulador permite
la simulación de programas escritos en C, per-
mitiéndose configurar completamente diversos
niveles de caché y, tras la ejecución del código,
ver el contenido final de los diversos niveles de
la caché. También permite ver los resultados
estadísticos del uso a nivel de fallos y aciertos
de caché. Se espera que el tiempo de adapta-
ción de los alumnos a este sistema sea menor
que a otros sistemas que previamente se venían
usando debido al uso de C como lenguaje de
entrada. Esto permitirá al alumnado concen-
trarse en cómo los diversos valores de la confi-
guración de la caché afecta al funcionamiento
de la ejecución de los programas.
Agradecimientos
Este trabajo ha sido subvencionado por el
Área de Arquitectura y Tecnología de Compu-
tadores del Departamento de Electrotecnia y
Electrónica de la Universidad de Córdoba.
Referencias
[1] Herrera Díaz, M.A.; Hermán Capitán, M;
Sistema Web para la Simulación de Refe-
rencias a Memoria y su Localización en la
Memoria Caché. Escuela Politécnica Su-
perior. Univ. de Córdoba. España. 2004.
[2] Hamacher, C; Vranesic, Z; Zaky, S. Or-
ganización of Computadores. 5a
ed. Ma-
drid. McGraw-Hill/Interamericana de Es-
paña S.A. 2003.
[3] Patterson, David A; Hennessy, John L. Es-
tructura y Diseño de Computadores. Inter-
ficie circuitería/programación. Ed. 2000.
España. Editorial Reverté, S.A. 2000.
[4] Schildt, H. Manual of Referencia C. 3a
ed.
Madrid-España. 1997.
[5] Algaba García, D.; Herruzo Olmo, M. Apli-
cación interactiva de simulación del com-
portamiento de una memoria caché multi-
nivel. Escuela Politécnica Superior. Univ.
de Córdoba. España. 2001.
312 Evaluación de Prestaciones, Modelado y Simulación
Medición de los contadores hardware del procesador en modo
exclusivo de ejecución
Pedro Navajas Ezequiel Herruzo J. Ignacio Benavides
Área de Arquitectura y Tecnología de Computadores
Dpto. de Electrotecnia y Electrónica
Escuela Politécnica Superior
Universidad de Córdoba
i12namop@uco.es eze@uco.es el1bebej@uco.es
Resumen
Este trabajo presenta un sistema para solu-
cionar la dispersión de los resultados de me-
didas de rendimiento en la ejecución de pro-
gramas. Estas medidas de rendimiento corre-
sponden a eventos de computación tomados
de la lectura de los contadores hardware del
procesador y que corresponden a característi-
cas de ejecución de los programas (número de
ciclos, fallos de cache, operaciones en punto
otante, de enteros, etc.). En este documento
se explican los pasos seguidos para que estos
datos sean los más ables posible realizando
una modicación en el planicador de instruc-
ciones del sistema operativo de forma que la
ejecución de los programas que se analizan se
realice de modo exclusivo de ejecución. La lec-
tura y análisis de estos contadores hardware se
realiza utilizando funciones perfctr libre dis-
posición. Se presentan los resultados experi-
mentales obtenidos en la ejecución de algunos
benchmarks de SPEC2000 (CINT2000).
1. Introducción
Este trabajo presenta un método gracias al
cual puedan obtenerse mediciones más ac-
ertadas de la ejecución de programas. Es-
tas mediciones se realizan sobre los conta-
dores hardware del procesador usando her-
ramientas de medición conocidas y de libre
uso (FAHB?JH y su interfaz 2)21 ), en sistemas
monoprocesadores de propósito general como
pueden ser los procesadores Intel o AMD. El
sistema incorpora el concepto de monotarea
en un sistema operativo multitarea (en este
caso las pruebas se realizan en una máquina
GNU/Linux) con el n de intentar disminuir
las diferencias de valores entre distintas prue-
bas para medir un mismo evento del proce-
sador. Para conseguir este objetivo se incor-
poran al sistema herramientas y funciones en
tiempo real que permiten modicar la pri-
oridad del proceso que se quiere testear. Se
presentan algunos resultados experimentales
tomados sobre benchmarks de SPEC2000 en
distintas situaciones (sin ruido de ejecución,
con ruido de procesamiento y con ruido de en-
trada/salida). Y se comparan estos resultados,
para estas tres situaciones, en dos contextos:
en modo de ejecución normal del sistema y en
modo de ejecución exclusiva en el sistema im-
plementado.
En la siguiente sección se presentan algunos
conceptos previos sobre la planicación de eje-
cución de tareas y herramientas de medición
de los registros del procesador que conviene
conocer y tener en cuenta para entender el
resto del trabajo. En la sección 3 se explica
el desarrollo del sistema propuesto. La sección
4 muestra algunos resultados experimentales
obtenidos; y nalmente la sección 5 presenta
las conclusiones de este trabajo y el futuro tra-
bajo a desarrollar.
2. Conceptos previos
2.1. Planicación y linux
En la gran mayoría de los sistemas operativos
modernos, una tarea una vez enviada a la
agenda del sistema es cuanticada y tratada
según la política con la que fuera insertada.
La mayoría de las agendas de planicación de
los sistemas operativos actuales poseen dis-
tintas políticas de planicación con diversas
prioridades para cada política.
En linux, existen tres políticas de
planicación[4], SCHED_RR, que repre-
senta una planicación no apropiativa del tipo
Round-Robin, SCHED_FIFO, que indica
la planicación en modo apropiativo (no
obstante puede ser expulsado por una tarea
de mayor prioridad, así como por una tarea
que se ejecute en espacio kernel si nuestra
tarea FIFO se ejecuta en espacio de usuario)
y SCHED_OTHER, que es la política usada
por defecto en cualquiera de las tareas que
ejecuta un usuario.
Una primera aproximación para conseguir que
un proceso se ejecute sin interferencias sería
el establecer su política de planicación a
SCHED_FIFO, aunque en este caso nuestra
tarea podría seguir siendo eliminada de la
agenda en el caso de alguna interrupción
generada por el sistema, un proceso crítico de
mayor prioridad etc.
2.2. RTAI
RTAI es un conjunto de parches y herramien-
tas para dotar a Linux de una baja latencia
en su planicación, haciendo que ésta sea
cercana a la de algunos sistemas operativos
en tiempo real comerciales.
La principal característica de RTAI, que la
hace parte importante de nuestra prueba,
es que para conseguir reducir el tiempo de
latencias y conseguir de esa forma un sistema
operativo en tiempo real, ejecuta el núcleo
de linux como si éste fuera un proceso de
baja prioridad[3]. Gracias a esto cualquier
tarea que se ejecute usando la API del
RTAI, interrumpirá siempre a los procesos
pertenecientes a linux que se hayan apropiado
del planicador, esto implica además, que un
proceso de linux nunca podrá quitar de la
cola de planicación a un proceso de tiempo
real, ya que la prioridad del segundo es mayor.
2.3. Herramientas de medición
Con el n de poder tomar medidas sobre la
ecacia bien del código, bien del procesador,
han ido apareciendo a lo largo de estos últi-
mos años varias herramientas destinadas a la
toma de medidas relacionadas con numerosos
eventos del procesador.
Uno de los mayores problemas que surgieron
con este tipo de herramientas fueron los erro-
res cometidos debido a la cuanticación de
la tarea a medir por parte del planicador
del sistema, ya que ésta ocupará solo unos
cuantos del total del sistema, siendo los otros
ocupados por tareas de mayor prioridad (como
ejemplo en el caso del sistema que nos ocupa,
linux, como se vio anteriormente cualquier
tarea en modo kernel siempre expulsaría a
la tarea evitando que ésta se apropie de la
CPU, de hecho en los kernels de la rama 2.6
incluso este tipo de tareas han dejado de ser
apropiativas[2]).
En este caso, la tarea a usar para la medición
de eventos del procesador es perfctr mediante
su frontend PAPI. Esta herramienta con-
sigue eliminar una gran parte del problema
expuesto anteriormente gracias a una de sus
opciones de conguración Virtual performance
counters support, la cual permite que la medi-
ción se realice únicamente cuando el proceso
con el que se inicio el contador está dentro del
contexto de ejecución. Sin embargo, aunque
esto evita gran parte del ruido introducido al
medir la aplicación, ésta seguirá cometiendo
más fallos en la memoria caché de los que
debería (puesto que código intermedio la
vaciará, necesitándose una nueva carga de
datos a caché cuando vuelva a ejecución el
código), incrementando igualmente el número
de ciclos, instrucciones etc.
314 Evaluación de Prestaciones, Modelado y Simulación
3. Desarrollo
3.1. Sistema propuesto
Una vez vistos los conceptos necesarios para
entender el objetivo de reducción del ruido,
se va a proponer una posible vía de solución
al problema usando las herramientas vistas
anteriormente.
3.1.1. Entorno
Para la realización de las pruebas, y la obten-
ción de datos sucientes como para contrastar
los resultados, se ha creado un entorno de
trabajo en el que cada test se ejecutara en
seis contextos diferentes y se realizarán diez
pruebas para cada uno de estos contextos.
A continuación se explicará el por qué de
estas ejecuciones así como la denición y
diferenciación de cada una.
Cada uno de los tests, deberá ejecutarse
con los cambios al planicador propuestos y
sin estos cambios, con el n de poder observar
los diferentes resultados obtenidos.
La forma de compilación y ejecución de estos
tests no varía puesto que usan las mismas
funciones de PAPI con los mismos eventos. La
diferencia es que mientras en el test normal
se inicializan los contadores y se ejecuta la
función a medir para posteriormente detener
los contadores y obtener los resultados, en
el test que usa RTAI primero se establece el
planicador del test a FIFO, a continuación
se le indica que es una tarea de RTAI y
se detienen las interrupciones externas, y
nalmente se inicializan los contadores y
se ejecuta la función a medir para, al igual
que en el caso anterior, detener luego los
contadores y obtener los resultados.
Tanto los test normales como la imple-
mentación con RTAI se ejecutará en los sigu-
ientes contextos de ejecución:
• Manteniendo el procesador desocupado,
estando tan solo los procesos de sistema
que se ejecutan en segundo plano y algún
que otro proceso casual que haya podido
ser arrancado en el sistema. No obstante
para estas pruebas se asegura siempre
que el uso previo de la CPU no supere el
5%
• Ejecución con la CPU al 100% ocupada.
Para conseguir esto se arranca un proceso
que obtiene un número al azar y calcula
si es primo o no, este algoritmo se ejecuta
en segundo plano ocupando todo el uso
de la CPU y solo es detenido una vez el
test naliza, mediante kill
• El tercer contexto de ejecución varía con
respecto al segundo en que aunque existe
ruido que afecta al 100% de la CPU, en
este caso es de entrada/salida, es decir,
el algoritmo que genera el ruido en esta
ejecución no es de procesamiento como
el anterior, sino que obtiene un nombre
aleatorio y luego crea un chero con ese
nombre, escribe datos al azar en el mismo
y luego lo borra, para comenzar de nuevo
este proceso. Al igual que en el caso ante-
rior este proceso es detenido mediante la
orden kill cuando naliza la ejecución del
test.
3.1.2. LXRT
En el sistema propuesto es necesario incluir la
explicación del entorno lxrt de RTAI, ya que
será el empleado en este trabajo.
Si bien se vio anteriormente que RTAI per-
mite la ejecución de una tarea por encima de
cualquier proceso del núcleo de linux al ejecu-
tar a todo el núcleo como un proceso de ba-
ja prioridad, se ha de tener en cuenta que el
modelo principal de desarrollo de aplicaciones
para RTAI es el de los módulos del kernel, esto
es, pequeños trozos de código que se insertan
en el núcleo del sistema operativo ejecutándose
directamente en modo kernel.
RTAI fue diseñado con el propósito de que la
programación que se hiciera usando su API
estuviera orientada a la programación de este
tipo de módulos, usados para la construcción
XVI Jornadas de Paralelismo, JP '2005 315
de drivers, comunicación directa con el plani-
cador etc.
El uso de módulos añadiría la ventaja a nues-
tra aplicación de que no serían necesarios cam-
bios de contexto durante la ejecución del pro-
grama, esto es debido a que cuando un pro-
grama que se ejecuta en modo usuario nece-
sita acceder a cualquier periférico, o necesita
ejecutar cualquier orden que provoque una in-
terrupción (como puede ser un acceso de en-
trada/salida a disco
) necesitará entrar en es-
pacio de kernel para realizar dicho acceso.
Esta ventaja podría hacer ver que los módulos
son una alternativa óptima para nuestra solu-
ción, sin embargo, la programación de módulos
bajo linux posee ciertas restricciones[4], entre
las que destacan:
• El manejo de punto otante que se reali-
za, por ejemplo, en un programa escrito
en C, es tratado por el núcleo del sistema
operativo de tal manera que su uso se
hace transparente al programador ya que
es el propio núcleo el encargado de la
reserva y liberación de la FPU (oating
point unit) así como del manejo de los
registros de punto otante necesarios. Sin
embargo, el procesador no trata de forma
nativa al punto otante como si hace
con los valores enteros. De este modo al
programar un módulo para el kernel, no
puedan usarse valores en punto otante
de manera trivial, ya que es necesario
una recodicación del programa a tratar
haciendo que no pueda ejecutarse un test
cualquiera en nuestra implementación.
• Las librerías usadas en la programación
estándar no son válidas en la progra-
mación de módulos. El ejemplo más claro
de esto es que el kernel de linux no esta
linkado con las libc, lo cual hace que en
la programación de módulos no existan
funciones tales como printf, scanf, gets
etc. así como las funciones de la librería
los programas que realizan una entrada/salida
importante son los que menos se ajustan a nuestra
solución debido principalmente a estos cambios de
contexto aquí nombrados
math.h. Por este motivo un programa
que se quiera ejecutar como módulo no
podrá usar ninguna librería del exterior
salvo que se desee enlazar esta librería
de forma estática con los riesgos que
esto supone (en el espacio de kernel no
hay protección de datos, por lo que un
desbordamiento de pila o una violación
de segmento pueden comprometer la
estabilidad del sistema).
• En la programación modo kernel, el
tamaño de pila que va a ser usado debe
ser denido y limitado, y no suele ser ex-
cesivamente grande ya que la memoria de
la que dispone el núcleo es baja en com-
paración con la memoria disponible en el
sistema entero. Esto hace que en modo
kernel no se pueda trabajar con matrices
grandes ni una elevada cantidad de datos,
haciendo que muchos tests queden fuera
de nuestra implementación.
Los inconvenientes anteriores dicultan
enormemente el trabajo con módulos para
alcanzar una solución al problema planteado.
Es por esto que surge la idea de utilizar el
entorno lxrt.
LXRT dispone de un conjunto de funciones
de RTAI que nos permite la programación de
tareas en tiempo real sin necesidad de que és-
tas sean ejecutadas en modo kernel, gracias a
esto se pueden aprovechar las ventajas que nos
brinda RTAI sin tener ninguno de los inconve-
nientes de la programación de módulos citados
anteriormente.
Las primitivas de lxrt que van a ser usada en
la tarea propuesta son principalmente:
rt_task_init() que crea una tarea en tiempo
real y la guarda en una estructura de tipo
RT_TASK denida previamente.
rt_make_hard_real_time() que activa la
planicación en tiempo real para una
tarea que está fuera del espacio kernel.
rt_global_sti() esta función usa la instruc-
ción sti de ensamblador que establece a 1
316 Evaluación de Prestaciones, Modelado y Simulación
el registro de inhabilitación de interrup-
ciones, haciendo que las interrupciones se
queden deshabilitadas hasta la ejecución
de rt_global_cli().
rt_global_cli() habilita de nuevo las inter-
rupciones.
3.1.3. Perfctr y PAPI
PAPI no es más que una interfaz a la herra-
mienta de medición de eventos perfctr, con lo
cual en esta sección lo único que se debe saber
de perfctr es que el parche aplicado al ker-
nel de nuestra solución fue el del perfctr-2.6.x
para kernel 2.6.8.1, con la opción de Virtual
performance counters support activada. En el
sistema en el que se realizarán las pruebas ba-
jo una planicación normal (para cada test se
ejecutarán dos pruebas, una bajo condiciones
de planicación FIFO usando las primitivas de
RTAI vistas anteriormente y otra bajo la plan-
icación estándar de linux, sin primitivas de
tiempo real ni del API del kernel de linux),
el parche es también del perfctr-2.6.x, pero en
este caso para un kernel 2.6.11.
Las funciones de PAPI utilizadas en la solu-
ción dada son:
PAPI_start_counters recibe como argumen-
tos un vector que indica que eventos
se van a medir (en este caso son: PA-
PI_TOT_CYC y PAPI_L2_TCM ); y
un valor numérico equivalente al número
de eventos a medir (tres).
PAPI_stop_counters recibe dos argumentos
también, un vector donde se escribirán los
resultados para cada evento y el número
de eventos.
Estas funciones se emplean en ambos entornos,
en el normal y en el que se intenta aislar del
ruido, para que los tests sean ejecutados de
igual manera y den un resultado equivalente.
Por tanto ambas funciones son llamadas
también en el mismo trozo de código, inmedi-
atamente antes de la llamada a la función que
contiene el test a medir, sin que en ninguno de
los dos casos se interponga código entre el ini-
cio y n de los contadores y la función a medir.
3.1.4. Tests
Los tests escogidos para comprobar la validez
de nuestra solución han sido los test de la
SPEC2000, de la sección de tests de valores
enteros (CINT2000 ). En concreto los tests
escogidos son los tests 164.gzip, 176.gcc,
181.mcf, 255.vortex y 300.twolf. Se han
escogido estos tests puesto que forman parte
de una de las referencias más populares en
cuanto a benchmarking y se puede conseguir
información de su funcionamiento evitando
así el tener que entrar en detalles sobre los
tests en este documento.
Todos los tests se han mantenido intactos con
la salvedad de que se ha establecido su nivel
de depuración a 0 para evitar mensajes por
pantalla que puedan dicultar la recogida de
los resultados.
3.1.5. Codicación
La codicación de los tests se ha realizado
con modicaciones en el planicador (test-
preempt) y con el planicador estándar de
linux (test-normal).
Para ello se ha declarado la función
init_func() como extern int init_func() de
tal manera que al compilar el código fuente
con la opción del gcc -c nos crea un objeto
que solo se tendrá que enlazar con el test
deseado tras haber cambiado el nombre de la
función main() de ese test por init_func().
El código de test-preempt.c podría resumirse
como sigue:
Obtener el pid propio
Declarar tarea actual como RT_TASK
Modificar planific y prioridad de tarea
Detener interrupciones
Iniciar contadores PAPI
Ejecutar init_func
Detener contadores PAPI
Habilitar interrupciones
Fin
Algoritmo 1: Ejecución de tests en FIFO
XVI Jornadas de Paralelismo, JP '2005 317
Mientras que test-normal.c solo diere en
que no cambia el planicador:
Iniciar contadores PAPI
Ejecutar init_func
Detener contadores PAPI
Fin
Algoritmo 2: Ejecución habitual de tests.
3.2. Resultados experimentales
En esta sección se muestran los resultados de
tests realizados en un procesador pentium 4 a
1600 Mhz, con una cache de datos de nivel 2
de 256 Kbytes y con 16 Kbytes en la cache de
datos e instrucciones de nivel L1.
Las dos funciones principales que se les va a
aplicar a los tests son la media y el coeciente
de variación, a continuación se va a indicar
cómo se efectúa su cálculo.
• La media de la muestra será la media de
diez ejecuciones de un programa deter-
minado, que será el programa a testear;
si realmente se obtiene una disminución
del ruido esta se verá claramente reeja-
da en una disminución de la media de la
muestra.Porejemplo,enunamediciónde
número de fallos en cache L2, si se con-
sigue obtener un ambiente libre de rui-
dos el número de errores de caché deberá
ser menor que el del mismo programa eje-
cutándose en un contexto normal.
La media se realizará puesto que es nece-
saria para el cálculo del coeciente de
variación
• El coeciente de variación nos muestra la
dispersióndelosdatosobtenidos.Paraun
ambiente libre de ruidos se ha de obte-
nerunadispersiónmenor,sibienestadis-
persiónnollegaráadisminuirsecompleta-
mentepuestoqueenelresultadoobtenido
por el test inuye tanto el estado inicial
de las caches de nivel 1 y 2, el estado de
la memoria, cambios de contexto (modo
usuario/modo kernel en las operaciones
deentrada/salida)etc.siquedeberáenla
mayoría de los casos tener una reducción
notable debido a que el entorno inuirá
menosenlaejecución.Estecoecientenos
viene dado por la ecuación
CV =
Sx
x
donde x es la media de la muestra, y Sx
esladesviacióntípicadadaporlafórmula
Sx =



1
n
n

i=1
(xi − x)2
donde xi eseldatodelamedidaparauna
determinada ejecución.
3.2.1. Coeciente de variación
Las medidas anteriores han sido tomadas
para analizar los resultados desde el punto de
vista de los coecientes de variación de dichas
medidas. Es decir, cómo varían estas medidas
en distintos ambientes de ejecución. A contin-
uación se presentan, en porcentaje, la reduc-
ción de dichos coecientes de variación, en un
sistema de ejecución normal y con la modi-
cación del planicador realizada, relacionados
entre sí. Por ejemplo, la primera la muestra
una reducción de las variaciones del número
de ciclos en las distintas muestras tomadas del
996% al tomarlas con el sistema propuesto,
cuando se incorpora ruido de procesamiento,
y una reducción del 23% cuando se incorpo-
ra ruido de entrada/salida. Del mismo modo
se muestran los resultados obtenidos para el
número total de fallos de cache en el nivel L2.
PAPI_TOT_CYC R. Proc. R. E/S
gzip 996% 23%
twolf 55% 232%
mcf 76% 252%
vortex 60% 36%
gcc 27% 45%
PAPI_L2_TCM R. Proc. R. E/S
gzip 2895% 249%
twolf 24% 292%
mcf 75% 283%
vortex 52% 24%
gcc 2% 32%
318 Evaluación de Prestaciones, Modelado y Simulación
A pesar de haber realizado el muestreo sobre
un número no muy elevado de tests, los
resultados obtenidos son sucientes como
para poder sacar algunas conclusiones sobre
la tarea que se ha llevado a cabo.
En algunos tests, como el vortex o el gcc,
la mejora producida es bastante aceptable y
estable, no presentando picos de mejora en
ninguna de las medidas; en ambos tests se
nota una mayor mejora especialmente cuando
existe ruido de entrada/salida para el gcc y
ruido de procesamiento para el vortex.
Sin embargo en los demás tests la mejora se
incrementa cuando existe algún tipo de ruido
a un nivel mucho mayor; en el caso de los
tests mcf y twolf se observa un incremento de
mejora de hasta del 283% para los fallos en
L2 del test mcf y un valor muy similar para
los del test twolf, obteniendo ambos tests su
mayor mejora cuando el sistema esta ocupado
con tareas de entrada/salida (ya que esta
mejor afecta tanto a los ciclos de reloj como a
los fallos de caché L2).
En el test gzip se obtiene la mayor mejora,
llegando a un 2.895% en los accesos a L2 y a
un 996% cuando se carga completamente la
CPU. Los resultados del test gzip son los más
vulnerables a la existencia de tareas ejecután-
dose en segundo plano en el procesador.
4. Conclusión
Observando los datos desde un punto de
vista global, se pueden sacar las conclusiones
de que se ha conseguido mejorar la precisión
de las medidas de forma muy notable. El sis-
tema propuesto podría dar buenos resultados
en un servidor de mediciones no dedicado, ya
que distintos tests podrían mandarse a la CPU
al mismo tiempo y no interferirían entre sí.
4.1. Trabajo futuro
Como se ha dicho anteriormente, existen
numerosas variables que afectan a la ejecución
de un programa en un sistema monoproce-
sador, una posible mejora para este sistema
experimental es el de controlar algunas de
estas variables (por ejemplo: se podría evitar
que los cambios de contexto modo usuario
<->modo kernel desaparecieran tratando
de llevar la aplicación entera al espacio de
kernel, usando alguna herramienta tal como
Linux Kernel Mode, que nos ofrece un entorno
seguro de ejecución de programas en espacio
kernel sin las restricciones que presenta la
programación de módulos).
Otra mejora es la automatización de las medi-
ciones mediante un modelo cliente/servidor
en el que se reciba el código del test y
automáticamente se le inserten las primitivas
para el cambio de planicador y para la
medición de los eventos dados por el cliente,
y los resultados sean enviados a través de la
red de nuevo al cliente.
Referencias
[1] PAPI Documentation team., PA-
PI user guide, 2004, http://
icl.cs.utk.edu/projects/papi/les/ docu-
mentation/PAPI_USER_GUIDE_306.pdf
[2] Robert M. Love, Introducing the 2.6 Ker-
nel, 2003, http://www.linuxjournal.com/
node/6530/print.
[3] Paolo Mantegazza E. Bianchi L.
Dozio Mike Angelo David Beal,
RTAI programming guide 1.0, 2000,
www.aero.polimi.it/ rtai/documentation/
reference/rtai_prog_guide.pdf.
[4] Robert Love, Linux Kernel Development,
2003, Sams Publishing.
XVI Jornadas de Paralelismo, JP '2005 319
Modelado Analítico Automático del Comportamiento de la Caché
para Códigos con Indirecciones*
Diego Andrade,Basilio B. Fraguela y Ramón Doallo
Departamento de Electrónica e Sistemas
Universidade da Coruña, Campus de Elviña
E-15071 A Coruña (España)
{dcanosa,basilio,doallo}@udc.es
Resumen
El mayor crecimiento de la velocidad de los
procesadores con respecto a la de los buses y
memorias, ha dado lugar a un importante cuel-
lo de botella en los procesadores actuales. Así,
el rendimiento de las jerarquías de memoria,
en las cuales las cachés juegan un papel impor-
tante, es crítico en los sistemas actuales. De-
safortunadamente, el comportamiento de las
cachés es muy inestable y difícil de predecir.
Esto es especialmente cierto en presencia de
patrones de acceso irregulares, los cuales ex-
hiben poca localidad. Tales patrones son muy
comunes por ejemplo en aplicaciones cientí-
cas en las cuales el almacenamiento comprim-
ido de matrices dispersas da lugar a indirec-
ciones. Sin embargo, el comportamiento de la
caché en presencia de patrones de acceso ir-
regulares no ha sido estudiado ampliamente.
En este artículo presentamos una técnica de
modelado analítico sistemático que permite
analizar automáticamente el comportamiento
de la caché para códigos con patrones de ac-
ceso irregulares debido al uso de indirecciones.
Nuestro modelo genera predicciones muy ex-
actas a pesar de las irregularidades y tiene
necesidades computacionales muy bajas.
*Este trabajo ha sido nanciado por el Ministe-
rio de Educación y Ciencia de España bajo contrato
TIN2004-07797-C02-02, y por la Xunta de Galicia ba-
jo contrato PGIDIT03-TIC10502PR.
1. Introducción
El comportamiento de la caché juega un pa-
pel crucial en el rendimiento de los computa-
dores actuales, dado que el cuello de botella
que supone la lentitud de la memoria crece
cada año. El rendimiento de la caché es difí-
cil de predecir y analizar, y depende de mu-
chos parámetros [7]. La simulacion basada
en trazas [8] y el proling con contadores
hardware [1] proporcionan estimaciones bas-
tante exactas; pero tienen necesidades com-
putacionales relativamente grandes, dan poca
información sobre las razones del compor-
tamiento observado, y, en el caso de los conta-
dores hadware, están limitados a aquellas ar-
quitecturas en las que están presentes. Por otra
parte, los modelos analíticos pueden ayudar
a explicar este comportamiento y con la su-
ciente rapidez como para poder ser usados
en un compilador real. En los últimos años
han aparecido modelos analíticos automatiz-
ables, precisos y rápidos capaces de analizar
programas reales con patrones de acceso regu-
lares [9, 5]. Sin embargo, se ha prestado poca
atención al análisis de códigos con patrones de
acceso irregulares, a pesar de que aparecen en
muchas aplicaciones. Aunque se han propues-
to estrategias de modelado ad-hoc para esta
clase de códigos [4], hasta el momento no exis-
tía ninguna estrategia de análisis automatiza-
ble razonablemente precisa.
En este artículo extendemos el modelo PME
(ecuaciones probabilísticas de fallos) [5], que
estaba restringido a código con patrones de
acceso regulares, de manera que también pue-
da analizar automáticamente códigos con in-
direcciones. Nuestro modelado considera indi-
recciones en las cuales todos los elementos del
array referenciados a través de indirecciones
tienen la mima probabilidad de ser accedidos,
es decir, donde el acceso irregular está uni-
formemente distribuido sobre el array referen-
ciado. La naturaleza modular del modelo PME
facilita su extensión, y su naturaleza proba-
bilística lo dota de las herramientas adecuadas
para el modelado de códigos con patrones de
acceso irregulares.
El resto del artículo está organizado de
la siguiente manera. En la siguiente sección
incluimos una breve introducción al mode-
lo PME. Después, en la sección 3, describi-
mos nuestra extensión detallando su ambito de
aplicación y los cambios que han producido en
el modelo. En la sección 4 validamos nuestro
modelo usando tres códigos típicos que con-
tienen indirecciones. Finalmente, dedicamos la
sección 5 a las conclusiones.
2. El modelo PME
Según el modelo PME [5] hay dos clases
de fallos. Los fallos intrínsicos, tienen lugar la
primera vez que se accede una línea, ya que
las líneas se cargan en la caché bajo deman-
da. Los fallos por interferencia, tienen lugar
cuando una línea que ha sido accedida previ-
amente no se encuentra ya en la caché cuan-
do se produce un nuevo acceso a ella. En una
caché asociativa de k vías, esto sucede cuan-
do k o más de las líneas accedidas entre dos
accesos consecutivos a una misma línea caché
están mapeadas conjunto de la caché donde se
encuentra ubicada ésta.
El modelo PME estima el número de fal-
los generados por una referencia mediante una
fórmula que incluye el número de líneas difer-
entes que accede (fallos intrínsecos), el número
de resusos de línea que genera y la probabili-
dad de interferencia para tales accesos (fallos
por interferencia). El cálculo de esta proba-
bilidad conlleva estimar la región de memoria
accedida entre dos accesos consecutivos a la
misma línea, y el mapeado de esta región so-
DO I0 =1, N0
DO I1 =1, N1
...
DO IZ =1, NZ
...
A(fA1(IA1),. . ., fAj(B(fB1(IB1))), . . .)
...
END DO
...
END DO
END DO
Figura 1: Bucles anidados con estructuras accedi-
das mediante indirecciones.
bre la caché. La probabilidad de fallo será igual
a la fracción de conjuntos que reciben k o más
líneas.
Normalmente, una línea dada es reusada con
diferentes distancias de reuso, es decir, difer-
ente porciones de código son ejecutadas entre
diferentes reusos. De este modo, las PME con-
sideran el número de reusos para cada distan-
cia de reuso y su probabilidad de fallo aso-
ciada. Los accesos regulares analizados en [5]
permitían una estructura relativamente simple
para las PME, debido a que en esta situación
cada nivel de anidamento que contiene una
referencia da lugar a una distancia de reuso
diferente. Esta es la razón por la que el mod-
elo PME comienza con el análisis del compor-
tamiento de una referencia en el nivel más in-
terno y luego continua hacia los niveles más ex-
ternos; añadiendo recursivamente nuevos tér-
minos al sumatorio de distancias de reuso para
las líneas afectadas por la referencia.
3. Extensión del Modelo PME para
Considerar Indirecciones
La gura 1 muestra el ámbito de aplicación
de nuestro modelo una vez extendido. Se trata
de un conjunto de bucles normalizados perfec-
ta o no perfectamente anidados, en los cuales
el número de iteraciones de cada bucle debe
ser el mismo en cada ejecución. Los índices
de las referencias son funciones anes fi o de
las variables que controlan los bucles Ii o de
valores leidos de arrays. Llamamos array de
322 Evaluación de Prestaciones, Modelado y Simulación
indirección o array índice a aquellos cuyos val-
ores son usados para indexar otro array, al cual
llamamos array base de la indirección. Los ar-
rays índice pueden ser además indexados por
otros arrays, lo cual da lugar a varios niveles
de indirección. En los códigos considerados en
este trabajo la probabilidad de que un com-
ponente del array base de una indirección sea
accedido está distribuida uniformemente. Esto
quiere decir que todos tienen la misma proba-
bilidad de ser accedidos.
En cuanto al hardware, el modelo PME con-
sidera cachés asociativas por conjuntos con un
tamaño total, tamaño de línea y asociatividad
arbitrarios y con política de reemplazo LRU,
lo cual constituye la situación más común.
El modelo PME genera una fórmula que es-
tima el número de fallos para cada referencia
R y nivel de anidamiento i, Fi(R, RegInput).
Esta fórmula depende de RegInput, la región
accedida desde el último acceso a una línea
dada de la estructura de datos cuando em-
pieza la ejecución del bucle i. La construc-
ción de Fi depende de si la variable de con-
trol para el bucle i,Ii, es usada en los índices
del array índice usados en la referencia o no.
Cuando Ii no aparece en R, o sólo aparece en
sus índices anes, el patrón de acceso de R
es regular con respecto al bucle i, por tanto la
PME para este bucle se construye como en [5].
Si, por el contrario, Ii participa en el indexa-
do de un array de índice en R entonces R es
irregular con respecto al bucle i. El modela-
do del comportamiento de patrones de acce-
so irregulares requiere nuevos tipos de PME.
Hemos identicado dos tipos de PME irreg-
ulares considerando accesos con distribución
uniforme. Las PME para accesos irregulares
ordenados modelan la situación en la que los
accesos generados por la indirección son orde-
nados, es decir, los valores leidos desde el array
de índices son monot'onicamente crecientes o
decrecientes. Cuando esta condición no se pro-
duce, o simplemente no tenemos información
sobre los valores de los índices, se aplica un
nuevo tipo de PME para valores no ordena-
dos. A continuación explicamos los tres tipos
de PME.
3.1. PME para Accesos Regulares
Si la variable Ii asociada al bucle i no in-
dexa ninguna estructura que sea usada en el
indexado de un array base A de la referencia
estudiada R, la PME para esta referencia y
nivel de anidamiento viene dada por
Fi(R, RegInput) = LRiFi+1(R, RegInput)+
(Ni − LRi)Fi+1(R, Regi(A, 1)) ,
(1)
donde Ni es el número de iteraciones del bu-
cle en el nivel de anidamiento i, y LRi es el
número de iteraciones en las cuales no existe
reuso posible para las líneas referenciadas por
R. Regi(A, j) representa la región de memoria
accedida durante j iteraciones del bucle en el
nivel de anidamiento i que puede interferir con
la estructura de datos A.
La formula calcula el número total de fal-
los para una referencia dada R en el nivel de
anidamiento i, como la suma de dos valores.
La primera es el número de fallos produci-
dos por las LRi iteraciones en las cuales no
puede haber reuso en este bucle. El segundo
valor corresponde a las iteraciones en las cuales
puede haber reuso con respecto a la iteración
anterior, y por eso depende de las regiones de
memoria accedidas durante una iteración del
bucle.
El número de iteraciones del bucle i que no
pueden explotar ni la localidad espacial ni la
temporal puede ser calculado como
LRi = 1 +
—
Ni − 1
max{Ls/SRi, 1}


, (2)
donde SRi es el desplazamiento constante que
la referencia R tiene con respecto al bucle i,
dado que o Ii no indexa la referencia R, o el
índice que estamos considerando es una fun-
ción afín de Ii. En el primer caso, trivialmente
SRi = 0. En el segundo caso, SRi = αAj dAj ,
donde j es la dimensión cuyo índice depende
de Ii; αAj es el escalar que multiplica a Ii en la
función afín, y dAj es el tamaño de la j-ésima
dimensión del array A.
Denimos GRi = Ni
LRi
como el número
medio de iteraciones del bucle i que accede a
XVI Jornadas de Paralelismo, JP '2005 323
cada uno de los LRi conjuntos de datos difer-
ente que referencia R con respecto a este bucle.
3.2. PME para un Acceso Irregular Orde-
nado
Cuando Ii indexa alguno de los arrays de
índices de una indirección, el patrón de acce-
sos de nuestra referencia R es irregular con
respecto al bucle i. La razón es que la posición
accedida por R no va a depender directamente
de i, sino del valor leído de el array de índices
que Ii indexa directamente o a través de más
niveles de indirección.
La distribución de los valores leidos del ar-
ray de índices sobre la dimensión del array
base que indexan determina los accesos, los
posibles reusos, y por tanto la PME que mod-
ela la interacción entre la caché y la referen-
cia. En nuestro modelado asumimos que esta
distribución es uniforme, es decir, todos los el-
emento del array base tienen la misma proba-
bilidad de ser accedidos. Esta probabilidad es
pi = 1/M, donde M es el tamaño de la dimen-
sión del array base indexada por la indirección.
Hemos encontrados dos clases de patrones
de acceso irregulares dependiendo de si los val-
ores del array de índices considerado están or-
denados o no. Cuando están ordenados, la se-
cuencia de accesos producida por la indirec-
ción puede ser caracterizada como monotoni-
camente creciente o decreciente. En este caso,
los reusos en el bucle considerado i pueden ten-
er lugar únicamente con respecto a la línea ref-
erenciada en la iteración inmediatamente an-
terior. Podemos utilizar esta información para
derivar una PME mucho más exacta para ac-
cesos irregulares ordenados.
Fi(R, RegInput) = diffLinesFi+1(R, RegInput)+
(Ni − diffLines)Fi+1(R, Regi(A, 1)) ,
(3)
donde diLines es el número medio de líneas
diferentes del array base que han sido acce-
didas.Se estima como diffLines = plineLRi
donde pline = 1 − (1 − pi)GRi es la probabili-
dad de acceder una línea de este array en este
nivel de anidamiento. Tanto LRi como GRi se
denen tal y como se describe en la sección 3.1.
La ecuación (3) reeja el hecho de que en
esas diLines iteraciones accedemos a líneas
que no han sido accedidas en un acceso ante-
rior de este nivel del bucle, la probabilidad de
fallo depende de la región del nivel más exter-
no. Sin embargo, en los restante accesos, existe
reuso y necesariamente con respecto al acceso
anterior.
3.3. PME para Accesos Irregulares No Or-
denados
Cuando los índices de indirección no son or-
denados, o no tenemos información sobre su
ordenamiento, el último acceso de una referen-
cia a una línea dada en el nivel de anidamien-
to considerado i puede haber sucedido hace
un número indeterminado de iteraciones. El
número de iteraciones del bucle entre dos ac-
cesos a la misma línea por una referencia no
puede ser estimando de forma segura porque
los accesos a los elementos de una línea dada
tienen lugar con una determinada probabili-
dad en cada iteración de ese bucle. Además,
se debe seguir una aproximación probabilística
para obtener este valor, el cual es la distancia
de reuso en el bucle. De este modo, la prob-
abilidad de que el último acceso haya sucedi-
do hace 1, 2. . . iteraciones debe ser ponderada.
Denimos el reuso ponderado para la referen-
cia R en la j-ésima iteración consecutiva del
bucle i,WRi(R, RegInput, j), con el proposi-
to de representar los diferentes posibles reusos
y su probabilidad asociada, ponderada con la
probabilidad de que tengan lugar. En esta ex-
presión, RegInput representa la región accedi-
da desde la última referencia a una línea dada
cuando comienza la ejecución del bucle, igual
que en las fórmulas anteriores. El reuso pon-
derado se calcula como,
WRi(R, RegInput, j) = (1 − pLs )j−1
Fi+1(R, RegInput ∪ Regi(A, j − 1))+
j−1
X
k=1
pLs (1 − pLs )k−1
Fi+1(R, Regi(A, k)) ,
(4)
donde pLs = 1 − (1 − pi)GRi calcula la prob-
abilidad de que una línea dada del array base
324 Evaluación de Prestaciones, Modelado y Simulación
que la referencia R puede potencialmente ac-
ceder sea efectivamente accedida durante una
iteración del bucle en el nivel de anidamiento
i. La probabilidad pi es denida tal y como lo
hicimos en la sección 3.2.
El primer término en (4) considera el caso
de que la línea no ha sido accedida en algu-
na de las anteriores j − 1 iteraciones. En este
caso, la región RegInput que podría generar
interferencias con el nuevo acceso a una línea
cuando comienza la ejecución del bucle debe
ser añadida a las regiones accedidas durante
estas j − 1 iteraciones previas del bucle, para
estimar la región de interferencia en su totali-
dad. El segundo término pondera la probabil-
idad de que el último acceso haya tenido lugar
en cada una de las j − 1 iteraciones anteriores
del bucle i.
La PME para un patrón de acceso irregular
no ordenado puede ser expresada como 1
Fi(R, RegInput) = LRi
GRi
X
j=1
WRi(R, RegInput, j),
(5)
donde LRi y GRi son calculadas y tiene el mis-
mo signicado que en la sección 3.1. En la
PME multiplicamos el número de líneas que
R puede acceder durante la ejecución del bu-
cle i por el sumatorio de los reusos pondera-
dos sobre cada uno de las GRi iteraciones que
pueden reusar cada una de las líneas.
3.4. Cálculo del Número de Fallos
En el bucle más interno i que contiene la
referencia R, la recurrencia en el cálculo de las
PME termina deniendo Fi+1(R, RegInput)
como la probabilidad de fallo asociada a la
región de memoria RegInput. Información so-
bre el calculo de las probabilidades de fallo
asociadas a las regiones de memoria pueden
ser encontradas en [5].
El número de fallos generados por una
referencia R puede ser estimado una vez
1En general, GRi
no debe ser un valor entero. En
este caso denimos Pn
j=1 F (j) =
Pn
j=1 F (j) + (n −

n)F (n)
DO I=1,M
REG=0
DO J=R(I), R(I+1) - 1
REG = REG + A(J) * X(C(J))
ENDDO
D(I)=REG
ENDDO
Figura 2: Producto Matrix Dispersa - Vector
DO I= 1,M
DO K= R(I), R(I+1) - 1
REG0=A(K)
REG1=C(K)
DO J= 1,H
D(I,J)=D(I,J)+REG0*B(REG1,J)
ENDDO
ENDDO
ENDDO
Figura 3: Producto Matrix Dispersa - Matrix Den-
sa (IKJ)
hemos analizados el bucle más externo
de los que contienen la referencia como
F0(R, RegInputextrn). Aquí RegInputextrn rep-
resenta la región de memoria accedida des-
de la ejecución de los anidamientos previos
que acceden la mismas líneas de memoria que
R. Si no existieron esos anidamiento previos,
RegInputextrn será una región de memoria uni-
versal con probabilidad de fallo asociada 1,
queriendo decir que no existe reuso posible.
4. Validación
Nuestra validación la vamos a realizar uti-
lizando tres código de complejidad creciente
que contienen indirecciones derivadas de la
manipulación de matrices dispersas almace-
nadas en formato CRS [2] (Compressed Row
Storage). El primer código es un producto ma-
triz dispersa por vector y se muestra en la gu-
ra 2. El segundo código, que mostramos en la
gura 3, es un producto matriz dispersa por
matriz densa con ordenamiento de bucles IKJ.
XVI Jornadas de Paralelismo, JP '2005 325
1 DO I=2,N+1
RT(I)=0
END DO
2 DO I=1, R(M+1)-1
J=C(I)+2
RT(J)=RT(J)+1
END DO
RT(1)=1
RT(2)=1
3 DO I=3, N+1
RT(I)=RT(I)+RT(I-1)
END DO
→
4 DO I=1, M
DO K=R(I), R(I+1)-1
J=C(K)
P=RT(J)
CT(P)=I
AT(P)=A(K)
RT(J)=P+1
END DO
END DO
Figura 4: Transposición de una matriz dispersa.
Finalmente el código de la gura 4 muestra la
transposición de una matriz dispersa, donde
tanto la matriz original como la transpuesta
son almacenadas en formato CRS. Este código
es particularmente complejo, ya que contiene
cuatro anidamientos de bucle, existen accesos
con varios niveles de indirección e involucra a
muchas más estructuras que los otros dos códi-
gos. Además algunas de las estructuras apare-
cen en varios anidamiento de bucles, por lo
tanto puede haber reusos entre al acceso a una
línea en un anidamiento de bucle y el acceso
en otro anidamiento diferente.
El modelo extendido aún no está integrado
en un compilador, por lo que se aplicó man-
ualmente a los códigos. Sus predicciones se
compararon con los resultados de simulaciones
basadas en trazas realizadas con dineroIII [6]
usando matrices sintéticas con una distribu-
ción uniforme de los elementos no nulos. Se
hicieron aproximadamente 12000 pruebas para
cada código cambiando los tamaños y las di-
recciones base de comienzo de las diferentes
estructuras de datos, la conguración de la
caché y la densidad de la matriz dispersa. Las
tablas 1, 2 y 3 muestran algunos resultados
representativos de la validación para el pro-
ducto matriz dispersa-vector, producto matriz
dispersa - matriz densa IKJ y la trasposición
de una matriz dispersa, respectivamente.
En las tres tablas, las primeras dos columnas
M y N, muestran, respectivamente, el número
de las y de columnas de la matriz disper-
sa involucrada en el código. La columna Nnz
muestra el número de no nulos de la matriz,
y α es el porcentaje de posiciones de la ma-
triz dispersa que contienen no nulos. En la
tabla 2, la columna H muestra el número de
columnas de la matriz densa usada en el pro-
ducto. La conguración caché se describe en
las tablas con Cs, Ls y K, que son el tamaño
de la caché, el tamaño de la línea, y el grado
de asociatividad de la caché, respectivamente.
Los tamaños son medidos como el número de
elementos del array usados en los códigos. La
exactitud del modelo se mide a través de la
métrica ∆MR, el valor absoluto de la diferen-
cia entre al valor predicho y el valor medido
expresado como un porcentaje. El valor máx-
imo de ∆MR en nuestro conjunto de pruebas
fue 1.06% para el primer código, 0.52% para
el segundo código, y 0.5% para el tercero. Los
valores medios fueron 0.0.1%,0.02% y 0.01%
respectivamente.
Las últimas dos columnas de las tablas, Tsim
y Tmod, reejan los correspondientes tiempos
de simulación y de modelado en un sistema
con un procesador AMD K7 a 2.08 GHz en se-
gundos. Los tiempos de modelado son varios
ordenes de magnitud más pequeños que los de
la simulación orientada a traza para el segundo
código, y notablemente menores en el caso de
los otros dos códigos. Esto ocurre incluso a pe-
sar de que Tsim sólo incluye el tiempo emplea-
do en el procesado de la traza y no el tiempo
empleado en su generación.
326 Evaluación de Prestaciones, Modelado y Simulación
Tabla 1: Datos de validación y tiempos para el producto matriz dispersa - vector para varias
conguraciones de caché, tamaños de matrices y densidades de la matriz dispersa diferentes
M N Nnz α Cs Ls K ∆MR Tsim Tmod
34000 56000 880000 0.05 8192 4 2 0.010 1.28 0.14
3370 4100 340000 2.46 32768 16 2 0.001 0.40 0.02
3000 5000 760000 5.06 32768 8 2 0.001 0.99 0.02
23200 88150 776000 0.04 4096 8 1 0.007 1.39 0.09
2300 2320 567300 10.63 65536 8 4 0.002 0.84 0.02
2300 1220 123400 4.39 16384 8 4 0.002 0.15 0.02
1170 5100 740000 12.40 8192 16 2 0.002 0.86 0.01
7000 800000 960000 0.02 4096 8 1 1.055 2.01 0.04
5000 56000 340000 0.12 2048 4 2 0.011 0.45 0.03
2000 69000 210000 0.15 16384 2 4 0.015 0.53 0.02
Tabla 2: Datos de validación y tiempos para el producto matriz dispersa - matriz densa para varias
conguraciones de caché, tamaños de matrices y densidades de la matriz dispersa diferentes
M N Nnz α H Cs Ls K ∆MR Tsim Tmod
3370 410 34000 2.46 6500 32768 16 2 0.089 11.87 0.01
3400 230 77000 9.85 900 32768 4 2 0.077 9.96 0.01
4700 450 85000 4.02 3500 16384 8 1 0.043 10.45 0.01
220 4600 69000 6.81 1000 8192 8 4 0.022 7.97 0.01
23000 24242 56730 0.01 2320 65536 8 4 0.015 13.29 0.02
73000 544 5900 0.015 3800 65536 4 2 0.517 13.37 0.06
6900 100 43000 6.23 500 4096 4 2 0.075 6.51 0.01
2700 850 88000 3.83 2500 16384 8 1 0.023 11.70 0.10
740 2360 33350 1.90 6500 4096 4 2 0.029 9.28 0.01
3450 22150 23300 0.03 1210 1024 2 1 0.112 9.76 0.01
Como vemos, el modelo genera estimaciones
muy exactas con un coste computacional muy
bajo; mucho menor que el tiempo necesario
para la simulación del código.
5. Conclusiones
Este artículo presenta el primer modelo que
permite analizar de forma automática, precisa
y r'apida el comportamiento de la caché ante
códigos con patrones de acceso irregulares de-
bido al uso de indirecciones. Nuestra estrate-
gia extiende el modelo en [5] para consider-
ar indirecciones en las cuales los accesos es-
tán distribuidos uniformemente sobre el array
dereferenciado. Cuando esta condición se pro-
duce, las predicciones de nuestro modelo son
muy exactas a pesar de su bajo coste com-
putacional, como muestra nuestra validación
con códigos de diferentes niveles de compleji-
dad. Cuando los accesos irregulares no están
distribuidos uniformemente, tienden a estar
agrupados en regiones. Por ejemplo, cuando se
procesa una matriz dispersa banda, las indirec-
ciones que genera están distribuidas sólo sobre
los elementos que corresponden a la banda, lo
cual incrementa su localidad. En estos casos,
nuestro modelo también puede ayudar a en-
tender el comportamiento de la caché, pero la
tasa de fallos que predice debe ser considerada
un límite superior más que una estimación ex-
acta. Nuestro grupo está desarrollando actual-
mente PMEs que modelan patrones de acceso
típicos no uniformemente distribuidos.
XVI Jornadas de Paralelismo, JP '2005 327
Tabla 3: Datos de validación y tiempos para la transposición de una matriz dispersa para varias
conguraciones de caché, tamaños de matrices y densidades de la matriz dispersa diferentes
M N Nnz α Cs Ls K ∆MR Tsim Tmod
240 85300 94000 0.45 32768 2 4 0.012 0.98 0.10
470 9500 88000 1.97 32768 8 2 0.023 0.40 0.03
220 560 59000 47.88 65536 8 4 0.200 0.21 0.02
240 80460 335000 1.73 32768 4 2 0.001 2.57 0.12
2250 98150 996600 0.45 65536 8 1 0.002 6.63 0.38
2270 22560 27000 0.05 4096 16 1 0.001 0.13 0.03
450 60460 230000 0.84 2048 4 2 0.001 1.00 0.09
1250 78100 885000 0.91 4096 8 1 0.001 4.74 0.23
1240 72000 44000 0.05 4096 2 4 0.003 0.29 0.08
2400 4460 345000 3.22 4096 4 2 0.004 1.44 0.45
Finalmente, así como el modelo PME origi-
nal está integrado en el compilador Polaris [3],
planeamos implementar nuestra extensión en
esta herramienta o una similar. Esto nos per-
mitirá explotar su exactitud y rapidez para
guiar procesos de optimización.
Referencias
[1] G. Ammons, T. Ball, and J. R. Larus. Ex-
ploiting Hardware Performance Counters
with Flow and Context Sensitive Proling.
In SIGPLAN Conf. on Programming Lan-
guage Design and Implementation, pages
8596, 1997.
[2] R. Barrett, M. Berry, T. F. Chan, J. Dem-
mel, J. M. Donato, Jack Dongarra, V. Ei-
jkhout, R. Pozo, C. Romine, and H. V. der
Vorst. Templates for the Solution of Lin-
ear Systems: Building Blocks for Iterative
Methods. Philadelphia: Society for Indus-
trial and Applied Mathematics., 1994.
[3] W. Blume, R. Doallo, R. Eigenmann,
J. Grout, J. Hoeinger, T. Lawrence,
J. Lee, D. Padua, Y. Paek, B. Pottenger,
L. Rauchwerger, and P. Tu. Parallel Pro-
gramming with Polaris. IEEE Computer,
29(12):7882, 1996.
[4] B. B. Fraguela, R. Doallo, and E. L. Zap-
ata. Modeling Set Associative Caches Be-
havior for Irregular Computations. ACM
Performance Evaluation Review (Proc.
SIGMETRICS/PERFORMANCE'98),
26(1):192201, June 1998.
[5] B. B. Fraguela, R. Doallo, and E. L. Zapa-
ta. Probabilistic Miss Equations: Evaluat-
ing Memory Hierarchy Performance. IEEE
Transactions on Computers, 52(3):321
336, March 2003.
[6] A.R. Lebeck and D.A. Wood. Cache pro-
ling and the SPEC benchmarks: A case
study. IEEE Computer, 27(10):1526, Oct
1994.
[7] O. Temam, C. Fricker, and W. Jalby.
Cache Interference Phenomena. In Proc.
Sigmetrics Conf. on Measurement and
Modeling of Computer Systems, pages 261
271. ACM Press, May 1994.
[8] R.A Uhlig and T.N. Mudge. Trace-Driven
Memory Simulation: A Survey. ACM Com-
puting Surveys, 29(2):128170, June 1997.
[9] X. Vera and J. Xue. Let's Study Whole-
Program Behaviour Analytically. In Proc.
of the 8th Int'l Symposium on High-
Performance Computer Architecture (HP-
CA8), pages 175186, Feb 2002.
328 Evaluación de Prestaciones, Modelado y Simulación
Cálculo del Peor Caso en la Cache de Datos*
L. C. Aparicio, J. Segarra**
, J. L. Villarroel, V. Viñals**
Dpt. Informática e Ingenierı́a de Sistemas, Universidad de Zaragoza.
** HiPEAC NoE (High-Performance Embedded Architectures and Compilers)
{luisapa, jsegarra, jlvilla, victor}@unizar.es
Resumen
El cálculo de una cota del WCET de un pro-
grama es especialmente complicado cuando el
procesador usa memoria cache, por la dificul-
tad de anticipar en compilación los fallos que
van a producirse en ejecución. En este traba-
jo proponemos un algoritmo capaz de calcu-
lar una cota ajustada del número de fallos en
la cache de datos, teniendo en cuenta acce-
sos a direcciones no conocidas en compilación.
Nuestra propuesta supera a los métodos exis-
tentes cuando hay reutilización de estos acce-
sos, ya que, a diferencia de otros, no limita el
habitual comportamiento dinámico de la ca-
che.
1. Introducción
Uno de los principales retos en el estudio de
los sistemas de tiempo real estricto (HRTS)
es el cálculo del peor caso del tiempo de eje-
cución (WCET) o en su defecto una cota su-
perior, pero ajustada del mismo. Ese tiempo
se calcula considerando el camino de ejecución
más costoso. El coste de cada camino depende
del contenido de la cache, que a su vez depen-
de de los caminos ejecutados con anterioridad.
Determinar los bloques presentes en una cache
en todo instante de ejecución permite calcular,
en cada acceso a memoria, si va a producirse
un acierto o un fallo.
Para calcular cotas de peor caso de fa-
llos/aciertos se han propuesto numerosos
*
Este trabajo ha sido subvencionado en parte por
el proyecto “Grupo Consolidado de Investigación” de
la Diputación General de Aragón y por los proyec-
tos TIN2004-07739-C02-01/02 y DIP2003-07986 del
MEC/MCyT de España.
métodos (ver sección 2). Algunos de ellos se
basan en la idea de limitar la dinámica de la
cache para ası́ conocer sus contenidos concre-
tos [7, 9, 10, 12, 13]. Otros métodos toleran el
funcionamiento convencional de la cache, pe-
ro sólo aportan soluciones para casos concre-
tos (e.g. sólo instrucciones, sólo corresponden-
cia directa) y/o para programas que acceden
a sus estructuras de datos de forma limita-
da (e.g. sin punteros, sin vectores de ı́ndices,
etc.) [1, 2, 3, 4, 5, 6, 8, 11, 14, 15, 16].
La mayorı́a de los métodos propuestos has-
ta la fecha se ocupan únicamente de caches de
instrucciones. En este caso el acceso a memo-
ria para buscar la siguiente instrucción puede
conocerse en compilación examinando el grafo
del flujo de control. En cambio, el cálculo en
compilación de las direcciones de los datos es
más complejo. Por ejemplo, si programamos el
acceso a estructuras de datos a través de vec-
tores de ı́ndices o punteros, en general no es
posible conocer en compilación las direcciones
que aparecerán en ejecución. En la figura 1
podemos ver ejemplos de accesos a direccio-
nes de memoria no conocidas en compilación.
Además no es correcto simplemente clasificar
las referencias a direcciones desconocidas co-
mo fallos, puesto que tales referencias alteran
el contenido de las caches. Cualquiera de los
métodos existentes que no limitan la dinámi-
ca de la cache debe renunciar al análisis en
presencia de referencias desconocidas, ya que
ninguno de ellos se ha planteado este proble-
ma.
Nuestra contribución. En este artı́culo
proponemos un algoritmo para obtener, sin
restringir la dinámica de la cache, una cota
a=myarray[indexarray[i]];
. . .
b=myarray[compute_index()];
. . .
while (node->value != searched)
node=node->next;
. . .
Figura 1: Ejemplos de referencias a direcciones de
memoria no conocidas en compilación.
superior ajustada del número de fallos en una
cache separada de datos. La cache puede tener
cualquier asociatividad y el programa puede
presentar direcciones no conocidas en compi-
lación. Utilizando estas ideas, hemos extendi-
do el método Static Cache Simulation [8, 15].
Además, hemos comparado nuestra extensión
con un método de bloqueo de caches sobre Ca-
che Miss Equations [12, 13].
El resto del artı́culo está organizado de la
forma siguiente. En la sección 2 hacemos una
breve revisión de trabajos relacionados. En
la sección 3 describimos nuestro algoritmo de
análisis. En la sección 4 extendemos el método
Static Cache Simulation. Después, analizamos
diversos detalles de nuestra aportación en la
sección 5. En la sección 6 mostramos algunos
resultados experimentales. Por último, en la
sección 7 detallamos las conclusiones de este
trabajo.
2. Trabajos relacionados
Para poder evaluar el impacto de las caches en
el WCET se han propuesto varias técnicas de
análisis de referencias y cálculo de fallos. Pode-
mos dividirlas en dos grupos distintos: restrin-
gir la dinámica de la cache para poder conocer
su contenido en compilación o bien usar méto-
dos para analizar su comportamiento dinámi-
co.
2.1. Métodos restrictivos
Estos métodos se basan en desactivar el me-
canismo de reemplazo de lı́neas, o bien desde
el principio de la ejecución del sistema [7, 9]
o bien durante algunos periodos de la mis-
ma [12, 13]. Utilizando estos métodos se pue-
de anticipar el comportamiento de la cache, ya
que sus lı́neas nunca son expulsadas (o sólo se
expulsan cuando lo permitimos).
2.2. Métodos analı́ticos
Estos métodos analizan el código del progra-
ma para calcular en compilación los fallos que
pueden producirse en la búsqueda de instruc-
ciones y la lectura y escritura de datos.
El método Cycle-level Symbolic Execution
realiza un análisis ciclo a ciclo de la ejecución
del programa en un modelo sencillo de pro-
cesador segmentado con caches separadas. El
análisis de fallos que realiza este método es
muy pesimista [5, 6].
El método Abstract Interpretation usa las
propiedades semánticas de los programas para
anticipar el comportamiento de la cache, pero
se centra en caches de instrucciones y lo hace
en base a referencias, no a accesos concretos [1,
2, 3].
El método Static Cache Simulation consis-
te en realizar un estudio del grafo de flujo de
control del código, analizando los contenidos
de la cache [8, 15]. De esta forma es capaz de
ofrecer una clasificación en fallos o aciertos de
las referencias a direcciones conocidas en com-
pilación. En caches de datos, los autores in-
dican cómo calcular accesos a vectores dentro
de bucles analizando sus iteraciones y calcu-
lando de forma agregada el máximo número
de fallos [15].
El método Cache Miss Equations (CMEs)
fue desarrollado originalmente para anticipar
el funcionamiento de la cache en programas
numéricos [4]. Su desventaja es que sólo es
capaz de analizar bucles perfectamente anida-
dos y con un número de iteraciones conocido
(i.e. no puede analizar estructuras de control
condicionales ni bucles while). Partiendo de
este método se han propuesto varias mejoras
para poder utilizarlo sobre programas comple-
tos [11, 14, 16].
330 Evaluación de Prestaciones, Modelado y Simulación
En un acceso a una lı́nea desconocida:
#1 asociar una etiqueta de lı́nea descono-
cida (label)
#2 si label ya está en cache
contar acceso como acierto
sino
contar acceso como fallo
para todo conjunto donde label pue-
da residir, reemplazar por label la
lı́nea menos recientemente usada
#3 actualizar la lista LRU
Figura 2: Algoritmo para el acceso a una lı́nea de
memoria no conocida asumiendo reemplazo LRU.
for (i=0;i<=100;i++) {
a=b[c[i]]; //una label_b_i por iter.
*p=a+d[i]; //label_*p para todas it.
b[c[i]]=foo(p); //reuso label_b_i
};
Figura 3: Ejemplo de generación de etiquetas en
un bucle que explota la localidad temporal. Supo-
nemos desconocido el valor del puntero p. En cada
iteración hay 3 accesos a direcciones desconocidas:
leer y escribir b[c[i]] (la dirección cambia en cada
iteración y también la etiqueta) y leer la posición
apuntada por p (la misma dirección todas las ite-
raciones).
3. Algoritmo para accesos a direc-
ciones no conocidas en compila-
ción
Los conceptos básicos de nuestra propuesta
pueden verse en el algoritmo de la figura 2.
Este algoritmo refleja el peor caso al acceder
a una dirección de memoria no conocida en
compilación. Asignamos una etiqueta label pa-
ra ese acceso y comprobamos si podemos ase-
gurar que se encuentra en cache. Si es ası́ po-
demos actuar siguiendo la polı́tica LRU, pero
en caso contrario debemos asumir el peor ca-
so: el reemplazo de todas las lı́neas que puedan
ser potencialmente reemplazadas.
La generación de etiquetas debe hacerse ex-
plotando la localidad, de forma que pueda con-
tabilizarse como acierto el mayor número po-
sible de referencias, como muestra la figura 3.
Si al aplicar el algoritmo de reemplazo se ex-
pulsa una label, es necesario invalidarla en to-
dos los conjuntos donde aparezca, puesto que
ya no podemos garantizar que se encuentre en
cache. En caso contrario (no expulsión) la label
envejece siguiendo la polı́tica LRU.
Esta propuesta realiza un análisis acceso por
acceso. Esto implica que si tenemos una refe-
rencia a memoria en un código que se ejecuta
n veces, vamos a ser capaces de caracterizar
cada uno de esos n accesos por separado. Esto
nos proporciona una mayor capacidad de de-
talle que los métodos que dan una clasificación
por instrucción y no por acceso efectivo.
Podemos ver un ejemplo de la aplicación de
estos algoritmos en las figura 4.
En la siguiente sección se detalla cómo inte-
grar el tratamiento de referencias desconocidas
en el marco Static Cache Simulation.
4. Extensión de Static Cache Simu-
lation
Para caches de instrucciones, este método con-
siste en dividir un programa en bloques bási-
cos1
y después unirlos para construir el grafo
de flujo de control. A la secuencia de varios
bloques básicos consecutivos atravesados al re-
correr un grafo de flujo de control se le llama
camino.
El estado abstracto de cache (ACS) es el
conjunto de labels (sección 3) y lı́neas concre-
tas que pueden estar potencialmente en cache
antes de cada acceso a memoria. Nótese que
vamos a trabajar con referencias a lı́neas de
memoria, no a variables concretas2
. Los ACS
se construyen utilizando las ecuaciones expli-
cadas más adelante. Con ellos se puede deter-
minar el estado de cache antes y después del
acceso a cada lı́nea de memoria l, y actualizar
esos estados mientras haya cambios, es decir,
hasta que el sistema converja.
Una vez conocidos los ACS, pueden hacerse
las siguientes categorizaciones: estado de cache
1
Un bloque básico es una secuencia de instruccio-
nes consecutivas que comienza con una etiqueta o una
instrucción destino de salto o que viene precedida por
un salto, y acaba con una instrucción de salto o va se-
guida de una instrucción destino de salto.
2
Referencias a direcciones distintas (pero cerca-
nas) pueden acceder a la misma lı́nea de memoria.
XVI Jornadas de Paralelismo, JP '2005 331
addr9
Maps into
Control Flow
Data Ref.
Control Flow
Cache set 0
Cache set 1
Cache set 2
Cache set 3
addr5
addr6
addr9
Input
Output
addr0
addr3
addr0
addr1
addr2
addr4
addr7
addr4
addr5
addr2
addr7
addr6
addr3
MRU LRU
(a)
labelA
addr5
addr6
labelA
addr0
addr3
addr4
addr1
addr2
addr7
labelA
addr5
addr6
labelA
labelA
addr7
addr4
(b)
addr9
addr0
labelA
labelA
labelA
addr1
addr2
addr3
labelA
labelA
labelA
labelA
addr3
addr2
labelA
addr0
addr9
(c)
addr9
addr0
∅
addr2
labelA
labelA
addr2
addr0
addr9
labelA
addr1
addr1
addr3 labelA
addr3 ∅
∅
(d)
addr0
addr2
labelA
labelA
addr2
addr0
labelA
addr1
addr1
addr3 labelA
labelA
addr3
labelA
labelA
labelA
labelA
(e)
Figura 4: Algoritmos de análisis de referencias desconocidas en compilación aplicados a caches asociativas.
(a) Referencia conocida sobre referencias conocidas, (b) referencia desconocida sobre referencias conocidas,
(c) referencia conocida sobre referencias desconocidas sin expulsión, (d) referencia conocida sobre referencias
desconocidas con expulsión, (e) acierto de referencia desconocida.
lineal (en ausencia de bucles), estado de cache
dominante (lı́neas en cache seguras antes de l)
y estado de cache post-dominante (lı́neas en
cache seguras después de l). Estas categoriza-
ciones son la base para la categorización final
de peor caso [8].
En las caches de instrucciones, al buscar una
lı́nea concreta del cuerpo de un bucle (sin es-
tructuras de control en su interior) podemos
tener dos estados de cache: uno si nos encon-
tramos en la primera iteración del bucle, y otro
si estamos en cualquier otra iteración. Esto no
es ası́ en caches de datos, ya que los datos ac-
cedidos pueden ser distintos en cada iteración,
con lo que el estado de la cache también serı́a
distinto. En este caso sólo puede converger de-
senrollando conceptualmente los bucles (que
deben estar acotados).
La extensión a cache de datos de Static Ca-
che Simulations no contempla esta posibili-
dad [15], y se limita a calcular el número de
aciertos y fallos en conjunto para cada bucle,
y proporciona un único estado de cache a su
salida, sea cual sea la iteración de salida. En
cambio nuestra propuesta proporciona una ca-
racterización detallada (acierto o fallo) por ac-
ceso, tanto si la referencia es conocida en com-
pilación como si no lo es, dado que se analizan
todas las iteraciones del bucle. Al hacer es-
te recorrido detallado, también se proporciona
un estado de salida mucho más preciso, depen-
diente del número de iteraciones realizadas.
4.1. Caches de datos de correspondencia
directa
Definimos in(p, l) y out(p, l) como los estados
de entrada y salida del acceso l dentro del ca-
mino p. Es decir, los contenidos que puede te-
ner la cache antes y después de acceder a l. Las
ecuaciones para construir los ACS para caches
de datos de correspondencia directa se pueden
ver en la figura 5.
332 Evaluación de Prestaciones, Modelado y Simulación
in(p, l) =
8
<
:
∅ if p = firstPath and l = firstRef
S
q≺p out(q, last) if p = firstPath and l = firstRef
out(p, l − 1) if l = firstRef
(1)
defs(p, l) =
j
{addrc} if the accessed address is known
{label0, label1, . . . , labeln−1} if the accessed address is unknown
(2)
confs(p, l) = {l1i ∈ in(p, l) | ∃ l2i ∈ defs(p, l), l1i = l2i} (3)
invalid(p, l) = {li ∈ in(p, l) | ∃ lj ∈ confs(p, l)} (4)
out(p, l) = defs(p, l) ∪ ((in(p, l) \ confs(p, l)) \ invalid(p, l)) (5)
Figura 5: Ecuaciones de construcción del ACS para caches de datos de correspondencia directa. El subı́ndice
de cada referencia representa el número de conjunto que le corresponde.
Ası́, la firstRef lı́nea del camino firstPath
pone los contenidos de cache a ∅ (estado inváli-
do). La firstRef lı́nea de cualquier otro camino
p recibe el estado abstracto de cache como la
unión de los contenidos de cache a la salida de
los caminos q que preceden al camino actual p.
Finalmente, las lı́neas que no son las primeras
de un camino p toman como entrada la sali-
da de la lı́nea anterior del mismo bloque (1).
Una vez conocido el estado de entrada in (el
contenido que puede estar en cache antes de
acceder a l), hemos de calcular la nueva entra-
da (defs) y sus posibles conflictos (confs). La
nueva entrada, o bien es una dirección conoci-
da que debe colocarse en el conjunto c (addrc),
o bien es una dirección desconocida label que
debe colocarse en todos los n conjuntos de ca-
che (label0, label1, . . . , labeln) (2). Un conflic-
to se puede definir como un nuevo acceso l2
que ha de colocarse en una lı́nea ya ocupada
por una referencia existente l1 (3). En caso de
que un conflicto afecte a una label almacenada
previamente, será expulsada. En este caso ya
no podremos garantizar que la lı́nea asociada a
esa label siga en cache. Por lo tanto, deberemos
invalidar todas las lı́neas que contengan una
label igual a la expulsada (4). Siguiendo las
ecuaciones, todas las lı́neas que generan con-
flictos deben ser expulsadas, y reemplazadas
por las nuevas. out(p, l) se obtiene al quitar
las lı́neas conflictivas e invalidadas del conjun-
to de los contenidos anteriores y añadir a este
resultado las nuevas lı́neas (5).
4.2. Caches asociativas LRU
Una cache LRU s-asociativa se puede ver como
s caches de correspondencia directa con des-
plazamiento LRU de sus contenidos. Es decir,
cuando la primera vı́a recibe una nueva entra-
da, le pasa las lı́neas en conflicto a la segunda
vı́a, que a su vez moverá su contenido al si-
guiente, y ası́ hasta la s-ésima vı́a, que descar-
tará su contenido. Podemos ver la descripción
formal de este comportamiento en la figura 6.
Ahora, in(p, l, w) representa las lı́neas que
contiene la vı́a w de la cache (6). Las nue-
vas entradas están representadas en el conjun-
to defs. Ası́, defs en la primera vı́a se calcula
como antes, y las demás reciben las lı́neas en
conflicto de su vı́a anterior (excepto cuando te-
nemos aciertos en vı́as distintas de MRU, que
refrescan contenidos) (7). Las lı́neas en con-
flicto confs se calculan igual que en corres-
pondencia directa (8). Como antes, invalida-
mos (si procede) las lı́neas cuyas etiquetas son
iguales a la expulsada (9). De esta forma po-
demos eliminar referencias a direcciones des-
conocidas cuando no podemos garantizar que
están en cache. Hacemos efectivas las expul-
siones/invalidaciones al calcular out (10).
Nótese que las ecuaciones de construcción
de los ACS para caches de correspondencia di-
recta son un caso particular de las asociativas
donde sólo hay una vı́a. Las completamente
asociativas también son un caso particular de
éstas donde sólo hay un conjunto.
XVI Jornadas de Paralelismo, JP '2005 333
in(p, l, w) =
8
<
:
∅ if p = firstPath and l = firstRef
S
q≺p out(q, last, w) if p = firstPath and l = firstRef
out(p, l − 1, w) if l = firstRef
(6)
defs(p, l, w) =
8
<
:
{addrc} if w = MRU and addr is known
{label0, label1, . . . , labeln−1} if w = MRU and addr is unknown
confs(p, l, w − 1) \ defs(p, l, MRU) if w = MRU
(7)
confs(p, l, w) = {l1i ∈ in(p, l, w) | ∃ l2i ∈ defs(p, l, w), l1i = l2i} (8)
invalid(p, l, w) = {li ∈ in(p, l, w) | ∃ lj ∈ confs(p, l, LRU)} (9)
out(p, l, w) = defs(p, l, w) ∪ ((in(p, l, w) \ confs(p, l, w)) \ invalid(p, l, w)) (10)
Figura 6: Ecuaciones de construcción del ACS para caches de datos s-asociativas. El subı́ndice de cada
referencia representa el número de conjunto que le corresponde.
5. Asociatividad y conocimiento de
las estructuras de datos
Cuando tenemos una referencia a una direc-
ción desconocida, como puede reemplazar a
cualquier lı́nea, debemos asumir que todas
ellas son reemplazadas. En otras palabras, en
general, un acceso a una posición de memoria
desconocida implica expulsar una vı́a comple-
ta. Este hecho hace que la asociatividad de la
cache sea un factor determinante en la cota del
WCET que podamos obtener. Por ejemplo, si
tenemos una cache de correspondencia direc-
ta de 2 MB, cada vez que accedamos a una
dirección desconocida tendremos que conside-
rar los 2 MB completos como expulsados, ya
que esa referencia podrı́a situarse en cualquier
lı́nea. En cambio, en una cache del mismo ta-
maño pero 4-asociativa, sólo 512 KB (la vı́a
más vieja) deberı́an ser considerados como ex-
pulsados ante el mismo acceso, y estarı́a garan-
tizado que los 1,5 MB restantes permanecen
en cache. Ası́, en este caso se puede ver que la
asociatividad de la cache es determinante en
la precisión de la cota del WCET obtenida.
En las ecuaciones anteriores hemos introdu-
cido referencias a direcciones de memoria des-
conocidas como una lista de n labels, siendo
n el número de conjuntos de la cache. Esto
corresponde a un caso general, donde no te-
nemos ningún conocimiento previo sobre las
referencias. Sin embargo, muchas referencias a
direcciones desconocidas están asociadas a es-
Contenido de mem. Conjunto de cache
· · · → 0
a[0], a[1], a[2], a[3] → 1
a[4], a[5], a[6], ? → 2
· · · → 3
Figura 7: Contenidos de memoria y corresponden-
cias de un vector de 7 elementos. Una referencia
desconocida del tipo a[b[i]] sólo necesitarı́a dos eti-
quetas, que se situarı́an en los conjuntos 1 y 2.
tructuras de datos con dirección base, organi-
zación y tamaño conocidos y por lo tanto pue-
den identificarse fácilmente todas las direccio-
nes posibles. Es decir, podemos saber exacta-
mente los conjuntos donde es posible un reem-
plazo3
. Por ejemplo, el acceso a una posición
cualquiera de un vector de tamaño pequeño del
que conocemos su dirección base puede ser si-
tuada en unos pocos conjuntos de cache, como
muestra la figura 7. Esto implica que un análi-
sis basado en la declaración de las estructuras
de datos puede ajustar la cota del WCET.
6. Resultados
Como estudio preliminar hemos analizado
algunos benchmarks muy utilizados en siste-
mas empotrados para comprobar la aplicabi-
3
Asumiendo siempre que los programas son correc-
tos, es decir, que no acceden fuera de las estructuras
supuestamente accedidas.
334 Evaluación de Prestaciones, Modelado y Simulación
Telecomm Desc.
Fix. Point AutoCorrelation NO
Convolutional Encoder NO
Fix. Point Bit Allocation SI
Fix. Point Complex FFT/IFFT SI
Viterbi Decoder SI
Automotive Desc.
Angle-to-Time Conversion NO
FFT: Fast Fourier Transform SI
IFFT: Inverse FFT SI
FIR: Finite Impulse Response NO
Basic Integer and Floating-Point NO
Bit Manipulation NO
Cache “Buster” NO
CAN Reader Algorithm NO
Inverse Discrete Cos. Transform NO
IIR: Infinite Impulse Response NO
Matrix Math NO
Pointer Chasing NO
Pulse-Width Modulation NO
Road Speed Calculation NO
Table Lookup and Interpolation NO
Tooth to Spark NO
Cuadro 1: Referencias desconocidas en bench-
marks para sistemas empotrados (EEMBC).
lidad de nuestra aportación, ya que es difı́cil
conseguir benchmarks HRTS. Puede observar-
se en el cuadro 1 que, dependiendo del campo,
puede no ser muy habitual que los programas
tengan referencias no conocidas en compila-
ción. Aún ası́, ciertos benchmarks sı́ que tienen
este tipo de referencias.
Para evaluar nuestra aportación, hemos
analizado un código sencillo (figura 8) que con-
tiene varias referencias no conocidas en com-
pilación, y hemos comparado los resultados
con un método (CME-CL) de bloqueo de ca-
ches sobre Cache Miss Equations [12, 13]. Este
método encierra las referencias desconocidas
entre operaciones lock y unlock para que no
alteren la cache. En el cuadro 2 mostramos los
resultados obtenidos con ambos métodos. En
ellos se puede ver que, cuando la asociativi-
dad aumenta, nuestro método reduce la esti-
mación del número de fallos, mientras que la
estimación del método CME-CL se mantiene
constante.
Si la cache está fijada, no aprovecha la lo-
calidad temporal de los accesos. Para intentar
aumentar el número de aciertos en regiones fi-
jadas, el método CME-CL puede precargar las
lı́neas de memoria más accedidas en dicha re-
int a[100],c[100],b[100];
for (i=0;i<100;i++)
a[i]=1;
for (i=0;i<100;i++) {
c[i]=b[a[i]]+c[i];
b[a[i]]=0;
};
Figura 8: Ejemplo de análisis con referencias a di-
recciones no conocidas en compilación.
gión, intentando ası́ beneficiarse de la capaci-
dad de la cache. Esto implica que, globalmen-
te, su número de accesos a memoria aumenta
(es el caso de la cache de 512 KB del cuadro 2).
Otra consideración importante es que, an-
te accesos a direcciones no conocidas, la esti-
mación del método CME-CL coincide con los
fallos que se producirán en ejecución. En cam-
bio, nuestro método proporciona una cota su-
perior del peor caso, por lo que en ejecución el
número de fallos puede ser menor.
7. Conclusiones
En este trabajo se ha propuesto un algoritmo
para obtener una cota ajustada de un peor
caso de fallos en caches de datos para códi-
gos con direcciones no conocidas en compila-
ción. Para mostrar su funcionamiento, propo-
nemos una extensión del método Static Ca-
che Simulation [15]. Nuestra propuesta pro-
porciona unos resultados más detallados: ac-
ceso por acceso en vez de agregado de accesos.
Además es capaz de aprovechar información
sobre las estructuras de datos accedidas, redu-
ciendo ası́ la cota del número de fallos. Tam-
bién hemos mostrado que la asociatividad de
la cache es un factor determinante para redu-
cir dicha cota. Por último, hemos comparado
nuestra extensión con otro método existente,
mostrando que cuando hay reutilización de ac-
cesos a direcciones no conocidas en compila-
ción, nuestra propuesta es capaz de aprove-
charlo, ya que no restringe la dinámica de la
cache.
XVI Jornadas de Paralelismo, JP '2005 335
Cache de 256 B Cache de 512 B
Método Asoc. Accesos Fallos Lock+Unlock Accesos Fallos Lock+Unlock
CME-CL 1 600 275 100 + 100 625 322 1 + 1
Ext. SCS 1 600 350 – 600 321 –
CME-CL 2 600 275 100 + 100 625 322 1 + 1
Ext. SCS 2 600 175 – 600 174 –
CME-CL 4 600 275 100 + 100 625 322 1 + 1
Ext. SCS 4 600 175 – 600 174 –
Cuadro 2: Fallos estimados para caches con bloques de 16 B. CME-CL: Cache Miss Equations-
Cache Locking, Ext. SCS: Extensión de Static Cache Simulation. En el método CME-CL, para el
caso de 512 B, se ha precargado la estructura c para poder eliminar instrucciones lock/unlock.
Referencias
[1] P. Cousot and R. Cousot. Abstract interpre-
tation: a unified lattice model for static analy-
sis of programs by construction or approxima-
tion of fixpoints. In Proc. of the ACM Symp.
on Principles of Prog. Languages, pages 238–
252, 1977.
[2] C. Ferdinand and R. Wilhelm. Efficient and
precise cache behavior prediction for real-time
systems. Real-Time Syst., 17(2–3):131–181,
1999.
[3] C. Ferdinand and R. Wilhelm. Fast and effi-
cient cache behavior prediction for real-time
systems. Real-Time Syst., 17(2–3), 1999.
[4] S. Ghosh, M. Martonosi, and S. Malik. Ca-
che miss equations: a compiler framework
for analyzing and tuning memory behavior.
ACM Trans. on Prog. Languages and Sys-
tems, 21(4):703–746, 1999.
[5] T. Lundqvist and P. Stenström. An integra-
ted path and timing analysis method based
on cycle-level symbolic execution. Real-Time
Syst., 17(2–3):183–207, 1999.
[6] T. Lundqvist and P. Stenström. A method
to improve the estimated worst-case perfor-
mance of data caching. In Proc. of the Int.
Conf. on Real-Time Computing Systems and
Applications, page 255, 1999.
[7] A. Martı́, A. Perles, and J. V. Busquets. Sta-
tic use of locking caches in multitask preemp-
tive real-time systems. In Proc. of the IEEE
Real-Time Embedded System Workshop, De-
cember 2001.
[8] F. Müeller. Timing analysis for instruction
caches. Real-Time Syst., 18(2):217–247, May
2000.
[9] I. Puaut. Cache analysis vs static cache loc-
king for schedulability analysis in multitas-
king real-time systems. In Proc. of the Int.
Workshop on WCET Analysis, 2002.
[10] I. Puaut, A. Arnaud, and D. Decotigny. Per-
formance analysis of static cache locking in
multitasking hard real-time systems. Techni-
cal Report 1568, IRISA, October 2003.
[11] H. Ramaprashad, F. Müeller, D. Whalley, and
C. Healy. Bounding worst-case data cache
behavior by analytically deriving cache refe-
rence patterns. In Proc. of the Real-Time
and Embedded Technology and Applications
Symp., pages 148–157, March 2005.
[12] X. Vera, B. Lisper, and J. Xue. Data cache
locking for higher program predictability. In
Proc. of the Int. Conf. on Measurement and
Modeling of Computer Systems, pages 272–
282, June 2003.
[13] X. Vera, B. Lisper, and J. Xue. Data caches in
multitasking hard real-time systems. In Ins-
titute of Electrical and Inc. Electronics En-
gineers, editors, Proc. of Int. Real-Time Sys-
tems Symp., pages 154–166, 2003.
[14] X. Vera and J. Xue. Let’s study whole pro-
gram cache behaviour analytically. In Proc.
of the Int. Symp. on HPCA, February 2002.
[15] R. T. White, F. Müeller, C. A. Healy, D. B.
Whalley, and M. G. Harmon. Timing analysis
for data and wrap-around fill caches. Real-
Time Syst., 17(2–3):209–233, 1999.
[16] J. Xue and X. Vera. Efficient and accura-
te analytical modeling of whole-program da-
ta cache behavior. IEEE Trans. Computers,
53(5):547–566, 2004.
336 Evaluación de Prestaciones, Modelado y Simulación
Tecnologías Grid, Clusters
y Plataformas Distribuidas
                        "  %  ( )   + %  %   -  0 2     
5   %      % 8    : ; <      > @  %   
C E F G H I K L N G F Q R S T V I H S F W S Z S T F ] F ^ S _ a S T T G F d G f h G i I j k S E T S N N S f
m n o q m n o q m n o q o t u q u
v x y v x y v x y v x y
z | } ~ ~ y   ƒ „ … †  z | } ~ ~ y   ƒ „ … †  z | } ~ ~ y   ƒ „ … †  z | } ~ ~ y   ƒ „ … † 
† ˆ   „ ‰ Š ƒ Œ  Ž † …  Š  ‘  ƒ Ž ‘ “ ƒ ” „  „  Œ  Ž † …  Š  ‘  ƒ Ž — ™  Ž Œ  Ž † …  Š  ‘  ƒ Ž  ‰ Š †  † Ž Œ † œ  …   Š  ‘  ƒ Ž
 Ÿ ¡ ¢ £ Ÿ ¤
¥ ¦ § ¨ § © ª © « ¬ ­ ¯ § ± ¦ ² § ¦ ³ © ¶ · ¹ º § ¨ ¦ ³ ¯ § ¹ ¶ ³ ± ¹ ² ¶ »
© § ³ ¶ ¯ § « · ½ ¾ § ­ § ³ · ¿ ¯ « © ¦ ³ © ¶ · ¶ º ¦ ² § ¾ « ³ ± ² ¦ © « ¬ ­
¯ § ³ § © ª § ­ © « ¦ ³ ± § · ¹ ¶ ² ¦ º § ³ ¯ § « · ½ ¾ § ­ § ³ Á ¶ º ª · ¿ »
± ² « © ¦ ³ ² § Ã ª « § ² § ² § © ª ² ³ ¶ ³ Ã ª § § Ä © § ¯ § ­ º ¦ © ¦ ¹ ¦ © « »
¯ ¦ ¯ ¯ § º ¶ ³ ³ « ³ ± § · ¦ ³ © ¶ ­ Á § ­ © « ¶ ­ ¦ º § ³ Å Æ ¶ · ¶ ² § ³ »
¹ ª § ³ ± ¦ ¦ § ³ ± § ¹ ² ¶ È º § · ¦ É º ¦ ³ ± § © ­ ¶ º ¶ ¾ Ë ¦ ³ Ì ² « ¯
³ ª ¹ ¶ ­ § ­ ª ­ ¦ « ­ ± § ² § ³ ¦ ­ ± § ¦ º ± § ² ­ ¦ ± « Á ¦ É ¦ ª ­ Ã ª §
º ¦ ª ³ ¦ È « º « ¯ ¦ ¯ ¯ § § ³ ± ¶ ³ § ­ ± ¶ ² ­ ¶ ³ Ï ¦ ¯ « Ð © ª º ± ¦ ¯ ¶
³ ª « ­ © ¶ ² ¹ ¶ ² ¦ © « ¬ ­ ¾ § ­ § ² ¦ º « Ò ¦ ¯ ¦ Å
Ó ­ § ³ ± § ¦ ² ± Ë © ª º ¶ ³ § ¦ È ¶ ² ¯ ¦ § º ¹ ² ¶ È º § · ¦ ¯ §
º ¦ ² § ¾ « ³ ± ² ¦ © « ¬ ­ ¯ § « · ½ ¾ § ­ § ³ · ¿ ¯ « © ¦ ³ Ö × § ­ ª ­
§ ­ ± ¶ ² ­ ¶ Ì ² « ¯ Å Ø ¦ ² ¦ º ¶ Ã ª § ³ § Ï ¦ ¯ § Ð ­ « ¯ ¶ ª ­ ¦
¦ ² Ã ª « ± § © ± ª ² ¦ § ­ © ª ¦ ± ² ¶ ­ « Á § º § ³ Ù © ¦ ¹ ¦ Ì ² « ¯ É © ¦ »
¹ ¦ Ì ¦ ± § » ± ¶ » Ì ² « ¯ É © ¦ ¹ ¦ ¯ § · « ¯ ¯ º § Ü ¦ ² § ¯ § ¦ È ³ »
± ² ¦ © © « ¬ ­ ¯ § º ¶ ³ Þ § ² Á « © « ¶ ³ ß § È à Ð ­ ¦ º · § ­ ± § º ¦
© ¦ ¹ ¦ ¯ § ¦ ¹ º « © ¦ © « ¬ ­ Å Ó ­ ¯ « © Ï ¦ ¦ ² Ã ª « ± § © ± ª ² ¦ © ¦ »
¯ ¦ © ¦ ¹ ¦ ¶ á ² § © § ª ­ ¦ ¦ È ³ ± ² ¦ © © « ¬ ­ ¯ § · ¦ à ¶ ² ­ « Á § º
¦ º ¦ © ¶ · ¹ ª ± ¦ © « ¬ ­ Ì ² « ¯ à ¦ º ¦ Á § Ò · ¦ à ¶ ² « ­ ¯ § »
¹ § ­ ¯ § ­ © « ¦ § ­ © ª ¦ ­ ± ¶ ¦ º ¶ ³ ¹ ¦ Ã ª § ± § ³ ³ ¶ á ± Ü ¦ ² §
­ § © § ³ ¦ ² « ¶ ³ ¹ ¦ ² ¦ « ­ ± § ² ¦ © © « ¶ ­ ¦ ² © ¶ ­ § º Ì ² « ¯ Å
Þ § Ï ¦ ¯ § ³ ¦ ² ² ¶ º º ¦ ¯ ¶ ª ­ ¦ ¦ ¹ º « © ¦ © « ¬ ­ ³ ¶ È ² § § ³ ± ¦
¦ ² Ã ª « ± § © ± ª ² ¦ Ã ª § ¹ § ² · « ± § º ¦ ¾ § ³ ± « ¬ ­ ¯ § ¾ ² ª ¹ ¶ ³
¯ § § ¨ § © ª © « ¶ ­ § ³ ¹ ¦ ² ¦ · ¿ ± ² « © ¦ ³ ¯ § ± ² ¦ È ¦ ¨ ¶ ³ ¯ § ² § »
¾ « ³ ± ² ¦ © « ¶ ­ § ³ ¯ § Á ¶ º ã · § ­ § ³ ² ¦ ¯ « ¶ º ¬ ¾ « © ¶ ³ ³ ¶ È ² § § º
º ¦ « ­ á ² ¦ § ³ ± ² ª © ± ª ² ¦ Ì ² « ¯ ¯ § Ó Ì Ó Ó ä å æ Å Ó ³ ± ¦ ¦ ¹ º « »
© ¦ © « ¬ ­ § ³ · ª º ± « ¹ º ¦ ± ¦ á ¶ ² · ¦ à ¹ ª § ¯ § ³ § ² ª ³ ¦ ¯ ¦
¯ § ³ ¯ § © ª ¦ º Ã ª « § ² © ¶ · ¹ ª ± ¦ ¯ ¶ ² © ¶ ­ Á § ­ © « ¶ ­ ¦ º ³ « ­
² § Ã ª « ³ « ± ¶ ³ § ³ ¹ § © « ¦ º § ³ Å
ç è ê
¤ ë ì í î ¢ ï ï ð ñ ¤
¥ ¦ © ¶ · ¹ ª ± ¦ © « ¬ ­ Ì ² « ¯ ³ § § ­ © ª § ­ ± ² ¦ § ­ ª ­ ¹ ª ­ ± ¶
¯ § ¾ ² ¦ ­ § Ä ¹ ¦ ­ ³ « ¬ ­ § « ­ ± ² ¶ ¯ ª © © « ¬ ­ § ­ ½ · È « ± ¶ ³
¯ § ¦ ¹ º « © ¦ © « ¬ ­ · ª à ¯ « Á § ² ³ ¶ ³ Å Ó ­ § ³ ± § ¹ ² ¶ © § ³ ¶ ¯ §
§ Ä ¹ ¦ ­ ³ « ¬ ­ Ï ¦ ­ ³ ª ² ¾ « ¯ ¶ ¯ « Á § ² ³ ¶ ³ · « ¯ ¯ º § Ü ¦ ² § ³
© ¶ · ¶ Ì º ¶ È ª ³ ä ó
æ ô Ì õ ó É Ì õ Ö É Ì õ ö ÷ É ¶ ± ² ¶ ³ È ¦ »
³ ¦ ¯ ¶ ³ § ­ Ì º ¶ È ª ³ Ù Ó × Ì ä Ö æ É ¥ Æ Ì ä ö æ É ¾ ¥ « ± § ä ù æ É
à ¶ ± ² ¶ ³ © ¶ · ¶ ú ­ « © ¶ ² § ä û æ ¶ ü ­ ­ § ² Ì ² « ¯ ä ý æ Å õ ¶ »
¯ ¶ ³ § ³ ± ¶ ³ · « ¯ ¯ º § Ü ¦ ² § ³ § ³ ± ¦ ­ ¶ ² « § ­ ± ¦ ¯ ¶ ³ ¦ ¯ ¦ ²
³ ¶ º ª © « ¶ ­ § ³ ¦ ¹ ² ¶ È º § · ¦ ³ § ³ ¹ § © Ë Ð © ¶ ³ © ¶ · ¶ ¦ º ± ¦
¹ ² ¶ ¯ ª © ± « Á « ¯ ¦ ¯ ¯ § ² § © ª ² ³ ¶ ³ ¶ ¦ ¦ ¹ ² ¶ Á § © Ï ¦ ² ¯ « á § »
² § ­ ± § ³ ± « ¹ ¶ ³ ¯ § ¹ º ¦ ± ¦ á ¶ ² · ¦ ³ © ¶ ­ º ¦ © ² § ¦ © « ¬ ­ ¯ §
³ § ² Á « © « ¶ ³ Ã ª § ¦ È ³ ± ² ¦ « ¾ ¦ ­ ¦ º ª ³ ª ¦ ² « ¶ ¯ § § ³ ± ¦ ³ Å
Ó º ¶ È ¨ § ± « Á ¶ Ð ­ ¦ º ¯ § © ª ¦ º Ã ª « § ² Ì ² « ¯ § ³ ¹ § ² · « »
± « ² © ¶ · ¹ ¦ ² ± « ² ² § © ª ² ³ ¶ ³ ¯ « ± ² « È ª « ¯ ¶ ³ © ¶ ­ ÿ § Ä « È « »
º « ¯ ¦ ¯ § ­ º ¦ ³ ¯ « á § ² § ­ ± § ³ ¹ ¶ º Ë ± « © ¦ ³ ¯ § ³ § ¾ ª ² « ¯ ¦ ¯ à
¾ § ³ ± « ¬ ­ Å
Ó ­ § ³ ± § ¦ ² ± Ë © ª º ¶ ³ § ¹ ² § ³ § ­ ± ¦ ª ­ ¦ ¦ ² Ã ª « ± § © »
± ª ² ¦ § ­ © ª ¦ ± ² ¶ © ¦ ¹ ¦ ³ Ã ª § ¦ È ³ ± ² ¦ § § º á ª ­ © « ¶ »
­ ¦ · « § ­ ± ¶ à · ¦ ­ § ¨ ¶ ¯ § ª ­ § ­ ± ¶ ² ­ ¶ Ì ² « ¯ ¦ º ¶ ³
ª ³ ª ¦ ² « ¶ ³ Ð ­ ¦ º § ³ · § ¯ « ¦ ­ ± § º ¦ © ² § ¦ © « ¬ ­ ¯ § ³ § ² Á « »
© « ¶ ³ Å
² ª ± ¶ ¯ § º ¦ © ¶ º ¦ È ¶ ² ¦ © « ¬ ­ © ¶ ­ § ³ ¹ § © « ¦ º « ³ ± ¦ ³
§ ­ ² ¦ ¯ « ¶ º ¶ ¾ Ë ¦ ³ § Ï ¦ ¯ § ³ ¦ ² ² ¶ º º ¦ ¯ ¶ ª ­ ¦ ¦ ¹ º « © ¦ © « ¬ ­
à ª § ¾ § ³ ± « ¶ ­ ¦ § º º ¦ ­ Ò ¦ · « § ­ ± ¶ ¯ § · ã º ± « ¹ º § ³ ¹ ² ¶ »
© § ³ ¶ ³ · ª º ± « ¹ ¦ ² ¦ · ¿ ± ² « © ¶ ³ § ­ © ¦ ² ¾ ¦ ¯ ¶ ³ ¯ § « · ¹ º § »
· § ­ ± ¦ ² º ¦ © ¶ ² ² § ¾ « ³ ± ² ¦ © « ¬ ­ ¯ § « · ½ ¾ § ­ § ³ · ¿ ¯ « © ¦ ³
¯ § á ¶ ² · ¦ Ã ª § ¦ ³ « ³ ± ¦ ¦ º § ³ ± ª ¯ « ¶ ¯ § º ¶ ³ ¹ ¦ ² ½ · § »
± ² ¶ ³ Ã ª § ¾ ¶ È « § ² ­ ¦ ­ º ¶ ³ ¯ « á § ² § ­ ± § ³ · ¿ ± ¶ ¯ ¶ ³ à
¦ ­ ± § ¯ « á § ² § ­ ± § ³ · ¶ ¯ ¦ º « ¯ ¦ ¯ § ³ ¯ § « · ½ ¾ § ­ § ³ · ¿ »
¯ « © ¦ ³ Å
Ó ³ ± ¦ ¦ ¹ º « © ¦ © « ¬ ­ ± « § ­ § © ¶ · ¶ ª ³ ª ¦ ² « ¶ ³ Ð ­ ¦ º § ³
± ¦ ­ ± ¶ ¯ § ³ ¦ ² ² ¶ º º ¦ ¯ ¶ ² § ³ ¯ § ­ ª § Á ¶ ³ ¦ º ¾ ¶ ² « ± · ¶ ³ Ã ª §
à ª « § ² ¦ ­ ¦ ­ ¦ º « Ò ¦ ² § º © ¶ · ¹ ¶ ² ± ¦ · « § ­ ± ¶ ¦ ­ ± § ¯ « á § »
² § ­ ± § ³ § ­ ± ² ¦ ¯ ¦ ³ © ¶ · ¶ ¯ § § ³ ¹ § © « ¦ º « ³ ± ¦ ³ · ¿ ¯ « © ¶ ³
à ª § ¹ ¶ ¯ ² Ë ¦ ­ § ¨ § © ª ± ¦ ² ² ½ ¹ « ¯ ¦ · § ­ ± § º ¦ © ¶ ² ² § ¾ « ³ »
± ² ¦ © « ¬ ­ ¯ § ­ ª § Á ¶ ³ § ³ ± ª ¯ « ¶ ³ Å
¥ ¦ ¦ ¹ º « © ¦ © « ¬ ­ ¹ ² § ± § ­ ¯ § § Á « ± ¦ ² Ã ª § º ¶ ³ ª ³ ª ¦ »
   

  
 

         
   
  

     "   % ' ) ) +    )   -   /

    
/ ) 6 

)      8
 
 

 ; 

+  +      ) )  
 

      )    
8      
 )    )    + ) ) ) D 
 )
)     )   I  )  
    

      "  
+ ) )  )
      -  
 +  D 
 ) 

J    )   - 
+  )  
)   %
L 
M N O   Q O S T
                   ! "   
U    
 )   / )  )      X     
 )    Z J


  D 
   )   )   ) Z +   ) )        )   -  

J )          \
 ) 

]  ) 
   ) + 




  J )    + )   

   ) J  -      ^  )
8 )   )
  -  
  /

 

    ) 
 + )  - J
 )  %
'     
   / )  )      X      
  
$ )  + )
) +  
+

 

  
 +   )
8      -  

     + 
  
  - J
  
] - J
 
    a  
     +  ) 
 % b ) ) 
J    )
8      -  

 

   + 
  
    a        +  ) 
 
 D  


  ) 
 
   ) 
  Z J

 8     X    )  

% ' d
              )  
 
 
 +  +   

 
 )  )   ^
   -  
    + 
   % h )  )   )


  )    Z J

 
   +  

     i    

  
 ; 
/   ) 
 8    
 
 ) + ) 


  
+  )  ;     )
   

   )     
 )  
% l
D    ) ; 

  )  )  ;        
 

)
  6 )  
 +  )  
 

 + )   )  )  m ^
   /



 +
     
) + 
) m ) + )

 
 ) i   


 )    /

 
   Z J

 )  ;     )  m ; 

  
 )   Z  J ) 8


 Z  D    ) D      )  o    
+ 
i
 +  


      
   
 \
+ Z  
   q %
b ) ) +  
 D 

  
   / )  )      X  
   +
    
   +
      D 
; 
   )   )  ) 
;        

  X   
  ) 
 

J    )  )  ^ )
; 


      
 )
8      -  
     )  


D
 
 +   
)        +     )  )  -    

 + )  
 

    )   )    Z J

 %
  *     .  0 "     5
' )  
J    )   -  
  Z J

       

 )  

)    +      
     Z    Z J




    
 + )    J
  X     m + ) )   ; 


  )
D 

  )   )   /   )    
 

 )  )  ) ) +  
 ) )   )   ) J
 + ) ) ; 

) i   
)  )   )
J
 

/

   ) % h  
 
) i   

+

 

; 
   + u ]

 
   )   
  )      )     

 )  )  
 )    Z J

  
 +    )  )  )   
 ) +      - 
 + )   )  %
U    +  

J    )   -  + 


u J   )  

/   ) D 
% ' )
J    )   -  u J   )
 ) ; 
  )

 ) ; 
 -   

)   6 )   )   /   )    
 ) I 

  D
)  )   ) J
 a   )  
o ; 

 ) ; 
  )  
D
 ) ; 

) +    )   )   )   /   )    
   

  D i
  8  
   
J  
 ) i   
  
 +

  )  )   ) J
 

/

   ) q ' )
J    )   - 

/   ) D 
) +    ) )  )   ) J
 a   )  
 )  
/   )    
 ^ 
/   )    
 
/   ) ; 


     J )   
i  ) i   
)  )   Z J
 

/

   ) %
' )
J    )   -  
  Z J

 m 
+ 

) +  
 )  )    )   Z J




 + )    
 +  )  
o x l q    

  )       
     )  m

 ; 

   J ) 
  )    )   ) J
 
 

     i  
  
  Z J

 x l ; 
   +  

 8    


 z l %
{  ) 8
6 8       ) 

 +  
  
)  ;  
    -  
  Z J

  X    )  + ) )
   
 )  
/ )  )      X     ^  )   +   )    ) 
 )
J  
 )   -  m  ) D

 )   ) ; 
 )
J    )   -  
/ 
 ) D 

   +  
     + 
i  ; 
)    )  



;  

D )   )  
 ) + )    )  
 -  +    % | 
) 
 Z       
)    ; 

    i     
 )
  
 8
6 

  )    )   ) J

   8   

 m  )  )     )  
 -  +   
; 
  )
 ) } 
 ) ^  % 7 
 Z 
 
+  
  

J    )   - 



 )  
)   6 )   8 )  )       )  J   
) 
J     + ) Z 
   

  )  ) \ )   )
     )
) ; 
    8 )  
 ; 
+  +     

 
i 

    )   %
8 L : < >
~ N O  M 
U   D i
  8  I  ) 
    +  

  ) \
)  

 ) ; 
/ )     
 )  )
) 


   -  
   + )
Z 
    
    + ) )   ) D 
 )
J    )
  -  
/   ) D 

8   } 

 )     - J     + 
+ ) 

   )              
    +
8    


     J u )  "   %
' ) \
)  
  ) 
D
+
     )
i
    - 


J    )    
 
   i      J )  
 
  Z
J

  X    )  8 )  )       + ) Z 
   ; 

) /
  )  )  )  J      

J    )   -  m  )  D  X 

D


    
/ ) 6 ; 
+
   )
i
   ) ^
8
 I  )    \    ) D ) i   
/   ) 
     ) %
340 Tecnologías Grid, Clusters y Plataformas Distribuidas
                     !
$ &        ( & $     $      ( & 
  2     $  $  2     5         $  &     9
 :     <

> 
? @  B D B F   G @ F
  $ (  J $    K      (  &      9
&  $   N        &    $         R     9
N   (    R     $   &        :  N   ( 
     &       : 5   &      $         
 Z   $    (  ^  & J  &  J N & J N &  J  < a <
b   c  :      Z  e
f  h   $     2   $  
   $   i   Z  J  $  2    $     &    $ 
 j     R   $    N   ^ Z  c  :    l     & 9
   b      Z c l b a < Z c l b  &    $  :
 $ n   :    $ l     &    J l     :  o    K  9
      ^ n l l K a e  f !           :  &   
&   :           o      &       c  :  9
    &    9       < b   c  :      Z   $  9
2   $ &      $  c  ( & $        t    9
  $ c t e u  f ! &   :  (      (    ( 9
& $ &    $      (              9
   &             $       N   ( 
      $  2    o                   9
$  2     $     $   i    b <
v  $ o   (    j   e u u f J  y      
&   &                  R         &  9
    ( &     o   $          : 5   ( { $  & $ 
  (        (        :   < b         &  
      |   J     J   N |   o N   ( |    
^ y        $ Z   a < b   $  :  $     &  
y     $       2    R      $ ^  a < n  
 e u € f   j    (       &    R  ( &  9
  $  &  (      ( &   &           9
  :    $  J   &         2       !  &   9
  o  $  2         <  $     &    o
! $  &    :    R   $         o &   :  $ 9
     $           (           
          ( &   (  $      ( i   
   $         i      !   N       $    9
  $   i   y            $   i     (  $    <
  $ (  $    :      $   i   y     9
h  :  $         (           $   i   
c  :     Z  < &  y    c  :         9
 ^ y c a e u ‚ f  &      $    (   
:  $   R         <  ! y c &   9
               &         9
     $      y    J  $     &    $ (       9
    (              $   i    (  &  
 ( & $  $         <
y $    y v €    & $   N   (  y     h    
o   o 
 :     &   o    ! $   $  2   &  9
  $       R         $ |    <   l v 9
y  K l e ‚ f &     y v €  $      (     $  9
2    &    $       $ $        |   J !
&         &     $ (              
      (         :   J   i   (  (   9
     J $   2  (            J & $    j   9
  R       o      $        $     9
    <  $   $     $ (    $ |    l y !
   (       o  ( & $       !       $
    $ |   b „ y o &   o      (  $   &   
    N    $            $    (      
" i      $       i   < b „ y  $ (    $ |  9
 ! ( & $   (     &   o   &    $
      $ $   $  &   y    <
$ > &
G ( … † @ F ˆ @ … G 
        R           $  $    !   9
  &   &   &    $ $ :        $       :  
(         $      R  ‚ <
„  (  o           $      R  ‰ J   
  !            $ (    $ |   y   
b „ y   (         $  &      :     < t  9
        $ N       (      (    $ 9
|            $ $        !     
  &       $    $          $ $    $   & $  9
    R   $   2  (                <   
  !        $ $   h  $  $          9
  R  <
 $    (         ( 5      J     9
   ( h    ( 5         ( &       
N                     j 9
 < b  N   (   !             2  $ 
        $        Š & $          9
(     $      R  ‹ < € <
* , . , 1 3 4 3 5
„  (  o     :                  9
            J $       $ $       $  2   
   &   J &   &             (  o      &  9
     o         R   $ y    <   $        9
 &       $ $         $     &    ( 9
& $ (      o   $         $      $   i  
( & $      $ $   <
XVI Jornadas de Paralelismo, JP '2005 341
Gate (UI)
Grid LCG2
Middleware
WS
WS
Container
Servidor
FTP
Aplicación.
LCG Registration
Launcher
XML Datos

        
             
          
   ! # #  & ( * , & . , ! # 2 3 & 4 & & 4 7 8 3 4 * : # < & 4 & 
? A . C D ?  A G <  H 3 7 ! : J . , ! # K , < N & G 7 P Q R T V  4 W
7 & 4 ! 4 7 &  * Z * G & 3 4 < # & , & G 3 , 4 < 4 G <  H 3 7 * G ! < : * W
 & 4 \ # & *   * G & : *  ! & : 7 < 2 3 & & 4 7 8 : ! : 4 7 *  * # < 4
& : 3 : J , * : : _  & , < # & G & : 7 , < 4 # & G <  H 3 7 * G ! b :
& : # ! 4 7 ! : 7 < 4 H * d 4 & 4 V  4 7 &  ! # #  & ( * , & < f , & G &  *
!  H , & 4 ! b : # & 2 3 & 7 < # < 4 & 4 7 < 4 , & G 3 , 4 < 4 & 4 7 8 :
# ! 4 H < : ! l  & 4 # & f < ,  * G < Z & , & : 7 & < f , & G ! & : # <  *
* H * , ! & : G ! * # & 3 : G <  H 3 7 * # < , _ : ! G < V
? * o J 3 , * C  3 & 4 7 , * 3 : & 4 G & : * , ! < # & & N &  H  <
# & 3 : * & 4 7 , 3 G 7 3 , * # & 3 : . , ! # & : ? A . C V
   ! # #  & ( * , & . , ! # # &  ? A . C  < G <  H < : & W
: & :  < 4 4 ! J 3 ! & : 7 & 4 &  &  & : 7 < 4 t
•
u v W  w u u t u : f < ,  * 7 ! < : v & , y ! G & W  & ,  &  & \
w * 7 * l * 4 & u : f < ,  * 7 ! < : u : # & { | & 4 7 & &  &  & : W
7 < H , < H < , G ! < : *  * ! : f < ,  * G ! b : * G & , G * # &
 < 4 , & G 3 , 4 < 4 # &  . , ! # \ 4 3 & 4 7 * # < V
•
A ! t A & , 7 ! o G * 7 ! < : ! 3 7 Z < , ! 7 \ |  * A ! o ,  *
 < 4 G & , 7 ! o G * # < 4 7 * : 7 < # & , & G 3 , 4 < 4 G <  < # &
3 4 3 * , ! < 4 V
•
A  t A <  H 3 7 ! : J   &  & : 7 | 4 & # & o : & G < W
 < 3 : * G <  * # & 7 , * l * N < 4 . , ! # V  : G <  W
H 3 7 ! : J   &  & : 7 & 4 3 : * J , * : N * # & : < # < 4
# & G b  H 3 7 < Z <  < J „ : & < 4   *  * # < 4 … < ,  & ,
# < # & 4 V
Organización 2
Organización 1
Grid WN
WN
RB
CE
SE
WN
Usuario
Usuario
CA
Gestor VO
BDII
RLS
CE
UI
$ & ' ( * , . 0 2 3 5 * ( 6 5 ( * , 9 : ( < : ? : @ B C D 9 : F * & 9 H I F .
• K M N K P Q R S Q M P W S Y [ P \ ^ P [ \ P W P [ P c e g
h j k
\ l [
h j
S Q S l ^
k o
l \ ^ l [ p l Q S l [ W S r t c v
j
p P x
• y z N y p P Q l { S z ^ S c S \ p Y
j
\ y z S [
j
\ Q S r
j
Q g
[ P W S l ^ c l r S \ l c
k
S \ p P
h j
S [ S S \ r l Q { l W S
l ^ c l \ r S \ l Q W l p P [
h j
S v P W Q e \ [ S Q
j
[ l W P [
v P Q ^ l [ c e
h j k
\ l [ W S ^  Q
k
W x
• ‚ ƒ Y ‚ „ y N ‚ S v ^
k
r l ƒ l p l ^ P { Y S [ S ^ S ^ S c S \ p P
h j
S { S [ p
k
P \ l S ^ l ^ c l r S \ l c
k
S \ p P W S W l p P [
S \ S ^  Q
k
W x
• ‚ ‰ N ‚ S [ P
j
Q r S ‰ Q P R S Q Y S ^ ‚ ‰ S [ S ^ { S [ p P Q
W S p Q l Œ l  P [ S \ S ^  Q
k
W Y S [ p S S ^ S c S \ p P W S g
r
k
W S S \
h j
S ƒ z [ [ S p
k
S \ S \
h j
S ^ l \
o
l Q ^ P [
p Q l Œ l  P [ x
•   N  [ S Q  \ p S Q ’ l r S Y S [ p S r P c v P \ S \ p S v S Q g
c
k
p S
k
\ p S Q l r p
j
l Q r P \ S ^  Q
k
W l p Q l ” • [ W S
j
\ r P \ 
j
\ p P W S r P c l \ W P [ x
z ^ – P Œ ˜ S [ r Q
k
v p
k
P \ „ l \ {
j
l { S › – ˜ „ œ S [ ^ l
’ P Q c l S \
h j
S [ S W S [ r Q
k
Œ S \ ^ P [ p Q l Œ l  P [ S \ „ ƒ  x
 \ – ˜ „ S [
j
\  r ž S Q P W S p S Ÿ p P S \ S ^
h j
S [ S S [ g
v S r
k
 r l Y S \ p Q S P p Q l [ P v r
k
P \ S [ Y r
j
e ^ S [ S ^ S  S r
j
g
p l Π^ S Y r
j
e ^ S [ [ P \ [
j
[ v l Q e c S p Q P [   ^ P [  r ž S Q P [
h j
S S [ p l Q e \
k
\ ” P ^
j
r Q l W P [ S \ S ^ p Q l Œ l  P x
¡ ¢ £ ¢ ¤ ¢ ¦ § ¨ § © § ª « ¬ ª ­ ¬ © ® ¯ °
„ l r l v l  l p S g p P g  Q
k
W r P \ [ p
k
p
j
  S S ^ v
j
\ p P W S
j
\
k
t \ S \ p Q S S ^ S \ p P Q \ P  Q
k
W   S ^ S \ p P Q \ P K S Œ
h j
S v Q S p S \ W S c P [
j
p
k
^
k o
l Q r P c P
k
\ p S Q ’ l
o
W S
j
[
j
l Q
k
P x „ P [ [ S Q ”
k
r
k
P [ P ’ Q S r
k
W P [ l ^
j
[
j
l Q
k
P [ P \
342 Tecnologías Grid, Clusters y Plataformas Distribuidas
   
                 ! "  # %       

            - /      % ! %    " %    "  6 %
 7 
8 9 %   ;    " 9    "  > %   A        % "  6 % 9  D
  %     "
 9 !       G H   " A    %   %  K   

  !   8 !   #  % 9 %  -
M   % 
P             %     " A    %   %  K 
  " G H U !   "     K       !               
X /    !   9    " %
 !  %   "    %        
 "      9 %  !   %   !    "    %    8  " G H -
M     ]            
     " A       ]  
 
%   %  K    
  !   8 !   #  % 9 %       %  % ; % 

       

       " G H 8    ] %
 "   %  " %   % D
  %   
  %   %  - c " %

   %      !   #  % 9 % 
8 
  !     ]   9 %   9   %     % "  6 % 9    %   
   
      U "             " %     % " %
 7 
   
   %          
   >   -
M      
      9    9 !    %         
 ]  
     h
•
H          - c        
     "  
%  # %  
  #     %   " !   i 8 % ! %       "  
    j D

%         %      " A    8   %  "  % 9   
 
    
 % "    "        A    -
•
A    > / %  P c i 
     - c   " G H  
  %
  %     
   %      
      ! %  %
%  %
" %  6 % 9          %  % ;   U A    > / %  P c D
i 
              %    % l  
%    " G H
% ! %       " %
 % "     # %   6 %    " %   9  D
#     U "   "  #  U 8 "    n M    "           
  %  % ;   -
•
  9   - M % " " % 9 %  % %    9      
%  D
# %     #     %  "   % 
P       " G H % " c U

  %  "    n M  ! %  %
%  %   %  % ;  8 j  % " D
9     " %  6 %  "     %  % ;   % " A    - X   
      P %
 ! %  %   %    %    ; 

 7 
 %  % -
•
A   H  ]   9 %         -

      " %   ]   9 % D

 7    "   ! %   9          #   !   
  %  % ;   8       P %         %   % " A   

   
 % 9     -
•
r % 
 "    - r % 
 " %     %  % ;        D
  % " -
•
r % 
 " A    ! - r % 
 " %  " #   !      %  % D
;   8  "  9   % "   % 
P       #     %    -
•
A       %    -

       "    %      
  %  % ;  M r A
 
    - M      %    !   "  
   ! %  %     %  % ;           ; 
  %
 
K i       h
   9      U
> %     #  U
  %  8  U


P    "    U
      #  U       U

"  %     -
•
/   ! %       "   -   
%  # %   !   ! %  % 
   " G H "       "  %          %  % ;  8 %
j  % "  6 %   U             " A    " %  % "   %
      %  8          "   %  % ;   ; 
  %  
%  x
 9  "   j
P      
    #     %
 7  #  D
   %    -
c   " G H                 % 9   K   "  ;  D

  %  "       % "  6 % " %   #     %

 7  U       

 9 !  " %      ]   9 %      
% ! %  %    !    %
 ; 
  %       !    "  9 %      !     
 %   

 % "      %   " %  9      %    " A    - M %   D

#     %
 7      9 ! "  9    %      ; 
  %  "     
 %  %  %   " %    "    
%     ]  > %   H X  z { | } -
H X                ]  > %    
7   #  %      
! %  % " %   #     %
 7  8   # 9    %
 7     9  #  D
   -
   #  % ' ( ' * , . . 0 1 2 ' 3 1 6 8
M %
% ! %   9    "  > %     "         
 
!   !  
   %   % %     %

 7  % "      "     D
 
      -
M % %     %

 7    " %
% ! %      
     
       %    "      
   % "   %  - /     " %   U

    #      % "      x %   %

   % "      
  
       !           " %
% ! %   % ! " 
%
 7  8
!      % ! %   
  %  9 K      8     
   %   
 %      9   % "       " ! %  % ] %
 "   %   "    % D
   " "    % ! " 
%
     j  % "          "     D
 
      -
c " P 
P            %    " "  " % "      x %  
%

   % "      
     
 9    !   8 
 
  ! %  %   ] %
 "   %      i      7  %    %  % ! "  D

%
       
 9 ! %   %   
    %      9  " %   
8 %   9   !   9            
  9  ;   %       %

% ! %        
  %   % 9     % ] 
  % " %  % ! "  D

%
        " %     " 
  -
9   9   U    %
% ! %  ]  
   %        " " % D
9 %  %   %  %  %    " %  9 / H  < X /   A "    
! %  % !       % "  6 %   "   %    #    j
P    
 
" %
% ! % A %   D   D A    -
=  
 
   % 9     U " % %     %

 7    "  
   
     
       U   !   9   "  # %  U  

 "  %  " %
  %
 7  8 9 %   ;    "         
 D
 %     ! %  % " %
 9   
%
 7 
  "      
  
XVI Jornadas de Paralelismo, JP '2005 343
   
   
        
 "        (     +
,    (        0   , 3 4 3        3 
(    (   4 +
(      <   
4 3     > @  A B 3        @  3 4  4 3 A

E  4    
      0   , 3 4 3      3  @ 
3    

  4  @  I  (  + (  + I  3  L  B 3  (  
 M (    

  (  4  @  N     4      3
P     4 3 A
N     +
,    ,    0   , 3 4 3    V 
P     ( 
 Z \ >
  ,    ,       (   
( 3 @    <  3 4      "  (  
  (   4 (       @    N   @    
    
 "    
 3   4 (   
(  @     4  @     @  3 4  4 3 A
 ^  +
    @   4       B (   4 4 3 A
  3
P     4 3 A
  
  4   
( 
 Z N     ,    , 
   0   , 3 4 3  
    b         b      3 
( 
    @ +
@    c d e f 



            $ &
  (  4  @      N    P   4    3
(   P  h   < i 4 
4 
  N          3  3
(    4 (    <    (  4  @ 
b  4          P 
4 3 
  L   "  (   > 4   @ 
 +

 (   N    P   4    4  @   3     m    0 @   
    3 h   4    N  3    @    4 3 A
       I  3  
Z    @ 4 3 
       N    3  @ 
   b     +
 3 
(   
r
•
I   ( 3 A
  @   i      @   <   (     Z     +
( 3 A
  @   <   (    @    3 (  4     L    3 i +
4   >   3  3
  4 
i     4 3 
       @  +
 <   (    @       
h   3 
(       3  (   +
4 3 
   Z   @   <   (           3  (   4 3 A

, 
  <
     @   
4 
" 
(     
  
  ,       N      <
   N       


   
h   3 
(          3  (   4 3 
  
 
I  3  
•
u  
 P   
4 3       3  <  
  ,     M (  3 +
4   N     , 
    3  (     
(         3 +
h        3  (   4 3 A
 
 4     3  (  
 P   3  
  4  @  I  (  + (  + I  3       4 b 3 ,     3  < +
 
     3   A  3 4      @         3  @ 

  
 @   (    
  N       3       +
4 b 3 ,      P   
4 3  >      4 b 3 ,   v  ( 
+
(   @         3  (   4 3 A
   (     4 b 3 ,    

  (   < ( 3 4   
(  (  
 P   3      I  (  + (  +
I  3  
•
   4 4 3 A
      
     @   <   (    >
 
h   3 
(    I  3   Z   @  3 4  4 3 A
@    3 +
(    @  4 3 i 4   4       
    
     @  +
 <   (    V     , 3     3 h   3   b 
4      
        @   i    \ @     
h   ( 
(   3
 +
( 
4 3   4    4    3
 4 3 
  @  
3      
   ,            @   <   (      3 
<
  +
   

     @    3  
( 3 i 4        @ 
  (     "   
•
0    3  3 
(       (     "   >   ( 
4 3 A

       (      ( 3
   
(     @  3 4  4 3 A

(    3 M
    (   >    ( 3 
   3
P     +
4 3 A
           @     (     "    
h  +
   >     (      4    (     "  3
 3 , 3     
{
 ,  h (    3
       (     "      3  (  +
  @    3 (     4              (     N  
b 
 
     @        (   3  
) + , + . / 1 3 4 6 8 9 8
|  
    (     "  4 
  (    M  3 4       +
   3        3
P     4 3 A
4 
  N     (   ( 
    , 3 (   3  @   ( 
4 3  @       
( 3 h     @  3 +
,  4 3         @  4 3 
(    E  
(        (  
@    
    L      (    M  3 4      (  4 
@     
3  @  3 4  4 3 
  N   @     ( 
  @      @   @ 3  +
(   3     3     4 3 A
3
           3
P     4 3 A

Z   ( 3  3 h  4 3 A
   3  (     I  3  
     3  +
@  3 4   4 4 3 
  N   @    
@ 
  
 3      
@  3 ,  4 3           (    M  3 4      @   4    +
 3 
(         (    M  3 4     @ 
   (  
 +
P   
4 3     4       " 
    4 
(   N    3 @ 

      3      0 3  3 
  (   3  <  
  @    } 

 4 4       @        3   4 
     i 4 3 
(   @  3 +
, 3    3   
    3  (         (   L   @  3 ,  4 3   

   4   @     (    

3  3 h     3  <  

Z    3 P   
(   4  @   N   4   @ 

    N  3 +
(  4 (      i
3   
    4 4 3 A
e     4 
<   3 +
(          3     3 P   
(   L @   
 @   (    ( <
  <   3 (       0   , 3 4 3     > @    (      
  <   3 (    
(  
 I  3  + Z | I  
      
 ( 3  3 h  
(  
 ( 4         3
(   4 
 B 3 A
>  
 ( 3  3 h 
@   (  4       (  
  3  3 A
       
;  P   
(    <   3 (         3         0   +
, 3 4 3     L 
    N  3 (  4 (        i
 
 4  +
@  4  3 
(  V  3     m    0 \ @    3
(    4 (   
4 
   3  (     ^    3
(    4 (    4 
   0   +
, 3 4 3            @   (  4    0
<
 ^ N   

   (   4            3  @    
(  4 3 A
    
= u u ^ 0 L       
0  4    0  4 ?  ( Z  >   V 0 0 Z \ 
  @   (  4    = u u ^ 0    
( 3 h    @  3 ,  4 3   
       (   > 4 
   ( 3  3 h  4 3 A
  4   ( 3 i 4    
344 Tecnologías Grid, Clusters y Plataformas Distribuidas
                      !      # #  $ 
  !  !   & '
(      .   1   !      & 5 7 9 1 ; = ?  & @
A    !    D      ! #  !     A     !  
   1   K  # !    M O  D      ! #  !   5 1 K O ; '
1 K O             K K 7 ' V  ? &     @
  $       1       #     &   ? &    
!  ?  & ] M      & ?      !  #     ` # &
 #       `   & ? &  ! 
!  &   9     ` @
# &  5 9
;  # &  `   = # &   & b !     @
           ` # #  $    !  !   &     &  
1   ' 9   # !   &   1         #  !   @
?  &   f       !   g     5 f  ; = &      &
  ?  & ] M      & = !  !  !   &     # !   & '
         # !  &   &    # !   &    ?   @
 &      1      k #     ` # & ? &  !  9

A k   ?      D &   ? &   #    #    
   !  &         m m V K '

     &         g  ] ? !    &     !  
   &        &  k     &     b !    #  ! 
5 p   M 1   ; '
# &     ! #  $      #     # & @
 &         # &   ]  $      &  &     &   & 
 D &       ?       !  !   & ' (    b !  @
  #  !    #    =  # ? 1   @  & @ 1         @
] &  !   $       p   M 1   ' (     # ?
  g       #  & !          ?  &   & 
!  !   &  p   5 #     ` # & p    !  !   & ; b ! 
     #  !         &  K   A  #  &  p     ?   @
 &     # ? 1   @  & @ 1   # &   &  !  !   & 
1   ' V  # !  !   &         ! ?  & ] M
?       ! #     ` # & 1   '
r
s t u v  w y z u
(     !   &  k     #  &         | & g
  &  g          7 9 1          &  7 !  @
# g    b !     ?   # #  $      &    &    
 b !    #  !    #    '
(      ? &   b !    & ?        !       @
  #  $    !   k b !   V O O O  } }  g  # & 
~  €       &   
 g   &   g & 
M € ‚    !  &  '
V &  &   &  & # !  &   g    &  &     
1    €        #  &       !   k    = !       &
 &    # !   &    1    ( 1 ( ( 5 &      #  $ 
A    !     &   ;  |  &     # #  $    & 
  # !   &               $      | &  5   ;
  &   ! A & !      ? &     ? !     „ g &  
     !  &  '  M b !         # !    b !     & 
 … † ‡ ˆ
" ‰ ˆ Š ‹ † ‡ ˆ  Ž †  ˆ Š ˆ  ‹ ˆ   ˆ  Ž  ˆ ˆ Š  … ‘ ˆ ‘ …  
  # !   &       # &  ?    &  ? &  &   &  !  ! @
  &  ' (  #    & !       &  &         # !   & 
# &  !     &    &  !      #  $  =       ? &
 &   D !   € g &   ~ „    !  &  5 !  9 ( # &  € #
p   ; '
            `  !  „ ?   #  !  # ? @
 !    ?       &    &    #  $     |  @
# ! #  $  M   # &       !   &  '

r 
z ’ “  v u ” z ’ t u
7 ?   # #  $  `       &   & D   #  !    @
   D     &   A   M D k #    !   b !  ?      
  ?  & A  # g      &   1   7 9 1 € !  !   & 
 & D        &  # &      #  &  &  •  1   ? 
        #  $     k      '
9 &    !  &   g           #      # &  @
   !  !     # ? #   # $  ? !  & !   
  #  &         | & ?    k ?  # &       @
  #  $   A &  –        &  $   # &  '
(  1    ! ? &   !    #  &  &  • b !      
? !      !  &    ?  k #   # #  •   #  ?  & @
#   &  b !  = ? &   !    #      # &  ? !  #  &  @
   =  &    !    A      =   k   & D   #   ! 
?   D &      ?  & ! #   A  ?     @
A      #  $     # ' 7  b !    #  !  ?  & ? !   
  ?      D        ?   D &    M ?     @
    |  # ! #  $    D        ?   # #  &    #  @
   &        D   !  !   & '
XVI Jornadas de Paralelismo, JP '2005 345








       
             ! "  !   %  "    ( %  "    + 
   + ( .  / ( 1 ! %  5 ( % % +  7      ! 9  /  %    +     ?
   / / ( 1 ! %  + A  ( % %  9   5  E   "   5 (   !  + 9 I ?
/ ( + %       + +  %  ( !    9  /   "     + +  ! .  5 (  !  
%           + A  ( % P
! /   !    +   " + ( /  / ( 1 ! %       + +  %   
"     %   ! "   X  /   5  / Y  5 I   5 " + (  P Z  ?
5    Y  ( !    %  / ( %   ! +  \  / / ( 1 ! ^ _ +   " + ( ?
/  / ( 1 ! %    ` (     / ( 1 !    ! "  ( 5   "    %  +
5  %  +  %  9   5  /  / ( ! c  ( /  P +  ( `  (  !   "  ! ?
  E           I   +   f    / / ( 1 ! %  + 5  %  + 
9   5  /  / ( ! c  ( /  %  %   + /  !   !   %   % E  (  ( ?
/ (  !   P h                I !  /     (  % (  "  !  
%  +  Y     5 (  !   %  /     ` (     / ( 1 ! E   Y   ( ?
%  %       + +  %   !            P  ( !  + 5  !   _ + 
/  "   ( % % +  7    j \    5 " + (   I "      "   ?
   !   l   9  ! / (  !  + ( %  %     +  / (  !  %   /  ! + 
 f    / / ( 1 ! %  + 5  %  +  9   5  /  / ( ! c  ( /  P
 /    + 5  !   +   " + ( /  / ( 1 !    I "   "    % 
"    9  ! / (  !   /  ! l  + r 5  !   %  ( 5 I `  !    !
9   5     !  + X .  s t u v _   ! E   +   f   !  ( 1 ! 
     9   5     /  5  x y Z

 s t z v    I /  !   5 ?
" +  %   !    +   "  (   ( %  %   P



| } ~    } ƒ  
„          E  (    !  `   %  /    +   "     … !  ! ?
/ (      / (  ( %  "   "     %  +  ( ! (     (  %  Z (  ! ?
/ (  X †  / !  +  ` ‡  "     + %       + +  %  + "   X  /  
 y ! l    ( `  / ( 1 ! X x       + +  %  \   l ( / (   A  y x ‰
 " + ( /  / ( 1 !    %  +   Z + (  !   ? \   l ( %   _ Z  +  ?
     ( l   X %   +   h   %  /  ( l ( %  %  _ /  !   9  ?
  ! / (  † y Z ^   Š ?  t Š t  P      X  %      I ! /  ?
… !  ! / (  %   "    +   ! %     "   %  x       ?
+ +    ` (  !  + ‹  x  Œ     l c  %  +     ! %  
    /     +   P
 }  }  } ƒ ~ 

s t v !   + ( ! ` A  ( %  9   ?  / (  ! / P
Y   " ‰   7 7 7 P   ?  `   P   ` P
s ^ v y P        ! % Z P      + 5  ! P A +     ‰
 5    /  5 "   ( ! ` ( ! 9       /        + (  P

                 %    )  *  )   - _ "  `  
t t Ž _ t ^  _ t # # z P
s Š v † Y  x  †  A  y x "     /  P
Y   " ‰   7 7 7 P   ? %    `  ( % P   ` P
s  v „ % Z Z  5 "   ( ! ` A  ( % P
Y   " ‰   + / ` P 7   P /   ! P / Y  „ Z A P
s Ž v ` „ (   P Y   " ‰   ` + (   P 7   P /   ! P / Y  ` + (   P
s u v  ! ( /    9    5 P Y   " ‰   7 7 7 P  ! ( /    P   ` P
s z v y ! !   A  ( %      5  !   + _ ^   Š P
s  v \ /    \ Y    P 0   *  ) 3  5  -   7 )  )  - :  =
> ? A  *  *  *   *  * G   *  K L N P  / ?
A   7 ? % ( + + _ ^   ^ P
s # v  ! ( l     + x   /  ( "  (  ! _ x (  /  l   X  ! % y ! ?
  `    ( ! ‹  x x y Œ P Y   " ‰   7 7 7 P  % % ( P   ` P
s t  v \ ( 5 " + 

   /   / /    h     /  + ‹ \

 h ΠP
Y   " ‰   7 7 7 P 7 Š / P   ` P
s t t v f "    A    "   "    P
&  f  `  !     (  ! `  ( % ‹  Œ P
Y   " ‰   7 7 7 P /   % (  P +   (    `  ( %   ( ! %  f P Y  5 P
s t ^ v       y P  ! %      + 5  ! Z P N Q  S U
W Y
Z      )   G   * K  ^ 0     )  b
 G  *  - e
        P    `  !    9 5  ! ! h   + (  Y    _
y ! / P _ t # #  P
s t Š v y P       _ Z P      + 5  ! _ * P & ( / _  ! %
\ P †   /  P † Y  " Y X  (  +  ` X  9  Y  `  ( % ‰  !
 "  ! `  ( %    l ( /     / Y (   /     9   % (    ( ?
    %  X    5  ( !   `    (  ! _ ^   ^ P
s t  v y   !  . _ \ / Y    %   _ & ` _  ! % Z     P N Q 

N g   G  ^ *   S  ) 5  P  (  7    y ! / P
s t Ž v A P   +  1  ! % * P  P Z    ‡ P A  !    / ( 1 !   ?
  5 I  ( /  %  7   " "    "     +  / /    X
5  ! ( "  +  / ( 1 ! %  %     f 5 + P A ) =   5  *  e
 * - 5   m n ^   o - Q   ) =    *   )  *   5  )  e
b   )   q * 5  U  t  ) - )   - u * = )     - -  G  e
^ *   _ "  `   ^   w ^  Ž _ ^   Š P
s t u v  !  + X .  z P Ž … +  9   5   P   X  Z + ( ! ( / P
s t z v &   (  !  + +  /   ( /  +   !  9  /           ?
/ (   (  ! P x ( ` (   + y 5  ` ( ! `  ! % Z  5 5  ! ( /  ?
 (  !  ( !   % ( / ( !  ‹ x y Z

 Œ P t Š   & P t z  Y
\      _     + X ! _ 6 (  ` ( ! (  ^ ^ ^  #  \  P
346 Tecnologías Grid, Clusters y Plataformas Distribuidas
Incremento de prestaciones en el acceso en Grid de datos
José María Pérez Menor, Félix García Carballeira, Jesús Carretero Pérez,
José Daniel García Sánchez, Alejandro Calderón Mateos
Departamento de Informática. Universidad Carlos III de Madrid
Av. Universidad, 30 Leganés Madrid
josemaria.perez@uc3m.es
Resumen
El modelo de computación Grid ha evolucionado
en los últimos años para proporcionar un entorno
de computación de altas prestaciones en redes de
área amplia. Sin embargo, uno de los mayores
problemas se encuentra en las aplicaciones que
hacen uso intensivo y masivo de datos. Como
solución a los problemas de estas aplicaciones se
ha utilizado la replicación. Sin embargo, la
replicación clásica adolece de ciertos problemas
como la adaptabilidad y la alta latencia del nuevo
entorno. Por ello se propone un nuevo algoritmo
de replicación y organización de datos que
proporciona un acceso de altas prestaciones en un
Data Grid.
1. Introducción
Actualmente se puede obtener una gran
potencia de cálculo mediante la utilización de
clusters y Grids, sin embargo la E/S se ha
convertido en el mayor cuello de botella de estos
sistemas, al igual que en su día se convirtió en el
cuello de botella de la computación de altas
prestaciones en los centros de supercomputación.
Para algunas aplicaciones Grid que acceden a
conjuntos masivos de datos este problema no solo
persiste, sino que se ve acrecentado debido a las
distancias entre recursos (latencia), al bajo ancho
de banda de algunas redes, al gran número de
clientes que acceden a los datos y a la gran
cantidad de datos que necesitan.
Los sistemas Grid se suelen clasificar en Grid
computacionales (Grids) y Grid de datos (Data
Grids). En los Grids computacionales prima el
aspecto computacional y puede verse como una
simple ampliación del concepto de cluster,
mientras que en los Grids de datos prima el acceso
a grandes cantidades de datos de forma eficiente
por lo que no basta con escalar el concepto de
cluster [1].
Los Data Grids [2] tratan de suavizar los
problemas en el acceso masivo a datos en Grid. Se
define un Data Grid como un conjunto de recursos
de almacenamiento y elementos de adquisición de
datos que tratan de proporcionar a las aplicaciones
los datos que éstas necesitan mediante un
middleware especializado en la gestión de datos.
El sistema propuesto en este artículo se centra
en el aspecto de acercar los datos a los clientes
que los utilicen, en la escalabilidad mediante la
agrupación física y lógica de recursos, en la
reconfigurabilidad y en la autogestión del
almacenamiento y del acceso a datos en un Data
Grid. La agrupación física trata de explotar la
proximidad de localización de los clientes y nodos
de almacenamiento, mientras que la agrupación
lógica trata de aprovechar la característica small
worlds [3] presente en los Grid multidisciplinares.
2. Modelo de Grid de datos
El sistema propuesto se centra en el aspecto de
almacenamiento y acceso a datos en un Data Grid
El objetivo principal de este artículo es proponer
mecanismos para optimizar el rendimiento, la
escalabilidad y el balance de carga en el acceso y
creación de conjuntos de datos entorno a los
clientes que los necesiten o puedan necesitar en el
futuro en un Data Grid.
Para aumentar el rendimiento en el acceso y la
gestión de los datos se utilizarán técnicas de E/S
paralela y la agrupación de recursos de forma
física (localización) y lógica (contenidos).
Para ello se definirán una serie de entidades
que tratan de agrupar los datos y recursos tanto
física como lógicamente (ver Figura 1).
En el sistema propuesto un archivo está
compuesto de un subarchivo de metadatos y un
archivo de datos. La separación de datos y
metadatos se debe al mecanismo de localización
tipo peer-to-peer que permite una gran
escalabilidad y que permite guardar una clave
(subarchivo de metadatos) en cualquier nodo del
Data Grid, mientras que el subarchivo de datos
permanece cerca de donde sean necesarios.
Figura 1. Entidades del sistema Data Grid
Las comunidades de almacenamiento se
definen como un conjunto de nodos de
almacenamiento cercanos entre sí, cuyo objetivo
es proporcionar recursos de almacenamiento a los
clientes cercanos, pero que pueden ser accedidos
desde cualquier lugar del Grid si es necesario.
Cada comunidad de almacenamiento tiene un
nodo central que realizará funciones de
localización de datos y de recursos, para lo que
será necesario establecer contacto con otras
comunidades.
Se define una intragrid como una entidad que
agrupa varias comunidades de almacenamiento
mediante criterios de intereses comunes. Es decir,
se trata de una entidad agrupativa basada en
criterios lógicos (contenido de los archivos).
Las intragrids tratan de acercar a los clientes
los datos que puedan necesitar sus aplicaciones en
el futuro, basándose en el contenido de los datos,
reforzándose la relación a medida que se vayan
creando nuevos archivos y relajándose cuando una
comunidad esté más interesada en otros archivos o
conjuntos de datos. Una comunidad se unirá a
intragrids ya existentes o abandonará una intragrid
a la que pertenezca según cambien los temas de
interés de la comunidad. Una comunidad de
almacenamiento puede pertenecer a varias
intragrids.
2.1. Localización de archivos
El sistema de localización utilizado en el modelo
propuesto en este articulo está basado en las redes
de tipo superpeer [4], donde se forma una red de
cobertura (overlay network) entre los nodos
centrales (superpeers), conectándose el resto de
nodos a éstos. Sin embargo, a diferencia de los
sistemas superpeer, el nodo central no tiene por
qué conocer la localización de todos los archivos,
ya que dentro de la comunidad puede haber
cualquier tipo de sistema de localización.
El sistema de localización distribuido
propuesto consta de dos pasos. El primero localiza
la comunidad de almacenamiento donde se
encuentra el subarchivo de metadatos y en el
segundo paso se procede a localizar el archivo de
metadatos en la comunidad.
La localización de la comunidad se llevará a
cabo mediante una red de cobertura (overlay
network) formada por todas las comunidades. Ya
que normalmente los algoritmos para formar este
tipo de redes se basan en nodos, más que en la
unión de subredes (comunidades) se utilizará el
nodo central de cada comunidad como el
representante de la misma. El nodo central de una
comunidad no tiene por qué saber en qué nodo de
se encuentra un archivo, pero sí sabrá si el archivo
se encuentra o no en su comunidad.
El segundo paso de la localización utilizará un
mecanismo local a la comunidad para localizar el
archivo. Como mecanismo de localización se
puede utilizar cualquiera de los siguientes:
• Centralizados: El nodo central conoce donde
se encuentran los datos. Es un típico servicio
de directorios.
• Distribuido con función de localización: Se
utiliza una función tipo hash aplicada al
nombre del archivo para localizar el nodo
donde está almacenado.
• Distribuido con multidifusión: Se utilizan
mecanismos de broadcast o multidifusión a
todos los nodos para preguntar por un archivo,
el nodo que almacene el archivo devolverá la
respuesta al nodo que preguntó.
2.2. Creación de archivos
La creación de un archivo sigue los siguientes
pasos:
348 Tecnologías Grid, Clusters y Plataformas Distribuidas
1. Localización del nodo que almacenará el
subarchivo de datos.
2. Reserva de recursos mediante la creación del
subarchivo de datos.
3. Creación del subarchivo de metadatos.
En un Data Grid uno de los problemas
principales es la localización de recursos. Si
además se desea que ésta sea eficiente desde el
punto de vista de quién utilizará en el futuro esos
recursos y del estado del sistema, el problema se
complica.
Una complicación adicional es la
heterogeneidad de la infraestructura, donde un
nodo cercano puede no ser adecuado para servir
datos a ciertas aplicaciones (a la hora de crear un
archivo se pueden exigir unas condiciones
mínimas de distancia y rendimiento), para ello se
han de tener en cuenta diferentes métricas: de
distancia (∆), de rendimiento de red (Ν) y de
rendimiento del servidor (Π).
El sistema utiliza los siguientes pasos para la
selección de un nodo adecuado para almacenar los
datos:
1. Primero se trata de localizar un nodo con
espacio suficiente en la propia comunidad,
teniendo en cuenta las características de cada
nodo (∆, Ν, Π). De esta forma se reforzará la
localidad en el acceso entre nodos de una
misma comunidad.
2. Si en la comunidad no se encuentra ningún
nodo, el nodo central obtendrá una lista de las
comunidades que pertenecen a intragrids
interesadas en los mismos contenidos que el
archivo que se desea crear. Esta lista de
comunidades se ordenará de menor a mayor
distancia (∆) y a continuación se procederá a
consultar a las comunidades de la lista hasta
localizar un nodo que cumpla con los requisitos
de espacio, distancia y rendimiento. De esta
forma se refuerza la localidad lógica al utilizar
recursos de las intragrids.
3. Si todavía no se encuentra un nodo con recursos
suficientes o que se adapte a las características
indicadas por el cliente se tratará de localizar un
nodo del resto de comunidades del Data Grid
ordenadas por distancia (∆).
3. Algoritmo de replicación
Para tratar con el problema de la latencia en
sistemas distribuidos se pueden utilizar varios
mecanismos. La solución adoptada en la mayoría
de Data Grids es la utilización de replicación [2].
Los sistemas la replicación se han utilizado
como un mecanismo que permite proveer de datos
a las aplicaciones que hacen uso intensivo de
éstos, a la vez que proporciona tolerancia a fallos.
Sin embargo, debido a la escala del Grid, son
necesarios otros mecanismos adicionales a la
simple replicación. Por ejemplo, es necesario el
movimiento automático y transparente de datos
para poder proporcionar datos a las aplicaciones a
lo largo de todo el Grid.
Los sistemas de replicación clásicos pueden
clasificarse grosso modo en dos tipos: sistemas de
replicación estáticos y dinámicos. Los sistemas
estáticos determinan el número de réplicas y su
localización durante la creación de un archivo,
mientras que los sistemas dinámicos permiten que
la localización o el número de réplicas cambien
acorde con las necesidades de los usuarios o el
estado del sistema en cada momento.
En los primeros Data Grids [5] se utilizaban
sistemas estáticos, evolucionando estos hacia
sistemas dinámicos en los últimos años [6]. En los
sistemas dinámicos los problemas son cuándo,
dónde y qué replicar. El sistema propuesto se trata
de un sistema adaptativo que proporciona todas
estas características, además de orientarse al
incremento de prestaciones y escalabilidad en el
acceso a datos mediante la aplicación de técnicas
de E/S paralela, fragmentación y agrupación
lógica de contenidos (intragrids).
3.1. Replicación ramificada
El algoritmo propuesto en este artículo se basa en
una organización jerárquica de las réplicas, pero
en vez de replicar todo un archivo en un sitio
como hace el algoritmo de replicación jerárquico
clásico, fragmenta una réplica en varios archivos
denominados subréplicas. Cada uno de estos
fragmentos se creará en una comunidad de
almacenamiento cercana a los clientes que deseen
acceder a los datos.
A partir de una réplica raíz o archivo original
el sistema va creando subréplicas según las
necesidades de los clientes, tratando de que estas
subréplicas estén lo más cerca posible de los
clientes (ver Figura 2).
Cuando se debe crear una nueva réplica, se
calcula el número de subréplicas, el rango de
XVI Jornadas de Paralelismo, JP '2005 349
datos a que da soporte cada subréplica y se
determinan las comunidades donde se van a crear
éstas (subarchivo de metadatos + subarchivos de
datos). A continuación, se fragmenta la réplica en
el número de subréplicas deseado, teniendo en
cuenta que entre dos subréplicas no puede haber
solape de datos.
Figura 2. Ejemplo de replicación ramificada
Desde el punto de vista del cliente que abra un
archivo, una réplica se define como un conjunto
de subréplicas (archivos) que contienen todos los
datos de la réplica raíz o archivo original y donde
un bloque de datos dado solamente está presente
en una de las subréplica (no haya solape).
A B C
SITE 2
A B C D E F
SITE 1
D E F
SITE 3
F
SITE 5
D E
SITE 4
A B C D E F
Archivo con 6 bloques (A..F)
RÉPLICA RAÍZ
(Archivo Original)
D R3 E R3
SITE 6
SITE 7
RÉPLICA 3
Figura 3 - Ejemplo de selección de réplica
Para saber la carga de cada subréplica en un
momento dado, en el subarchivo de metadatos de
cada subréplica se almacenará un índice de
utilización de un archivo o réplica. Este índice es
utilizado en la localización, en la creación y en la
destrucción de réplicas.
Este índice de utilización es propio de cada
archivo o subréplica y no tiene relación con otros
archivos (o subréplicas). Es decir, la utilización de
una subréplica no está relacionada con la
utilización de sus subréplicas hijas o su réplica
padre. Se trata de un valor real entre 0 y 1 que
sirve como indicador de lo mucho o poco que es
accedida una réplica concreta.
3.2. Localización de réplicas
El problema de localización de réplicas se
puede definir de la forma siguiente: Dado un
único identificador lógico para un conjunto de
datos, determinar la localización física de una o
más copias de ese conjunto de datos
Los sistemas de localización de réplicas en los
sistemas Data Grid han evolucionado desde
directorios de archivos y réplicas, como LDAP,
hacia sistemas peer-to-peer [7], pasando por otros
mecanismos como filtros Bloom. En la sección
2.3 se presentó el mecanismo para localizar un
archivo o réplica raíz (se localiza el subarchivo de
metadatos). El sistema de localización de réplicas
utiliza este mecanismo distribuido, pero almacena
la estructura del árbol de replicación del archivo
en el subarchivo de metadatos de la réplica raíz.
Esto se hace por razones de eficiencia, ya que
siempre podrían hallarse todas las subréplicas
siguiendo el árbol de replicación.
Cuando un cliente desee obtener una lista de
todas las subréplicas de un archivo (o una sublista,
como la de réplicas hoja) accederá a la réplica raíz
para obtener la información. Esta información se
actualizará con la creación de nuevas subréplicas
y ante la desaparición o el fallo de subréplica.
Para mantener la estructura jerárquica, cada
subréplica deberá mantener información en sus
metadatos de aquellas subréplicas por debajo y
por encima de ella en la jerarquía.
3.3. Acceso y creación de réplicas
Desde el punto de vista del cliente, una réplica
está formada por un conjunto de subréplicas
cercanas que tratan de optimizar el acceso a los
datos de un archivo.
La selección de réplicas por parte de un
cliente debe tener en cuenta las características del
acceso a los datos y el coste de acceso a las
subréplicas. Es decir, se utiliza un modelo
350 Tecnologías Grid, Clusters y Plataformas Distribuidas
económico para la selección de la réplica que
produzca menor coste de acceso, pero además
para conseguir balance de carga y evitar cuellos
de botella se ha de tener en cuenta la carga de las
réplicas. Para ello se definen dos parámetros
globales: umbral de rendimiento mínimo de una
réplica (MRPT) y un umbral de utilización
máxima de una réplica (MRUT). Para la selección
de una réplica (conjunto de subréplicas) de lectura
se realizarán los siguientes pasos:
1. Se obtiene el conjunto de todas las réplicas
posibles que podrían dar soporte al rango de
datos indicado (cada réplica estará formada por
un conjunto de subréplicas).
2. Después de determinar el conjunto de réplicas
que podría utilizar el cliente, las réplicas que
contengan alguna subréplica con un índice de
utilización mayor que un umbral de utilización
máximo (Ij > MRUT) son descartadas con el
objetivo de lograr un balance de carga en el
acceso al archivo en todo el Data Grid y no
saturar solo ciertas réplicas.
3. Para seleccionar la mejor réplica para un cliente
se deben tener en cuenta las métricas (∆, Ν, Π)
para el nodo que almacena el subarchivo de
datos. Con este propósito en mente se utilizará
una función de rendimiento de acceso (f_ap)
entre el cliente (cl) y el nodo que almacena el
subarchivo de datos (s). Para la selección de la
mejor réplica se calculará para cada réplica i un
índice de rendimiento que tiene en cuenta la
función de rendimiento de acceso y el índice de
utilización del archivo para cada subréplica j de
la réplica i.
( ) ( )
i
R
j
j
i
R
s
cl
ap
f
I
PI
i
¦
=
×
−
=
1
,
_
1
(1)
4. A continuación, todas las réplicas cuyo índice
de rendimiento esté por debajo de un umbral de
rendimiento de réplica mínimo (MRPT) son
descartadas.
5. Finalmente, se selecciona la réplica con mejor
índice de rendimiento.
Si después de todo el proceso no hay réplicas
que cumplan todas las condiciones se procederá a
la creación de una nueva réplica.
La creación de nuevas réplicas se realiza
cuando un cliente necesita localizar una réplica de
un archivo y no se encuentra ninguna réplica
cercana, por lo que el sistema creará una nueva
réplica cerca del cliente, o por que las réplicas
existentes tienen una alta carga, por lo que se
realiza una nueva fragmentación aumentando el
grado del paralelismo que se puede alcanzar al
acceder al archivo.Se puede decir que un archivo
se expande hacia los clientes.
El sistema crece a partir de la réplica raíz
formando un árbol que va creciendo y que se va
ramificando mediante la fragmentación de las
réplicas en varias subréplicas (ramas) según sea
necesario, aumentando de esta forma el grado de
paralelismo.
El objetivo es crear nuevas subréplicas que
permitan que el proceso de búsqueda de réplicas
pueda llevarse a cabo en el futuro, para lo que se
tratará de fragmentar aquellas réplicas que sean
muy utilizadas y estén lejos del cliente. A la hora
de seleccionar las réplicas a fragmentar se siguen
los siguientes pasos:
1. Se selecciona el conjunto de subréplicas hoja,
las subréplicas del nivel más profundo. Para la
localización de las réplicas hoja se contactará
con el nodo que almacena el subarchivo de
metadatos de la réplica raíz que devolverá la
lista de subréplicas hoja actual.
2. Para cada subréplica se calcula el índice de
rendimiento (1-I)×f_ap(cl, s).
3. Se selecciona de entre las subréplicas aquellas
subréplicas con un índice de rendimiento menor
que el umbral MRPT. Es decir, se fragmentarán
aquellas réplicas con peor rendimiento.
4. Del conjunto de subréplicas obtenido se
seleccionan aquellas subréplicas cuyo índice de
utilización sea mayor que el umbral de
utilización MRUT. Aquellas que son más
demandadas serán fragmentadas para obtener
un balance de carga, al repartir las peticiones
entre la subréplica original y las nuevas
subréplicas (subsubréplicas) de ésta, y ya que
de esta forma los clientes pueden aumentar el
grado de paralelismo.
5. Se debe calcular el número y rango de datos de
las subsubréplicas para cada subréplica
seleccionada.
6. Cada subsubréplica se crea como un archivo
cerca del cliente. Es decir, se creará un archivo
en una comunidad de almacenamiento cercana.
Para ello el cliente iniciará el proceso de
creación de archivos y de localización de
recursos. Ya que no se quiere que todas las
subréplicas se creen en la misma comunidad,
XVI Jornadas de Paralelismo, JP '2005 351
sino que se repartan entre comunidades
cercanas se pedirá al Grid una lista de
comunidades cercanas y de entre estas
comunidades cercanas se elegirá una de forma
aleatoria para crear el archivo (subarchivo de
metadatos + archivos de datos) en ésta. En este
caso el subarchivo de metadatos y el de datos
pueden residir en la misma comunidad ya que
los metadatos no son utilizados por el sistema
de localización básico del Data Grid.
7. Por último el cliente volverá a iniciar el proceso
de búsqueda de réplicas (y también el de
creación de réplicas si es necesario) hasta que
encuentre una réplica adecuada.
4. Evaluación
Para observar la ganancia del sistema y de los
mecanismos propuestos se ha evaluado
analíticamente cada una de las características
siguientes: E/S paralela, reparto de fragmentos y
agrupación lógica (intragrids).
Para la evaluación se partirá de un modelo
analítico básico (ver Figura 4).
Figura 4. Modelo básico de acceso
Para los valores de los parámetros del disco
se han utilizado los del disco Seagate Barracuda
ST3160021A 7200RPM.
• 160 GBytes
• tseek: 8,5 ms. tlatencia: 4,16 ms
• C/H/S: 16383/16/63
• tamaño de sector: 512 bytes
• transferencia media sostenida: 32 a 58 MB/s
Se ha considerado que las redes locales (LAN)
son Fast Ethernet, cuyo ancho de banda máximo
es 100 Mbits/s = 12,5 Mbytes/s y cuyo ancho de
banda efectivo está alrededor de los 8 Mbytes/s.
Se ha considerado una latencia para la LAN de
512 microsegundos. Para la red de área amplia
(WAN) se ha considerado un ancho de banda de 1
Gigabit/s y un ancho de banda efectivo de 80
Mbytes/s. El valor de la latencia de la WAN se ha
dejado como un parámetro de los modelos para
observar la influencia de este factor en los
diferentes mecanismos propuestos.
4.1. Efectos del paralelismo
Para analizar el efecto del paralelismo en el
acceso a datos en un Data Grid y el efecto de la
WAN. Se ha calculado el tiempo de acceso para
diferentes latencias y número de subréplicas.
Figura 5. Paralelismo vs. latencia WAN
En la Figura 5 se presenta el acceso a 1 MB de
datos, que para los tamaños de archivos
manejados en Data Grids puede considerarse un
tamaño pequeño. Aun así el paralelismo permite
alcanzar un mejor rendimiento en el acceso a
datos, aún en redes de área amplia el efecto del
paralelismo se deja notar incluso para latencia de
100 ms. La ganancia aportada por el paralelismo
se encuentra en la utilización en paralelo de los
recursos de comunidades remotas (Disco y LAN
de los servidores remotos). Y si se considera que
el efecto de la latencia es prácticamente constante,
la ganancia será más notable para volúmenes
mayores de datos.
4.2. Efectos de la fragmentación
El siguiente mecanismo a analizar es la
fragmentación de réplicas. Para ello se comparará
en un escenario dado un sistema de réplicas
clásico y el propuesto en este trabajo (ver Figura 6
y Figura 7).
352 Tecnologías Grid, Clusters y Plataformas Distribuidas
En este escenario se tienen 9 comunidades
conectadas mediante varias redes (WAN). En un
ejemplo del mundo real podría tratarse por
ejemplo de una red en Madrid, otra en Barcelona
y otra en Valencia, conectadas las tres por otra
WAN. En cada una de estas redes habría tres
comunidades.
Si un cliente desea acceder a un servidor
lejano deberá hacerlo a través de tres WANs.
Figura 6. Replicación clásica
Figura 7. Replicación ramificada
En la Figura 8 y Figura 9 puede verse el tiempo
medio de acceso con clientes distribuidos
homogéneamente en todo el Grid.
En la Figura 8 se compara el tiempo medio de
los clientes en el caso de que haya 2 y 3 réplicas
completas (replicación clásica) frente a dos
configuraciones de replicación ramificada con 2
réplicas (1 réplica completa y 2 subréplicas de ½),
donde con configuraciones se hace referencia a
distribuciones distintas de las subréplicas.
Acceso a 4 MBytes de datos
1,5
2
2,5
3
3,5
4
0,005
0,030
0,055
0,080
0,105
0,130
0,155
0,180
0,205
0,230
0,255
0,280
0,305
0,330
0,355
0,380
0,405
0,430
0,455
0,480
latencia de la WAN (s)
tiempo
de
acceso
(s)
jerárquica 2 réplicas jerárquica 3 réplicas
ramificada 2 réplicas - v1 ramificada 2 réplicas - v2
Figura 8. Comparación 2 y 3 réplicas
Como se puede ver, el tiempo de acceso
medio con replicación ramificada es incluso mejor
que con 3 réplicas completas para latencias de
hasta 150 ms (tengase en cuenta que en ese caso
que atraviesan hasta 3 WAN, lo que implicaría
450 ms de latencia).
Acceso a 4 MBytes de datos
1,5
1,7
1,9
2,1
2,3
2,5
2,7
2,9
0,005
0,035
0,065
0,095
0,125
0,155
0,185
0,215
0,245
0,275
0,305
0,335
0,365
0,395
0,425
0,455
0,485
latencia WAN (s)
tiempo
de
acceso
(s)
jerárquica 3 réplicas ramificada 3 réplicas - v1 ramificada 3 réplicas - v2
Figura 9. Acceso a tres réplicas
En la Figura 9 se puede ver el resultado en el
que se comparán las configuraciones de
distribución de las Figuras 6 y 7. Como se puede
observar el tiempo medio de acceso es mucho
mejor incluso para latencias de WAN de 0,5
segundos.
4.3. Efectos de las intragrids
La entidad intragrid sirve para agrupar
lógicamente los datos más utilizados por una serie
de comunidades.
Para contrastar el efecto de las intragrids en el
acceso a los datos se compararán los modelos
anteriores con uno donde varias comunidades
están más interesadas en un archivo (es decir los
clientes de esas comunidades realizarán un gran
número de accesos a esos datos). Para ello sobre
la infraestructura utilizada anteriormente se creará
XVI Jornadas de Paralelismo, JP '2005 353
una intragrid formada por cuatro comunidades de
las nueve existentes.
La diferencia con los modelos anteriores
estriba en que los clientes no están distribuidos
homogéneamente por todo el Grid, sino que el
número de clientes que acceden desde la intragrid
será mayor que desde el resto de comunidades que
no pertenecen a la intragrid.
Acceso a archivo de 4 MBytes
1
1,5
2
2,5
3
0,005
0,035
0,065
0,095
0,125
0,155
0,185
0,215
0,245
0,275
0,305
0,335
0,365
0,395
0,425
0,455
0,485
latencia WAN (s)
tiempo
de
acceso
(s)
jerárquica ramificada v1
ramificada v2 ramificada+intragrid (80/20)
ramificada+intragrid (50/50) ramificada+intragrid (20/80)
Figura 10. Comparación de acceso con intragrids
En la Figura 11 se pueden comparar los
resultados para 3 réplicas (Figura 10) con el efecto
de la intragrid para los casos en que el 80%, 50%
y 20% de los clientes pertenecen a la intragrid.
Como se puede ver, el efecto de las intragrids
permite mejorar el rendimiento. Sin embargo, para
latencias de WAN grandes esta ventaja se reduce
debido a que aunque el porcentaje de clientes de
fuera de la intragrid sea pequeño el efecto de la
latencia empieza a ser significativo. Además, la
ventaja obtenida se reduce para tamaños de
archivo mayores, debido a que el efecto del
paralelismo se hace más patente en los clientes
lejanos.
5. Conclusiones
En este artículo se han propuesto varios
mecanismos que permiten mejorar el acceso a
datos en Data Grids. Para ello se ha utilizado una
combinación de paralelismo, fragmentación y
localidad de los datos mediante un nuevo
algoritmo de replicación.
En trabajos futuros se estudiarán los efectos
de las escrituras y actualizaciones, que debido a la
organización, paralelismo y adaptabilidad del
algoritmo de replicación permitirán obtener
tiempos de actualización mejores que otros
algoritmos.
Referencias
[1] Heinz Stockinger. Distributed Database
Management Systems and the Data Grid. 18th
IEEE Symposium on Mass Storage Systems
and 9th NASA Goddard Conference on Mass
Storage Systems and Technologies. 2001. San
Diego, CA.
[2] Chervenak, A., Foster, I., Kesselman, C.,
Salisbury, C., Tuecke, S. The Data Grid:
Towards an Architecture for the Distributed
Management and Analysis of Large Scientific
Datasets. Journal of Network and Computer
Applications. 23:187-200, 2001.
[3] Iamnitchi, A., Ripeanu, M., and Foster, I.
Locating Data in (Small-World?) Peer-to-Peer
Scientific Collaborations. First International
Workshop on Peer-to-Peer Systems,
Cambridge, Massachusetts, March 2002.
[4] Beverly Yand, Hector Garcia-Molina.
Designing a Super-Peer Network. 19th
International Conference on Data
Engineering. March 05 - 08, 2003. Bangalore,
India.
[5] Chervenak, A., Deelman, E., Foster, I.,
Iamnitchi, A., Kesselman, C., Hoschek, W.,
Kunszt, P., Ripeanu, M, Schwartzkopf, B.,
Stockinger, H., Stockinger, K., and Tierney,
B. Giggle: A Framework for Constructing
Scalable Replica Location Service.
Supercomputing’02, November, 2002.
[6] Kavitha Ranganathan, Adriana Iamnitchi and
Ian Foster, Improving Data Availability
through Dynamic Model-Driven Replication
in Large Peer-to-Peer Communities.
Workshop on Global and Peer-to-Peer
Computing on Large Scale Distributed
Systems, Berlin, May 2002.
[7] A peer-to-Peer Replica Location Service
Based on A Distributed Hash Table. Min Cai,
ann chervenak, Martin Frank. November
2004. SC2004. The International Conference
for High Performance Computing and
Communications
354 Tecnologías Grid, Clusters y Plataformas Distribuidas
Evaluación del Uso Coordinado de Infraestructuras Grid*
J.L. Vázquez-Poletti A. Fuentes E. Huedo
DACYA-UCM RedIRIS LCASAT-CAB
28040 Madrid 28020 Madrid 28850 Torrejón de Ardoz
jlvazquez@fdi.ucm.es afuentes@rediris.es Madrid
huedoce@inta.es
R.S. Montero I.M. Llorente
DACYA-UCM DACYA-UCM
28040 Madrid 28040 Madrid
rubensm@dacya.ucm.es llorente@dacya.ucm.es
Resumen
La cuantía y heterogeneidad de las infraestruc-
turas Grid plantea un interesante debate sobre
la explotación coordinada de las mismas, tan-
to desde el punto de vista del usuario, como
del propietario. En este artículo mostramos el
uso eciente y simultáneo de diferentes infraes-
tructuras Grid a través de un sistema extremo
a extremo de planicación y ejecución des-
centralizado. En particular, evaluamos el uso
coordinado de los testbeds de EGEE e IRIS-
Grid en la ejecución de una aplicación de Bio-
informática. Los resultados muestran la viabi-
lidad de construir entornos Grid desacoplados,
basados únicamente en servicios Globus y em-
pleando protocolos e interfaces que responden
a un estándar de facto, a la vez que se obtie-
nen niveles de calidad de servicio no triviales,
en términos de funcionamiento y abilidad.
*Esta investigación ha sido apoyada por el Minis-
terio de Educación y Ciencia, a través de las ayudas
TIC 2003-01321 y 2002-12422-E, y por el Instituto
Nacional de Técnica Aeroespacial Esteban Terradas
(INTA) - Centro de Astrobiología. Los autores partici-
pan en el proyecto EGEE, subvencionado por la Unión
Europea mediante el contrato IST-2004-508833.
1. Introducción
Actualmente, varios proyectos están invo-
lucrados en la construcción de infraestructu-
ras Grid, cada uno con diferentes objetivos en
mente. Pero es discutible que algunos de es-
tos proyectos adopten o no la losofía Grid, y
a qué nivel. Esta losofía, propuesta por Fos-
ter [5], establece que un Grid es un sistema que
no está sujeto a un control centralizado y basa-
do en protocolos e interfaces estándar, abiertos
y de propósito general, mientras que son capa-
ces de proporcionar cierto nivel de calidad de
servicio, en términos de seguridad, productivi-
dad, tiempo de respuesta o el uso coordinado
de diferentes tipos de recursos.
Muchas veces, existe la tentación de igno-
rar los dos primeros requisitos con el objetivo
de obtener mayores niveles de calidad de ser-
vicio. Así, la optimización ha estado siempre
enfrentada con el uso general. Sin embargo, en
el Grid, la generalidad es incluso más impor-
tante que la optimalidad o los mayores nive-
les de calidad de servicio. Por tanto, la lo-
sofía Grid conduce a entornos computaciona-
les, que denominamos desacoplados, que pre-
sentan como principales características las si-
guientes [3]: múltiples dominios de administra-
ción y autonomía, escalabilidad, heterogenei-
dad, y dinamismo o adaptabilidad.
Para tener éxito, la arquitectura del Grid
debe ser similar a la de Internet, que, en la pa-
sada década, fomentó un desarrollo y difusión
espectacular de esta tecnología, y en particu-
lar la del Web. Esta arquitectura se basa en
el principio de extremo a extremo [1]: The
basic argument is that, as a rst principle, cer-
tain required end-to-end functions can only be
performed correctly by the end-systems them-
selves.
El conjunto de herramientas Globus
se
ha convertido en un estándar de facto en la
computación Grid. La arquitectura de Globus
sigue una aproximación de reloj de arena (the
Globus hourglass), que no es nada más que un
principio de extremo a extremo. Por tanto,
en lugar de sucumbir a la tentación de modi-
car el middleware de Grid según nuestras nece-
sidades (ya que, en ese caso, la infraestructura
resultante sería especíca para una aplicación
concreta) o de homogeneizar los recursos sub-
yacentes (ya que, en ese caso, la infraestruc-
tura resultante sería un cluster), tal y como
hacen la mayoría de proyectos Grid actuales,
proponemos seguir el principio de extremo a
extremo, en el que los clientes tienen la posi-
bilidad de acceder y usar un amplio rango de
recursos usando un conjunto limitado y estan-
darizado de interfaces y protocolos, en este ca-
so aquéllos proporcionados por Globus (como
en el pasado lo fue el conjunto de protocolos
TCP/IP).
Además, la coexistencia de distintos pro-
yectos, cada uno con sus propios desarrollos,
adaptaciones y extensiones de middleware, ha-
cen plantearse la idea de usar recursos asig-
nados a distintos proyectos simultáneamente
o de contribuir los mismos recursos a más de
un proyecto. La aproximación escogida, más
en línea con la losofía Grid, es el desarro-
llo de herramientas cliente que sean capaces
de adaptarse a distintas implementaciones de
middleware, considerando además, que casi to-
dos los proyectos actuales usan Globus como
middleware básico. Por lo tanto, esto podría
conducir a un desplazamiento de la funciona-
lidad desde los recursos a los intermediarios o
a los clientes, permitiendo a los recursos ser
http://www.globus.org/
accedidos y usados de una manera estándar y
facilitando la tarea de compartir recursos entre
distintas organizaciones y proyectos.
Para los propósitos de este artículo, hemos
utilizado un banco de pruebas basado en Glo-
bus para ejecutar una aplicación de Bioinfor-
mática a través de la herramienta GridW ay .
Este banco de pruebas se construyó a partir
de recursos asignados a IRISGrid!
, la Iniciati-
va Nacional sobre Grid, y a EGEE (Enabling
Grids for E-sciencE )"
, la mayor infraestructu-
ra Grid Mundial con nivel de producción.
La estructura del artículo es como sigue: En
la Sección 2, se discuten algunos aspectos acer-
ca de las infraestructuras Grid y el middlewa-
re. El banco de pruebas resultante se describe
en la Sección 3. Finalmente, la Sección 4 pre-
senta los resultados obtenidos, y la Sección 5
termina con algunas conclusiones.
2. Infraestructura Grid
Una infraestructura Grid se descompone
normalmente en las siguientes capas [3]: apli-
caciones y portales Grid, middleware grid de
usuario, middleware Grid básico y recursos
Grid.
Las dos capas internas son denominadas el
middleware, ya que conectan las aplicacio-
nes con los recursos. En un Grid desacoplado,
es importante mantener estas capas separadas
e independientes con un conjunto limitado y
bien denido de protocolos e interfaces entre
ellas. A continuación, se describe la interrela-
ción entre estas capas en varios proyectos exis-
tentes.
El proyecto EGEE (Enabling Grids for E-
sciencE ) está creando una infraestructura
Grid con nivel de producción imponiendo un
conjunto de requisitos muy restrictivo para las
organizaciones que pretenden formar parte de
él. EGEE dene el middleware Grid de usua-
rio, el middleware Grid básico y los recursos
Grid, los cuales están estrechamente relaciona-
dos entre ellos. EGEE usa el middleware de-
http://www.gridway.org/
!http://irisgrid.rediris.es/
"http://www.eu-egee.org/
356 Tecnologías Grid, Clusters y Plataformas Distribuidas
sarrollado por LCG (LHC Computing Grid)
#
,
LCG-2, que presenta algunas limitaciones en
términos de heterogeneidad (sólo soporta la
arquitectura Intel con versiones concretas de
Linux y requiere una conguración concreta
para los clusters), y escalabilidad y compleji-
dad de su despliegue (el middleware debe ser
instalado en los nodos de cálculo y deben tener
conexión externa de red). Es quizá el hecho de
que se centra en aplicaciones de Física de Par-
tículas y su dependencia de una única organi-
zación, CERN (la Organización Europea para
la Investigación Nuclear), lo que provoca estas
limitaciones. En cualquier caso, se espera que
el nuevo middleware desarrollado en EGEE,
gLite
$
, superará de algún modo algunas de es-
tas limitaciones.
Por otro lado, la iniciativa IRISGrid tiene
como principal objetivo la creación de una in-
fraestructura Grid estable en España. La pri-
mera misión de IRISGrid es proporcionar los
protocolos, procedimientos y directrices nece-
sarios para crear un Grid de investigación en
España. Esta iniciativa persigue la unión de re-
cursos distribuidos geográcamente de manera
que todos los grupos de investigación intere-
sados puedan acceder a un banco de pruebas
donde trabajar. IRISGrid sólo dene el midd-
leware Grid básico, que puede funcionar so-
bre diferentes recursos Grid, permitiendo y, es
más, requiriendo distintos middleware Grid de
usuario para ser operativo. La primera versión
del banco de pruebas de IRISGrid se basa úni-
camente en Globus, y ha sido ampliamente uti-
lizada mediante la herramienta GridWay. En
la actualidad, se están haciendo pruebas con
la herramienta GRID Superscalar [2].
Finalmente, GridWay es un metaplanica-
dor ligero, que usa Globus como middleware
Grid básico sobre cualquier tipo de recurso
Grid. Por tanto, GridWay podría ser utiliza-
do en cualquier infraestructura Grid que usara
Globus, sin modicaciones, como middleware
Grid básico [6]. En este artículo, mostraremos
su utilización en un banco de pruebas mixto
IRISGrid/EGEE, basado en Globus. En el ca-
so de EGEE, el comportamiento de Globus se
#http://lcg.web.cern.ch/
$http://www.glite.org/
ha modicado ligeramente, pero sin perder sus
protocolos e interfaces, por lo que puede seguir
siendo usado de una manera estándar.
Un aspecto clave en estas alternativas
de middleware Grid de usuario (EGEE y
GridWay), es cómo se realiza la ejecución de
los trabajos y, en particular, la transferencia
de cheros de entrada y salida. En EGEE, las
transferencias de cheros son iniciadas por un
envoltorio de trabajos que se envía a los nodos
de cálculo. En GridWay, la ejecución de traba-
jos se realiza en tres pasos: prólogo (prepara el
sistema el sistema remoto), envoltorio (ejecuta
el trabajo real y obtiene su código de estado de
salida) y epílogo (naliza el sistema remoto).
De esta forma, GridWay no depende del
middleware subyacente para realizar las tareas
de preparación y nalización del sistema remo-
to. Es más, dado que, en el caso de clusters,
tanto el prólogo como el epílogo se envían al
nodo frontal mientras que el envoltorio se en-
vía al nodo de cálculo (a través del gestor de
colas), GridWay no requiere la instalación de
ningún middleware ni la conexión externa de
red en los nodos de cálculo.
3. Banco de Pruebas Experimental
Este artículo no hubiera sido posible sin la
inestimable colaboración de diversas univer-
sidades y centros de investigación españoles,
que compartieron sus recursos computaciona-
les para congurar un banco de pruebas geo-
grácamente distribuido. El banco de pruebas
resultante está caracterizado por un alto gra-
do de heterogeneidad, apreciable en todos los
niveles que conforman la infraestructura, a sa-
ber:
- Infraestructura, los recursos del banco de
pruebas son de diferentes tipos desde esta-
ciones de trabajo o servidores SMP, hasta
clusters basados en diferentes arquitectu-
ras (Alpha e Intel).
- Gestores locales, los nodos computaciona-
les están gestionados por diferentes siste-
mas de gestión de recursos distribuidos
(Distributed Resource Management Sys-
tems, DRMS), como Portable Batch Sys-
XVI Jornadas de Paralelismo, JP '2005 357
tem (PBS), Sun Grid Engine (SGE) o
fork.
- Red de interconexión, los diferentes sitios
que forman parte del banco de pruebas
están conectados por una red pública no
dedicada, que resulta en latencias y an-
chos de banda variables.
- Middleware, a pesar de que el banco de
pruebas nal esta constituido por dos
Grids basados en el Globus Toolkit, es-
tos dieren en su arquitectura y en los
servicios que ofrecen.
Los diferentes centros que participaron de
este banco de pruebas, participan activamente
en IRISGrid y EGEE. IRISGrid es el banco de
pruebas resultado de la Acción especial Pre-
paración de Proyectos GRID en el marco de
las iniciativas de e-ciencia en Europa. En esta
Acción colaboran más de 40 grupos de inves-
tigación españoles de diferentes instituciones.
Actualmente, el banco de pruebas IRISGrid
cuenta con 16 sitios, 7 de los cuales participa-
ron en los experimentos que se analizan a con-
tinuación. En total el número de CPUs agre-
gadas de estos centros asciende a 209. Las ca-
racterísticas más importantes de los recursos
IRISGrid se muestran en el cuadro 1.
El resto de entros forman parte de EGEE.
Este proyecto europeo cuenta con más de 100
socios. En particular, los resultados mostra-
dos en este trabajo se obtuvieron con la par-
ticipación de 7 centros españoles del proyecto
EGEE, que suponen un total de 404 CPUs. En
el cuadro 1 se muestran las principales carac-
terísticas de estos recursos.
De forma agregada, el banco de prue-
bas nal consta de 13 sitios (destacar, que
LCASAT-CAB aporta recursos tanto al ban-
co de pruebas EGEE, como IRISGrid), y ofre-
ce un total de 613 CPUs. En los experimentos
que se describen a continuación, hemos limita-
do a 4 el número de trabajos que se ejecutan
simultáneamente al mismo recurso Grid para
no saturar el banco de pruebas completo, da-
do que algunos de los centros participan en
experimentos de producción correspondientes
al Large Hadron Collider (LHC).
Los centros anteriores están interconectados
por RedIRIS, la red académica y cientíca es-
pañola (NREN). En la Figura 1 se muestra la
localización y enlaces de interconexión de los
diferentes nodos.
Figura 1: Topología y anchos de banda de
RedIRIS-2.
Finalmente en el cuadro 2 se resumen las
principales características y conguraciones de
cada componente del middleware Grid (Glo-
bus Toolkit), usado en los resultados que se
presentan más adelante. Además, a continua-
ción se detallan las modicaciones que tuvie-
ron que realizarse en la infraestructura y el
sistema de planicación para permitir la in-
teroperabilidad de los dos Grids:
- Infraestructura de Seguridad. La au-
tenticación se realizó usando certica-
dos de usuarios emitidos por la entidad
DATAGRID-ES CA, lo que supuso aña-
dir el nivel de conanza a esta entidad
en todos los recursos IRISGrid. Por otro
lado, la autorización se realizó explícita-
mente al usuario con el que se ejecutaron
las pruebas tanto en los recursos de IRIS-
Grid como en los de EGEE.
- Servicios de Información y Selector
de Recursos. Para poder usar de forma
conjunta los recursos de ambos bancos de
prueba se desarrolló un selector de recur-
sos que combinase la información del es-
tado de éstos, expresada usando los es-
quemas MDS, en IRISGrid, y GLUE, en
358 Tecnologías Grid, Clusters y Plataformas Distribuidas
Cuadro 1: Recursos del banco de pruebas IRISGrid y EGEE usados en las pruebas experimentales.
∗
hydrus actúa como cliente para almacenar los archivos de entrada y ejecutable, y para recoger
los resultados del experimento.
Nombre Sitio Proc. Rec. Velocidad DRMS Infraestructura
heraclito RedIRIS Intel Celeron 1 700MHz Fork IRISGrid
platon RedIRIS 2 × Intel PIII 1 1.4GHz Fork IRISGrid
descartes RedIRIS Intel P4 1 2.6GHz Fork IRISGrid
socrates RedIRIS Intel P4 1 2.6GHz Fork IRISGrid
aquila DACYA-UCM Intel PIII 1 700MHz Fork IRISGrid
cepheus DACYA-UCM Intel PIII 1 600MHz Fork IRISGrid
cygnus DACYA-UCM Intel P4 1 2.5GHz Fork IRISGrid
hydrus∗
DACYA-UCM Intel P4 1 2.5GHz - IRISGrid
babieca LCASAT-CAB Alpha EV67 30 450MHz PBS IRISGrid
bw CESGA Intel P4 80 1.2GHz Fork IRISGrid
llucalcari IMEDEA AMD Athlon 14 800MHz PBS IRISGrid
augusto DIF-UM 4 × Intel Xeon 1 2.4GHz Fork IRISGrid
caligula DIF-UM 4 × Intel Xeon 1 2.4GHz Fork IRISGrid
claudio DIF-UM 4 × Intel Xeon 1 2.4GHz Fork IRISGrid
lxsrv1 BIFI-UNIZAR Intel P4 50 3.2GHz SGE IRISGrid
ce00 LCASAT-CAB Intel P4 8 2.8GHz PBS EGEE
mallarme CNB 4 × Intel Xeon 8 2GHz PBS EGEE
lcg02 CIEMAT Intel P4 6 2.8GHz PBS EGEE
grid003 FT-UAM Intel P4 49 2.6GHz PBS EGEE
gtbcg12 IFCA 2 × Intel PIII 34 1.3GHz PBS EGEE
lcg2ce IFIC AMD Athlon 117 1.4GHz PBS EGEE
lcgce02 PIC Intel P4 69 2.8GHz PBS EGEE
EGEE. El acceso a los servidores de in-
formación GISS (Grid Information Index
Service) y BDII (Berkeley Database In-
formation Service) es homogéneo, ya que
ambos usan LDAP como interfaz de ac-
ceso. La principal diferencia entre ambos
sistemas es que BDII usa una base de da-
tos persistente que se actualiza periódica-
mente, lo que resulta en un menor tiempo
de acceso y eciencia.
La clasicación nal de los recursos se rea-
liza mediante la asignación de un rango
que reeja la idoneidad de cada uno en
términos de las características propias de
la aplicación. En este caso, dado que la
aplicación es intensiva en cálculo, se pri-
mará el rendimiento pico de la CPU de
cada recurso.
- Servicios de Ejecución. Debido a que
el middleware Grid del banco de prue-
bas EGEE no requiere la compartición
de los directorios de usuarios en arquitec-
turas en cluster, el módulo de ejecución
(MH=FFAH) debe realizar en estos casos un
transferencia explícita de cheros entre el
front-end, y los nodos del cluster.
4. Resultados Experimentales
Los resultados presentados en esta sección
consisten en el análisis de una familia de 80
proteínas ortólogas de la enzima Triosa Fos-
fata Isomerasa [4]. Con objeto de capturar
la variabilidad del entorno fueron realizados
cinco experimentos en diferentes días durante
una semana. El tiempo medio de respuesta de
la aplicación durante estas ejecuciones fue de
XVI Jornadas de Paralelismo, JP '2005 359
Cuadro 2: Middleware Grid básico.
Componente Globus IRISGrid EGEE
Infraestructura de
Seguridad
IRISGrid CA y generación manual
de archivos de autorización
DATAGRID-ES CA y generación
automática de archivos de
autorización
Gestión
de Recursos GRAM con directorios de usuario
compartidos (clusters)
GRAM sin compartición de
directorios de usuario (clusters)
Servicios
de Información IRISGrid GIIS Y GRIS locales, con
esquema MDS
CERN BDII y GRIS locales, con
esquema GLUE
Gestión
de Datos GASS y GridFTP GASS y GridFTP
43.37 minutos.
El cuadro 3 reeja los tiempos medios de
transferencia y ejecución, y su desviación típi-
ca, para cada host, en la resolución de una úni-
ca tarea de la simulación total. Estos tiempos
incluyen la sobrecarga inducida por el midd-
leware Grid. La desviación típica es un indi-
cador del dinamismo del entorno ya que se
calcula sobre el mismo recurso a lo largo del
tiempo. Como puede verse, los recursos con
procesadores más rápidos presentan un tiem-
po de ejecución medio más bajo (lxsrv1, bw,
grid003 y lcgce02). Algunos recursos presentan
además una desviación mayor en el tiempo de
ejecución, debida a la sobrecarga en su siste-
ma de colas y a un nodo front-end lento (lcg02,
ce00 y lcg2ce). El uso de nodos SMP (platon,
augusto, caligula y claudio) causa una mayor
variabilidad en el tiempo de ejecución cuando
todas las CPUs son usadas simultáneamente
debida al uso competitivo de sus recursos com-
partidos.
Analizando los tiempos de transferencia, ve-
mos como los sitios bien conectados con la má-
quina cliente en DACYA-UCM, presentan una
media más pequeña (DACYA-UCM, RedIRIS
y FT-UAM) a no ser que tengan un nodo front-
end lento (LCASAT-CAB, IFIC y CIEMAT).
Los sitios con peor conectividad con el clien-
te presentan un mayor tiempo de transferencia
medio y variabilidad (IFCA, IMEDEA, BIFI-
00
00
11
11
00
00
11
11 0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
00
00
00
00
00
00
00
00
00
00
00
00
00
11
11
11
11
11
11
11
11
11
11
11
11
11
0
0
1
1
0
0
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
1
1
00
00
11
11 0
0
1
1 0
0
1
1
00
00
11
11
00
00
00
11
11
11
00
11
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
10
20
30
40
50
60
70
80
Ejecuciones
Falladas
Suspendidas
Completadas
RedIRIS
DACYA−UCM
LCASAT−CAB
CESGA
IMEDEA
DIF−UM
BIFI−UNIZAR
CNB
IFIC
IFCA
FT−UAM
CIEMAT
PIC
Figura 2: Planicación agregada realizada
por Grid9ay durante los cinco experimentos.
UNIZAR y DIF-UM).
Además, durante el desarrollo de cada si-
mulación, algunas de las ejecuciones no fueron
exitosas o la tarea fue suspendida durante de-
masiado tiempo. Estos hechos provocaron que
el sistema de planicación migrara a otro re-
curso estos trabajos. En la gura 2 se muestra
la distribución del número total de ejecuciones
por sitio y los fallos experimentados.
Uno de los aspectos fundamentales de la eva-
luación del rendimiento de un sistema es la
capacidad para realizar predicciones. En este
sentido, resulta interesante analizar el bene-
cio que obtiene cada sitio por formar parte del
360 Tecnologías Grid, Clusters y Plataformas Distribuidas
Cuadro 3: Tiempos de ejecución y transferencia (en segundos) para cada trabajo en los recursos
de IRISGrid y EGEE.
Tiempo de Ejecución Tiempo de Transferencia
Recurso Media Dev. Media Dev. Sitio
heraclito 2146 57 150 107 RedIRIS
platon 919 275 67 50 RedIRIS
descartes 611 33 48 30 RedIRIS
socrates 647 103 51 27 RedIRIS
aquila 1895 235 143 93 DACYA-UCM
cepheus 2022 112 64 24 DACYA-UCM
cygnus 755 74 33 20 DACYA-UCM
babieca 1798 28 131 131 LCASAT-CAB
bw 697 176 123 54 CESGA
llucalcari 1567 168 169 92 IMEDEA
augusto 1200 233 89 61 DIF-UM
caligula 1242 233 153 109 DIF-UM
claudio 1228 184 187 131 DIF-UM
lxsrv1 687 190 152 92 BIFI-UNIZAR
ce00 929 267 220 80 LCASAT-CAB
mallarme 945 191 123 68 CNB
lcg02 932 342 158 115 CIEMAT
grid003 739 63 90 67 FT-UAM
gtbcg12 1002 52 261 105 IFCA
lcg2ce 889 226 208 113 IFIC
lcgce02 777 179 98 68 PIC
Grid. Denimos, así la ganancia Grid como:
SSite =
TSite
TGrid
, (1)
donde TGrid es el tiempo de ejecución usando
todos los recursos del Grid, y TSite es el tiem-
po de ejecución cuando la simulación se realiza
únicamente en los recursos disponibles en un
sitio dado. En este caso, estimaremos el tiem-
po óptimo de ejecución de cada sitio (Tsite),
calculando el makespan óptimo de la aplica-
ción [8].
La gura 3 muestra la ganancia (barras del
gráco) y el tiempo de respuesta de cada sitio
(valores asociados a cada barra). Es importan-
te recordar que se ha limitado a 4 el número de
trabajos que simultáneamente se pueden eje-
cutar en cada sitio. Finalmente, en la gura 4
podemos comparar la productividad dinámica
obtenida por todo el Grid frente al stio con
mayor potencia computacional (DIF-UM, en
este caso).
5. Conclusiones
En este artículo hemos demostrado que es
posible aplicar el principio de extremo-a-
extremo en la parte cliente, esto es el midd-
leware Grid de usuario. El sistema de plani-
cación y ejecución de usuario propuesto pue-
de trabajar satisfactoriamente con middleware
Grid básico, en cualquier infraestructura Grid
de forma débilmente acoplada. Además, da-
do que un análisis similar ha sido previamente
realizado en la parte de los recursos [7], esto
es en la infraestructura Grid, podemos con-
cluir que el principio de extremo-a-extremo
es aplicable en ambos lados.
La facilidad de integración de los tan dife-
rentes bancos de prueba analizados, a pesar de
XVI Jornadas de Paralelismo, JP '2005 361
3.8h
9.5h
3.4h
8.7h
2.3h
3.8h
5.3h 5.2h
5.6h
4.1h
4.9h
4.3h
3.9h
0.7h
LCASAT−CAB
RedIRIS
CESGA
IMEDEA
DIF−UM
BIFI−UNIZAR
CNB
FT−UAM
CIEMAT
IFCA
IFIC
PIC
All
0
2
4
6
8
10
12
14
Ganancia
del
Grid
DACYA−UCM
Figura 3: Ganancia Grid estimada y tiempos de
respuesta por sitio.
1.90
1.80
1.74
1.59
0.59
2.37
Exp 5
Exp 4
Exp 3
Exp 2
Exp 1
0
0.5
1
1.5
2
2.5
0 10 20 30 40 50 60 70 80
Productividad
(ejecuciones/minuto)
Ejecuciones completadas
DIF-UM
Figura 4: Productividad dinámica obtenida.
que ambos están basados en Globus, demues-
tran que una arquitectura descentralizada y
extremo-a-extremo de planicación es apro-
piada para el Grid.
Por otro lado, la evaluación de entornos
Grid desde el punto de vista de la aplicación se
ha conseguido mediante el establecimiento de
un conjunto de métricas apropiadas. En par-
ticular mediante el uso de la Ganancia Grid,
tiempos de transferencia y ejecución, así como
un análisis de la variabilidad que presentan es-
tas medidas.
6. Agradecimientos
La realización de este trabajo ha sido posi-
ble gracias a la inestimable colaboración de to-
das aquellas instituciones que participan en las
iniciativas IRISGrid y EGEE, y especialmente
aquellas que colaboraron en las simulaciones
aportando recursos y atendiendo los requeri-
mientos del equipo de investigación (véase el
cuadro 1).
Referencias
[1] Editor B. Carpenter. RFC 1958: Architec-
tural Principles of the Internet, June 1996.
Category: Informational.
[2] Rosa M. Badia, Jesús Labarta, Raül Sir-
vent, Josep M. Pérez, José M. Cela, and
Rogeli Grima. Programming Grid Appli-
cations with GRID Superscalar. J. Grid
Computing, 1(2):151170, 2003.
[3] Mark Baker, Rajkumar Buyya, and Dome-
nico Laforenza. Grids and Grid Techno-
logies for Wide-Area Distributed Compu-
ting. Software  Practice and Experience,
32(15):14371466, 2002.
[4] U. Bastolla, A. Moya, E. Viguera, and
R. van Ham. Genomic Determinants of
Protein Folding Thermodynamics. (en pre-
paración), 2004.
[5] I. Foster. What Is the Grid? A Three Point
Checklist. GRIDtoday, 1(6), 2002. Availa-
ble at http://www.gridtoday.com/.
[6] E. Huedo, R. S. Montero, and I. M. Lloren-
te. A Framework for Adaptive Execution
on Grids. Intl. J. Software  Practice and
Experience (SPE), 34(7):631651, 2004.
[7] O. San José, L. M. Suárez, Eduardo Hue-
do, Rubén S. Montero, and Ignacio Martín
Llorente. Resource Performance Manage-
ment on Computational Grids. In Proc.
2nd Intl. Symp. Parallel and Distributed
Computing (ISPDC 2003), pages 215221,
2003.
[8] M. Pinedo. Scheduling: Theory, Algo-
rithms, and Systems. Prentice Hall, New
Jersey, NJ, second edition, 2002.
362 Tecnologías Grid, Clusters y Plataformas Distribuidas

          
      
             
  
    

 
            
                   ! " # $    %  ! " # &  ' (     )  
  ' * +  + "  "    #   ,  - . ' /  0   "  / # "  &  ' &  /   1  # "
2 3 4 5 6 7 3 8 9 3 : 5 ; < = > : ? @ A B C 4 D 5 ? : > < =
E = > F 3 ; G > 7 ? 7 7 3 H ? = 5 > ? I B 7 3 A B C 4 B G 5 3 9 ?
J K L M N
H ? = 5 > ? I B 7 3 A B C 4 B G 5 3 9 ?
O P
D 9 > B Q 7 > 3 I B ; C Q C ? ; : B G Q : ? R ? Q 5 B C ? G Q
S
; ? = T U 7 3 : 6 D G : 6 3 G
V W X Y Z W [
\ ] ^ _ ` a ` b c ` c _ d e d f g a ` h ` b c _ d ` b ] d i ` j b k h k l b
i ` m b n g i ` ] g i ` _ ` b i k n k ` b c g ^ d _ d ] d ^ _ ` i k h o
h k l b i ` ] c k ` n ^ g i ` ` f ` h m h k l b i ` ] g a h g n ^ g o
b ` b c ` a h g n ^ m c d h k g b d ] n ` b c ` n p a h g a c g a g a i `
m b d d ^ ] k h d h k l b q _ k i h g b h _ ` c d r s k h t d d ^ ] k h d o
h k l b d e g _ i d ] d c g n d i ` i ` h k a k g b ` a ` b a k c m d o
h k g b ` a h _ u c k h d a i ` e k i g d ] _ k ` a v g i ` k b m b i d h k g o
b ` a w x a ` ` b v ] g e d ` b ` ] h g b c ` y c g i ` ] ^ _ g x ` h c g
z
_ g a a q _ k i { | } r ~ b d _ ` a ^ m ` a c d ` b c k ` n ^ g _ ` d ]
` a k n ^ _ ` a h k b i k e ] ` ` b ` a c ` c k ^ g i ` d ^ ] k h d h k g b ` a w
^ g _ ] g  m ` i k a ^ g b ` _ i ` k b € g _ n d h k l b _ ` a ^ ` h c g d
a m h g n ^ g _ c d n k ` b c g h g n ^ m c d h k g b d ] ` a n m x k n o
^ g _ c d b c ` r
 ‚ ƒ
[ „ … † ‡ Y ˆ ˆ ‰ Š [
‹ d ` f ` h m h k l b i ` d ^ ] k h d h k g b ` a h g n ^ m c d h k g b d ] o
n ` b c ` k b c ` b a k Πd a a g e _ ` ` b c g _ b g a q _ k i ^ _ ` a ` b c d
^ _ g e ] ` n d a d i k h k g b d ] ` a d ] d h g n ^ m c d h k l b c _ d i k o
h k g b d ] w i ` e k i g d ] d t ` c ` _ g v ` b ` k i d i i ` _ ` h m _ a g a
i ` ` a c ` ` b c g _ b g r
‹ g a ` b c g _ b g a q _ k i a g b ` b c g _ b g a i k b p n k h g a
i ` v _ d b p n e k c g w  m ` _ `  m k ` _ ` b m b d ^ ] d b k j h d o
h k l b h g n ^ ] ` f d w ] g  m ` i k j h m ] c d ` b g _ n ` n ` b c `
] d ` a c k n d h k l b i ` ] c k ` n ^ g b ` h ` a d _ k g ^ d _ d ] d ` f ` o
h m h k l b i ` m b d d ^ ] k h d h k l b r
‹ d ` Œ d ] m d h k l b i ` _ ` b i k n k ` b c g w k b a c _ m n ` b c d o
h k l b w ^ _ ` i k h h k l b x Œ k a m d ] k  d h k l b i ` h l i k v g a ^ d o
_ d ] ` ] g a ` a m b h g n ^ ] ` f g ^ _ g e ] ` n d n m ] c k i k n ` b o
a k g b d ] { | Ž } ` b a k a c ` n d a ^ d _ d ] ` ] g a x i k a c _ k e m k i g a 
a k c m d h k l b  m ` a ` c g _ b d n p a h _ u c k h d ` b ] g a ` b o
c g _ b g a q _ k i r
z
m d b i g a ` ^ _ g v _ d n d b ` a c g a a k a o
c ` n d a w ] d a _ d  g b ` a ^ g _ ] d a h m d ] ` a ] g a h l i k v g a
^ d _ d ] ` ] g a ^ _ ` a ` b c d b e d f d `
j h k ` b h k d ^ m ` i ` b a ` _
Œ d _ k d i d a x h g n ^ ] ` f d a  x ] g a m a m d _ k g a b ` h ` a k o
c d b ^ g i ` _ ` b c ` b i ` _ x h g _ _ ` v k _ ] g a ^ _ g e ] ` n d a i `
_ ` b i k n k ` b c g ^ d _ d ] g v _ d _ d ] h d b  d _ e m ` b g a _ ` a m ] o
c d i g a r \ a c g ` a ` a ^ ` h k d ] n ` b c ` _ ` ] ` Πd b c ` h m d b i g
a ` m a d b ] k e _ ` _ u d a x ] ` b v m d f ` a i ` d ] c g b k Π` ] ^ d _ d
k n ^ ] ` n ` b c d _ ^ _ g v _ d n d a ^ d _ d ] ` ] g a r
\ ] ^ _ g x ` h c g
z
_ g a a q _ k i w i ` b c _ g i ` ] h m d ] a `
` b n d _ h d ` a c ` ` a c m i k g w a ` t d g _ k ` b c d i g d d ^ ] k o
h d h k g b ` a i ` h p ] h m ] g k b c ` b a k Πg x  m ` n d b ` f d b m b
v _ d b Œ g ] m n ` b i ` i d c g a  h d _ d h c ` _ k  d i d a d i ` n p a
^ g _ ] d k b c ` _ d h h k l b h g b ` ] m a m d _ k g i m _ d b c ` ] d a
k c ` _ d h k g b ` a i ` ^ _ g h ` a g r
s ` b c _ g i ` ` a c ` ^ _ g x ` h c g w b m ` a c _ g v _ m ^ g t d
k n ^ ] ` n ` b c d i g m b d t ` _ _ d n k ` b c d i ` ^ _ ` i k h h k l b
i ` _ ` b i k n k ` b c g i ` ] d a d ^ ] k h d h k g b ` a k b h ] m k i d a ` b
` ] n k a n g  ‘ ‘
z
w ‘ ` _ € g _ n d b h ` ‘ _ ` i k h c k g b
z
g n o
^ g b ` b c { ’ } “ w x ` a ` b ` a c ` n d _ h g ` b ` ]  m ` a `
a k c ” d ` a c ` c _ d e d f g r
• d ` b ] d h g n ^ m c d h k l b h g b Œ ` b h k g b d ] b g k b o
c ` _ d h c k Πd w ] d ^ _ ` i k h h k l b i ` _ ` b i k n k ` b c g _ ` Πk a c `
v _ d b k n ^ g _ c d b h k d  c d b c g ^ g _ ] d b ` h ` a k i d i i `
m b d v ` a c k l b d i ` h m d i d i ` ] g a _ ` h m _ a g a w h g n g
^ g _ ] d i ` c ` _ n k b d h k l b i ` ] d ^ _ ` h k a k l b x i k Π` _ o
a k i d i i ` d b p ] k a k a d a m n k e ] ` ` b m b c k ` n ^ g d h ` ^ o
c d e ] ` r \ b ] g a ` b c g _ b g a k b c ` _ d h c k Πg a ] d a k c m d h k l b
a ` Œ m ` ] Œ ` d ” b n p a h _ u c k h d i ` e k i g d ] d b ` h ` a k i d i
i ` a k b h _ g b k  d h k l b h g b ] d a i ` h k a k g b ` a i ` ] d v ` b c `
t m n d b g r
~ b d i ` ] d a d ^ ] k h d h k g b ` a i ` a d _ _ g ] ] d i d i ` b c _ g
i ` ] ^ _ g x ` h c g
z
_ g a a q _ k i h g b a k a c ` ` b m b a k a c ` n d
i ` a g ^ g _ c ` ^ d _ d m b d g _ v d b k  d h k l b Œ k _ c m d ] e d o
a d i d ` b q _ k i ^ d _ d ] d ^ _ ` i k h h k l b i ` k b m b i d h k g o
b ` a r \ a c d g _ v d b k  d h k l b Œ k _ c m d ] d a g h k d m b h g b o
f m b c g i ` k b i k Πk i m g a ` k b a c k c m h k g b ` a i ` i k h d i g a
d ] d ^ _ ` Π` b h k l b i ` k b m b i d h k g b ` a x ^ _ g c ` h h k l b
€ _ ` b c ` d ` ] ] d a r ` ` n ^ ] ` d c ` h b g ] g v u d q _ k i ^ d _ d
h g b ` h c d _ h g b f m b c d n ` b c ` ` y ^ ` _ c g a w _ ` ^ g a k c g _ k g a
i ` i d c g a x _ ` h m _ a g a h g n ^ m c d h k g b d ] ` a  € d h k ] k c d b o
i g ] d c g n d i ` i ` h k a k g b ` a € _ ` b c ` d k b m b i d h k g b ` a
i ` € g _ n d p v k ] x d i ` h m d i d r
\ ] h g n ^ g b ` b c ` ^ _ k b h k ^ d ] i ` ] d d ^ ] k h d h k l b ` a
m b a k a c ` n d d m c g n d c k  d i g i ` d Œ k a g c ` n ^ _ d b g
e d a d i g ` b n g i ` ] g a t k i _ g o n ` c ` g _ g ] l v k h g a w x a k o
n m ] d h k l b i ` ^ _ ` h k ^ k c d h k g b ` a r


i ` n p a w a ` k b c ` v _ d b c  h b k h d a i ` h g n m b k h d o
h k l b  m ` ^ ` _ n k c ` b d ] g a `  m k ^ g a i ` h g b c _ g ] i `
h _ k a k a h g b a m ] c d _ ] d c g n d i ` i ` h k a k g b ` a h g b Πd o
_ k g a ` y ^ ` _ c g a r


a k n k a n g w ] g a ` y ^ ` _ c g a i ` e ` b
a ` _ h d ^ d h ` a i ` ` f ` h m c d _ ] d a a k n m ] d h k g b ` a h g b
i k a c k b c g a ^ d _ p n ` c _ g a ^ d _ d d b d ] k  d _ ` ] k n ^ d h c g
i ` ] d a k c m d h k l b r \ ] m a g i ` _ ` h m _ a g a q _ k i ` a Πk c d ]
i ` e k i g d  m ` ] d a a k n m ] d h k g b ` a a ` i ` e ` b ` f ` h m o
c d _ _ p ^ k i d n ` b c ` ^ d _ d i d _ m b d _ ` a ^ m ` a c d ” c k ] d ]
^ _ g e ] ` n d r
 d a p b i g a ` ` b ] g a n g i ` ] g a h m d b c k c d c k Πg a i `
^ _ ` h k ^ k c d h k g b ` a w ] g a n g i ` ] g a t k i _ g ] l v k h g a a g b
m c k ] k  d i g a ^ d _ d i ` c ` _ n k b d _ ] d i ` a h d _ v d i ` a i `
` ] p _ ` d d € ` h c d i d  x h g b ` a c d k b € g _ n d h k l b w ] g a
n g i ` ] g a t k i _ p m ] k h g a a k n m ] d b ` ]  m f g i ` ] d v m d
a g e _ ` i k Π` _ a g a ` a c _ m h c m _ d a  m Πk d ] ` a ^ d _ d ^ _ ` o
i ` h k _ ` ] k n ^ d h c g i ` ] d h g _ _ k ` b c ` r
 m ` a c _ g ` a c m i k g a ` h ` b c _ d ` b ] g a e ] g  m ` a
h g n ^ m c d h k g b d ] n ` b c ` k b c ` b a k Πg a i ` ] h l i k v g i `
n g i ` ] d i g t k i _ g i k b p n k h g  \   { }  x ` ]
^ g a c ` _ k g _ i k a `
g i ` m b n g i ` ] g i ` ^ _ ` i k h h k l b
i ` _ ` b i k n k ` b c g ^ d _ d ` a c g a r
 ‚ 
† ‡ W † X ‡ W … W [ ‡ ‰ Z ‰ W [ „ †
\ b ] d h g n ^ m c d h k l b i ` d ] c d a ^ _ ` a c d h k g b ` a w ] d ` j o
h k ` b h k d i ` ] d a d ^ ] k h d h k g b ` a ` a n m x a ` b a k e ] ` d
^ _ g e ] ` n d a h g n g ] d i k a c _ k e m h k l b i ` ] g a i d c g a x
^ d _ p n ` c _ g a i ` h g n ^ m c d h k l b x h g n m b k h d h k g b ` a r
‹ d ^ _ ` i k h h k l b i ` _ ` b i k n k ` b c g ` a m b d k n ^ g _ c d b o
c ` t ` _ _ d n k ` b c d i ` k b v ` b k ` _ u d w  m ` ^ _ g ^ g _ h k g b d
] d k b € g _ n d h k l b g ^ g _ c m b d ` b ] d ` ] ` h h k l b i ` ] i k o
a `
g w ` b ] d a u b c ` a k a i ` ^ _ g v _ d n d a x ` b ` ] i ` a d o
_ _ g ] ] g i ` d _  m k c ` h c m _ d a r


i ` n p a i ` ] d ` y d h c k c m i i ` ] d ^ _ ` i k h h k l b w ` ]
h g a c ` ^ d _ d h g n ^ m c d _ ] d i ` c ` _ n k b d a m m c k ] k i d i r
\ y k a c ` b n ” ] c k ^ ] ` a ` b € g  m ` a ^ d _ d ]
d ^ _ ` i k h h k l b
i ` _ ` b i k n k ` b c g w x ] d ` ] ` h h k l b a ` Π` i ` c ` _ n k b d o
i d ^ g _ ` ] h g n ^ _ g n k a g ` b c _ ` ` y d h c k c m i x h g a c `
h g n ^ m c d h k g b d ] i ` ] d ^ _ ` i k h h k l b r


^ ` a d _ i ` a m
^ g c ` b h k d ] ^ _ ` h k a k l b w n g i ` ] g a € g _ n d ] ` a c d ] ` a h g o
n g ] d a _ ` i ` a i ` ‘ ` c _ k ` a c g h p a c k h d a { |  } g p ] v ` o
e _ d a i ` ^ _ g h ` a g a { | } b g a g b a g ] m h k g b ` a d c _ d h c k o
Πd a i ` e k i g d a m h g a c ` h g n ^ m c d h k g b d ] ` y ^ g b ` b o
h k d ] r  b h ] m a g d ^ _ g y k n d h k g b ` a e d a d i d a ` b h g n o
e k b d h k g b ` a i ` v _ d € g a i ` c d _ ` d a i k _ k v k i g a d h u h ] k o
h g a x _ ` i ` a i ` h g ] d a { Ž w |  } w  m ` ^ _ g ^ g _ h k g b d b
m b v _ d b ^ g i ` _ i ` n g i ` ] d i g h g b m b d d ] c d ` j o
h k ` b h k d w ^ _ ` a ` b c d b m b c k ` n ^ g i ` ^ _ g h ` a d i g i `
h g n ^ ] ` f k i d i ^ g ] k b l n k h d  ] g h m d ] a m ^ g b ` m b h g a o
c ` k b d a m n k e ] ` ^ d _ d ^ _ g e ] ` n d a i ` v _ d b c d n d
g r
‹ g a n g i ` ] g a i ` _ ` b i k n k ` b c g i ` d ^ ] k h d h k g b ` a
c d n e k  b b g a ^ ` _ n k c ` b ] d i k a c _ k e m h k l b ` j h k ` b c `
i `  a c d a a g e _ ` m b ` b c g _ b g q _ k i r \ b € m b h k l b i `
] g a _ `  m ` _ k n k ` b c g a w a ` _ p b n p a i ` c ` _ n k b d b c ` a d
] d t g _ d i ` d a k v b d _ _ ` h m _ a g a d a ^ ` h c g a h g n g ] d
^ g c ` b h k d i ` ^ _ g h ` a g k b i k Πk i m d ] w ] d a h d _ d h c ` _ u a o
c k h d a i ` ] d _ ` i g ` ] m a g i ` m b n d x g _ b ” n ` _ g i `
b g i g a  ` k b h ] m a g a ` ^ m ` i ` ` a c d e ] ` h ` _ a k ] d ` f ` o
h m h k l b ^ d _ d ] ` ] d b g ` a ` j h k ` b c ` i ` e k i g d ] h g a c `
i ` ] d a h g n m b k h d h k g b ` a r ‹ g a n g i ` ] g a c d n e k  b
b g a ^ ` _ n k c ` b w ^ d _ d a k n m ] d h k g b ` a i `         
 
  

        w ` a c k n d _ ` ] h g b f m b c g i ` i d c g a
 m ` ^ g i ` n g a d b d ] k  d _ x h g b  m  ^ _ ` h k a k l b  c d o
n d
g i ` n d ] ] d i g w k b c ` _ Œ d ] g a c ` n ^ g _ d ] ` a w r r r “
` b m b c k ` n ^ g d a m n k e ] ` r
‹ d ^ g a k e ] ` t ` c ` _ g v ` b ` k i d i i ` ] g a ` b c g _ b g a
q _ k i i k j h m ] c d ` ] i k a `
g i ` n g i ` ] g a i ` _ ` b i k o
n k ` b c g w  m ` d i ` n p a i ` e ` b a ` _ € p h k ] n ` b c ` ^ g _ o
c d e ] ` a d i k a c k b c d a d _  m k c ` h c m _ d a x c g ^ g ] g v u d a i `
_ ` i h g n ^ ] ` f d a r
~ b d h d _ d h c ` _ u a c k h d h g n ” b ` b ] d a a k n m ] d h k g o
b ` a b m n  _ k h d a ` a ` ] m a g k b c ` b a k Πg i ` ] d a m b k o
i d i ` a d _ k c n  c k h d a i ` ^ m b c g  g c d b c ` w  m ` w i ` o
e k i g d a m n d x g _ h g n ^ ] ` f k i d i w i ` c ` _ n k b d b ` b
v _ d b n ` i k i d ` ] c k ` n ^ g i ` ` f ` h m h k l b i ` ] d d ^ ] k o
h d h k l b r \ a c ` € d h c g _ b g a € d h k ] k c d ] d h g b a c _ m h h k l b
i ` m b n g i ` ] g ^ g _ c d e ] ` d i k a c k b c g a ^ _ g h ` a d i g o
_ ` a i ` d _  m k c ` h c m _ d a k n k ] d _ w x d  m ` a ` e d a d ` b
` ] k b Œ d _ k d b c ` i d i g ^ g _ ` ] b ” n ` _ g i ` g ^ ` _ d h k g o
b ` a ` b ^ m b c g  g c d b c ` ` b € m b h k l b i ` ] g a i d c g a
i ` ` b c _ d i d i ` ] ^ _ g e ] ` n d r
‘ g _ g c _ g ] d i g w ` b ] d a d ^ ] k h d h k g b ` a ^ d _ d ] ` ] d a
x i k a c _ k e m k i d a w ] d a h g n m b k h d h k g b ` a a g b m b € d h o
c g _ ` a ^ ` h k d ] n ` b c ` _ ` ] ` Πd b c ` w x d  m ` ] g a c k ` n ^ g a
364 Tecnologías Grid, Clusters y Plataformas Distribuidas
d a g h k d i g a d m b d h g n m b k h d h k l b a g b Πd _ k g a l _ i ` o
b ` a i ` n d v b k c m i a m ^ ` _ k g _ ` a d ] g a i ` m b d g ^ ` o
_ d h k l b d _ k c n  c k h d r ‘ g _ c d b c g w ^ d _ d n g i ` ] d _ ` ]
c k ` n ^ g _ `  m ` _ k i g ^ g _ m b d d ^ ] k h d h k l b w ` a € m b i d o
n ` b c d ] i ` c ` _ n k b d _ c d b c g ` ] b ” n ` _ g i ` h g n m o
b k h d h k g b ` a w h g n g ` ] Πg ] m n ` b i ` i d c g a c _ d b a n k o
c k i g a r
‚

W „ W … Z ‰ [  ˆ ‰ Š [ ‡ W † X Z † ‡ W † X
\ ] n g i ` ] g t k i _ g i k b p n k h g ` a c m i k d i g a ` e d a d
` b n  c g i g a i ` i k € ` _ ` b h k d a j b k c d a w _ ` h d x ` b i g ` ]
n d x g _ ^ ` a g h g n ^ m c d h k g b d ] a g e _ ` ] d _ ` a g ] m h k l b
i ` ] g a v _ d b i ` a a k a c ` n d a ] k b ` d ] ` a i k a ^ ` _ a g a d a g o
h k d i g a d ` a c g a r
‹ g a a k a c ` n d a i ` ` h m d h k g b ` a ] k b ` d ] ` a d a g h k d o
i g a d ] d a k n m ] d h k l b a ` _ ` a m ` ] Π` b n ` i k d b c ` n  o
c g i g a i `  _ x ] g Π{  w |  } h g b ^ _ ` h g b i k h k g b d i g _ w
n ` i k d b c ` ] d ] k e _ ` _ u d ‘ \  h {  } r ‘ g _ ] g c d b c g w
^ d _ d d ] h d b  d _ b m ` a c _ g a g e f ` c k Œ g a i ` e ` n g a ` a o
c m i k d _ ` b i ` c d ] ] ` ] d a g ^ ` _ d h k g b ` a d a g h k d i d a d ] d
a m e _ m c k b d i ` _ ` a g ] m h k l b ^ d _ d n d c _ k h ` a i k a ^ ` _ o
a d a r
  
  
‘ \  h  ‘ g _ c d e ] ` \ y c ` b a k e ] `  g g ]  k c € g _ h k ` b o
c k j h
z
g n ^ m c d c k g b “ ` a m b d ] k e _ ` _ u d ^ d _ d ] d a g ] m o
h k l b ^ d _ d ] ` ] d i ` d ^ ] k h d h k g b ` a n g i ` ] d i d a d c _ d o
Œ  a i ` ` h m d h k g b ` a ` b i k € ` _ ` b h k d a ^ d _ h k d ] ` a w ` n o
^ ] ` d b i g ] d ] k e _ ` _ u d  ‘  {  } ` b ] d a h g n m b k h d h k g o
b ` a r
 b c ` _ € d h ` a d e a c _ d h c d a d ] d a ` a c _ m h c m _ d a x _ m o
c k b d a i ` ‘ \  h € d h k ] k c d b ` ] d h h ` a g i ` € g _ n d
c _ d b a ^ d _ ` b c ` d ] m a m d _ k g r ‹ d a i k a c k b c d a k n ^ ] ` o
n ` b c d h k g b ` a i ` ` a c d a k b c ` _ € d h ` a a g b d a k v b d i d a
i ` € g _ n d i k b p n k h d n ` i k d b c ` ` a c _ m h c m _ d a i `
^ m b c ` _ g a r \ a c d h d _ d h c ` _ u a c k h d b g a ^ ` _ n k c ` w ^ g _
` f ` n ^ ] g w c _ d e d f d _ k b i k a c k b c d n ` b c ` h g b n d c _ k o
h ` a i ` b a d a g i k a ^ ` _ a d a w ` y h ` ^ c g ` b a m k b k h k d ] k  d o
h k l b  x ] d a ` ] ` h h k l b i ` m b n  c g i g i ` _ ` a g ] m h k l b
h g b h _ ` c g w d a u h g n g a m a ^ d _ p n ` c _ g a w ` a i ` j b k e ] `
c d b c g ` b c k ` n ^ g i ` h g n ^ k ] d h k l b h g n g i ` ` f ` o
h m h k l b r
‘ \  h i k a ^ g b ` i ` a g ^ g _ c ` ^ d _ d g ^ ` _ d h k g b ` a
i ` d b p ] k a k a x n g i ` ] d i g w n g a c _ d b i g ` ] b ” n ` _ g
i ` g ^ ` _ d h k g b ` a x ` ] m a g i ` n ` n g _ k d ` a c k n d o
i g r \ ] k b h g b Π` b k ` b c ` i ` a m m a g _ d i k h d ` b  m `
a ` c _ d c d i ` m b d d ^ _ g y k n d h k l b i ` j b k i d ` b h l i k o
 k v m _ d |  ‘ d c _ l b i ` n d c _ k  i ` g _ i ` b
∼  
r
  
x i ` c d ] ] `
v g w x t ` n g a h g n ^ _ g e d i g  m ` ` b d ] v m b d a i ` ] d a
d _  m k c ` h c m _ d a ` a c m i k d i d a ] g a _ ` a m ] c d i g a g e c ` b k o
i g a i k a c d b n m h t g i ` ] d _ ` d ] k i d i  ^ g _ ` f ` n ^ ] g w
a g e _ ` m b   ‘  |
   
w  m ` k n ^ ] ` n ` b c d ` b
t d _ i  d _ ` ] d n m ] c k ^ ] k h d h k l b o d h m n m ] d h k l b “ r \ a o
c d a i k a h _ ` ^ d b h k d a b g a ] ] ` Œ d _ g b d m c k ] k  d _ ‘


o
‘  {  } w m b d ] k e _ ` _ u d i ` d b p ] k a k a i ` _ ` b i k n k ` b c g
 m ` € d h k ] k c d ] d h d _ d h c ` _ k  d h k l b i ` ] d d ^ ] k h d h k l b
n ` i k d b c ` n ` i k h k g b ` a i ` ] g a h g b c d i g _ ` a t d _ i o
 d _ ` i ` ] ^ _ g h ` a d i g _ r
                     
‘ d _ d i ` j b k _ ` ] n g i ` ] g i ` _ ` b i k n k ` b c g a ` h g b o
a k i ` _ d _ g b g h t g a k c m d h k g b ` a _ ` d ] ` a a k v b k j h d c k Πd a
x i k a ^ d _ ` a r


^ d _ c k _ i ` ` a c d a a ` g e c m Πk ` _ g b ] d a
n d c _ k h ` a i k a ^ ` _ a d a d a g h k d i d a w x a ` v ` b ` _ d _ g b
Πd _ k d h k g b ` a _ ` d ] ` a ^ d _ d d n ^ ] k d _ ` ] ` a ^ d h k g i `
n m ` a c _ d r ‹ d a n d c _ k h ` a c k ` b ` m b g _ i ` b d ^ _ g y k o
n d i g ` b c _ `
 
r
  
x 

r
  
w x ^ _ ` a ` b c d b ` b c _ `
| x | n k ] ] g b ` a i ` ` ] ` n ` b c g a b g b m ] g a r ‘ _ ` a ` b o
c d b m b ^ d c _ l b n m x _ ` v m ] d _ i ` e d b i d a i k a ^ ` _ o
a d a   k v r | “ w ` ] h m d ] h g b i m h ` € p h k ] n ` b c ` d m b
_ ` ^ d _ c g i ` h d _ v d `  m k ] k e _ d i g r
s d i g  m ` ] g a a k a c ` n d a i ` ` a c m i k g ` a c p b d a g o
h k d i g a d m b d k c ` _ d h k l b i ` m b _ ` a g ] m c g _ i `  `  o
c g b b g ] k b ` d ] w b g ` a b ` h ` a d _ k g ` a c k n d _ ] g a c k ` n o
^ g a i ` h d _ v d i ` i d c g a w ^ m ` a ` a c g a ^ _ g Πk ` b ` b i `
] d _ ` d ] k n ` b c d h k l b i ` ] d d ^ ] k h d h k l b r
\ b ` ] h l i k v g d a g h k d i g d ] d a m e _ m c k b d i ` _ ` a g o
] m h k l b ! " # $ % &   k v r “ ^ g i ` n g a i k a c k b v m k _
` b c _ ` ] d ^ d _ c ` i ` k b k h k d ] k  d h k l b i ` ` a c _ m h c m _ d a w
c _ d b a € g _ n d h k g b ` a x ` a h d ] d i g a k b k h k d ] ` a  x ` ] b ” o
XVI Jornadas de Paralelismo, JP '2005 365
 k v m _ d  \ a c _ m h c m _ d i ` ! " # $ % &
h ] ` g h g n ^ m c d h k g b d ]  m ` k n ^ ] k h d ] d _ ` a g ] m h k l b
i ` ] ` a ^ d h k g i `  _ x ] g Πd a g h k d i g d ] ^ _ g e ] ` n d

# $ % & “ r s d i g  m ` ` ] h g a c ` i ` k b k h k d ] k  d o
h k l b a ` Œ ` _ ` i m h k i g d b c ` n ” ] c k ^ ] ` a ` f ` h m h k g b ` a
i ` a k a c ` n d a h g b ] d n k a n d ` a c _ m h c m _ d w x d i ` o
n p a a l ] g a k v b k j h d ` b c _ ` m b
 
x m b |
 
i `
] d ` f ` h m h k l b i ` ] ^ _ g v _ d n d ` b ] g a ^ ` g _ ` a h d a g a w
b g a ` h g b a k i ` _ l ` b ` ] i k a `
g i ` ] n g i ` ] g r


i ` n p a w x i ` e k i g d  m ` ] g a n  c g i g a i `  _ x o
] g Πa g b n  c g i g a k c ` _ d c k Πg a w ` ] ^ _ g e ] ` n d  m ` i d
h g n ^ ] ` c d n ` b c ` h d _ d h c ` _ k  d i g ^ g _ ` ] ` a c m i k g i `
m b d k c ` _ d h k l b v ` b  _ k h d i ` ] g a n  c g i g a r
 ` n g a i ` c ` _ n k b d i g ` ] h g b f m b c g i ` n  c g o
i g a  m ` h g b Π` _ v ` b ^ d _ d ] d n d x g _ u d i ` ] ` a ^ d h k g
i ` n m ` a c _ d a w i ` h k i k  b i g b g a ^ g _ ` ] ` a c m i k g i `
] g a a k v m k ` b c ` a _ ` a g ] m c g _ ` a {  w |  } k b h ] m k i g a ` b
‘ \  h 
•
q _ d i k ` b c `
z
g b f m v d i g
z
m d i _ d i g 
z
q “ r
•
q _ d i k ` b c `  k h g b f m v d i g   
z
q “ r
• 
` _ a k l b \ a c d e k ] k  d i d i ` ] q _ d i k ` b c `  k h g b o
f m v d i g
z
m d i _ d i g  
z
q “ r
•
 ` a k i m g  u b k n g q ` b ` _ d ] k  d i g  q   \ “
 t ` n g a j f d i g ` ] _ ` k b k h k g i ` ] n  c g i g ` b 

k c ` _ d h k g b ` a “ r
Matrices
Iteraciones 1 2 3 4 5 6 7 8
20
40
60
80
100
BCGS
BICG
CGS
GMRES
TFQMR
 k v m _ d     i ` k c ` _ d h k g b ` a ^ g _ n  c g i g
• 
d _ k d b c ` ‹ k e _ ` o  _ d b a ^ m ` a c d i `  ` a k i m g a
z
m d a k o  u b k n g a       “ r
\ ] 
z
q ` a w ` b v ` b ` _ d ] w ` ] n p a d i ` h m d i g
^ d _ d ] d a a k n m ] d h k g b ` a ` a c m i k d i d a w x d  m ` a m ` ] `
_ `  m ` _ k _ m b n ` b g _ b ” n ` _ g i ` k c ` _ d h k g b ` a ^ d _ d
d ] h d b  d _ ] d h g b Œ ` _ v ` b h k d   k v r  “ r
‘ d _ d d h ` ] ` _ d _ ] d h g b Œ ` _ v ` b h k d i ` ] g a n  c g o
i g a d b c ` _ k g _ ` a a ` m a d ` ] n  c g i g d i k c k Πg i ` h t o
 d _  { |

} 


 “ h g n g ^ _ ` h g b i k h k g b d i g _ w ^ d _ d
` ] h m d ] ‘ \  h k b h g _ ^ g _ d m b d Œ ` _ a k l b ^ d _ d ] ` ] d r
z
d i d e ] g  m ` k b i k Πk i m d ] d a g h k d i g d ] n  c g i g a `
_ ` a m ` ] Œ ` ` n ^ ] ` d b i g m b d € d h c g _ k  d h k l b ‹ ~ k b o
h g n ^ ] ` c d   ‹ ~ “ r
 b a c _ m n ` b c d ] k  d n g a ] d k n ^ ] ` n ` b c d h k l b i `
` a c g a n  c g i g a w ^ d _ d ] g h m d ] a ` k b c _ g i m f ` _ g b ] ] d o
n d i d a d ] g a h g b c d i g _ ` a i ` t d _ i  d _ ` i ` ] ^ _ g o
h ` a d i g _ n ` i k d b c ` ` ] m a g i ` ] d ] k e _ ` _ u d ‘


‘  r
‹ d ] k e _ ` _ u d ‘


‘  _ `  m k ` _ ` m b  ` _ b ` ] n g i k o
j h d i g a g e _ ` ] k b m y ^ d _ d ^ g i ` _ d h h ` i ` _ d ] g a
h g b c d i g _ ` a t d _ i  d _ ` i ` ] n k h _ g ^ _ g h ` a d i g _ r ‹ d a
n ` i k h k g b ` a a ` t k h k ` _ g b a g e _ ` m b h ] m a c ` _ i ` i k h d o
i g i ` ‘    d | q t  w b g i g a i ` d _  m k c ` h c m _ d a k o
n k ] d _ d ] g a i ` ] c ` a c e ` i i ` ] ^ _ g x ` h c g
z
_ g a a q _ k i r
               
    
‹ d ^ _ k b h k ^ d ] ` a g ^ ` _ d h k g b ` a  m ` a ` ` f ` h m c d b
` b c g i g a ] g a _ ` a g ] m c g _ ` a w x  m ` i ` j b ` b ` ] n g o
366 Tecnologías Grid, Clusters y Plataformas Distribuidas

            
R2 = R̄2

z
q
22n/p + 87,71 1
z
q
19n/p + 69,63 1
    
25n/p + 134,71 1
q   \
(7 + 4mod30(k − 1))n/p 1
+6mod30(k − 1) + 69,93
 
z
q
k = 1 12n/p + 45,94 1
k = 1 16n/p + 47,91
 d c  m ] c
2nz/p + 194 1



3,595nz/p + 179999 0,999
n

; 7 3 = C ? 5 ; > 
nz

3 ; C > = B G = B = D 9 B G
p

; B : 3 G ? 7 B ; 3 G
k

5 3 ; ? : > < =
 d e ] d |   g i ` ] g a i ` g ^ ` _ d h k g b ` a
i ` ] g i `  ‹  ‘ w a g b 
•
\ ] ^ _ g i m h c g n d c _ k  i k a ^ ` _ a d o Œ ` h c g _
 a m e _ m c k b d      $  “ w i ` ^ ` b i k ` b c ` i ` ]
b ” n ` _ g i ` c  _ n k b g a b g b m ] g a w x  m `
^ _ ` a ` b c d ` ] n k a n g n g i ` ] g ^ d _ d c g i g a ] g a
n  c g i g a r
•
‹ d a g ^ ` _ d h k g b ` a ^ _ g ^ k d a i ` h d i d n  c g i g w
] d a h m d ] ` a a g ] g i ` ^ ` b i ` b i ` ] g _ i ` b
n
i ` ] d
n d c _ k  w x d  m ` a g b g ^ ` _ d h k g b ` a h g b Œ ` h c g o
_ ` a i ` i k n ` b a k l b
n
x ` a h d ] d _ ` a r
•
‹ g a h p ] h m ] g a d a g h k d i g a d ] ^ _ ` h g b i k h k g b d o
i g _


 w i ` ^ ` b i k ` b c ` i ` ] b ” n ` _ g i ` c  _ o
n k b g a b g b m ] g a r
\ b ] d c d e ] d | n g a c _ d n g a w ^ d _ d h d i d m b g i `
] g a _ ` a g ] m c g _ ` a d b d ] k  d i g a x ] d a ^ d _ c ` a n ` b h k g o
b d i d a d b c ` _ k g _ n ` b c ` w ` ] n g i ` ] g  m ` ^ _ g ^ g _ h k g o
b d ` ] b ” n ` _ g i `  ‹  ‘ ^ g _ ^ _ g h ` a d i g _ ` b
€ m b h k l b i ` ] d a h d _ d h c ` _ u a c k h d a i ` ] d n d c _ k  x
i ` ] b ” n ` _ g i ` ^ _ g h ` a d i g _ ` a r  d n e k  b a ` n m ` a o
c _ d b ` ] h g ` j h k ` b c ` i ` i ` c ` _ n k b d h k l b
R2 w  m ` ` a
` ] d f m a c ` i ` ] d _ ` v _ ` a k l b n ” ] c k ^ ] ` d ] g a i d c g a 
x a m k v m d ] i d i h g b ` ] h g ` j h k ` b c ` i ` i ` c ` _ n k b d o
h k l b d f m a c d i g
R̄2 w ` ] h m d ] w a k € m ` a ` n m x i k a c k b c g
d
R2 k b i k h d _ u d  m ` ` ] n g i ` ] g t d a k i g a g e _ ` d o
f m a c d i g { | | } r
\ a c g a n g i ` ] g a ] k b ` d ] ` a a ` h g b a c _ m x ` _ g b d
^ d _ c k _ i ` ] g a _ ` a m ] c d i g a ` y ^ ` _ k n ` b c d ] ` a g e c ` b k o
i g a i ` ` f ` h m c d _ ] g a a k a c ` n d a i ` ] ` a ^ d h k g n m ` a o
c _ d ] ^ d _ d c g i g a ] g a n  c g i g a m a d b i g | w w  x 
^ _ g h ` a d i g _ ` a r ` n m ` a c _ ` l i ` € g _ n d m b k € g _ n `
50000 150000 250000
1e+06
4e+06
7e+06
Metodo BCGS (sin MatMult)
Orden Matriz/Procesadores
Flops
0.0e+00 4.0e+06 8.0e+06 1.2e+07
0.0e+00
1.0e+07
2.0e+07
MatMult: Producto Matriz−Vector
Non Zeros Matriz/Procesadores
Flops
0.0e+00 4.0e+06 8.0e+06 1.2e+07
0e+00
2e+07
4e+07
Precondicionador ASM
Non Zeros Matriz/Procesadores
Flops
 k v m _ d   \ f ` n ^ ] g i ` d f m a c ` i `  ‹  ‘ 

z
q
XVI Jornadas de Paralelismo, JP '2005 367

    

   

z
q 

` h s g c
|

` h  g _ n
z
q

` h s g c
|

` h  g _ n
    

` h s g c
|

` h  g _ n
q   \

` h  s g c
(k + 1)
|

` h  g _ n
 
z
q

` h s g c
|

` h  g _ n
 d c  m ] c |

` h h d c c ` _




` h h d c c ` _
k

5 3 ; ? : > < =
 d e ] d   g i ` ] g i ` h g n m b k h d h k g b ` a
] d k b € g _ n d h k l b g e c ` b k i d w x a ` m a l ` ] ^ d  m ` c ` ` a o
c d i u a c k h g  {

} ^ d _ d g e c ` b ` _ ] g a n g i ` ] g a  Œ  d a `
] d c d e ] d | x ] d  k v r  “ w ] g a h m d ] ` a a g b e d a c d b c `
^ _ ` h k a g a h g n g h g _ _ g e g _ d ` ]  m `
R2
= R̄2
 1
r
\ b h d i d k c ` _ d h k l b i ` ] g a n  c g i g a ` a c m i k d o
i g a w a ` _ ` d ] k  d b i g a ] ] d n d i d a d ] d a m e _ m c k b d
     $  w x a ` i ` e ` d ^ ] k h d _ i g a Π` h ` a ` ] ^ _ ` o
h g b i k h k g b d i g _ w ` y h ` ^ c g ` b ` ] h d a g i ` q   \ w
 m ` a l ] g t d h ` m b d ] ] d n d i d d h d i d m b d i ` ] d a
_ m c k b d a d b c ` _ k g _ ` a r
                        
‹ g a n  c g i g a i `  _ x ] g Œ a g b d i ` h m d i g a ^ d o
_ d ` b c g _ b g a ^ d _ d ] ` ] g a ^ g _  m ` a ` ^ m ` i ` b k n ^ ] ` o
n ` b c d _ h g b ^ g h d a h g n m b k h d h k g b ` a r \ ] ^ d c _ l b
i ` h g n m b k h d h k g b ` a ` a a ` b h k ] ] g h g n g a ` d ^ _ ` o
h k d ` b ] d c d e ] d r ‹ d n d x g _ u d i ` ] d a h g n m b k o
h d h k g b ` a a g b i ` e k i d a d ] ^ _ ` h g b i k h k g b d i g _ x d ]
^ _ g i m h c g n d c _ k  o Œ ` h c g _ w x d  m ` ] d € m b h k l b i `
‘ \  h  &    &
v ` b ` _ d ] ] d n d i d a ` b  ‘  d
€ m b h k g b ` a i ` h d c c ` _ x q d c t ` _ i ` Œ ` h c g _ ` a r


a g h k d i g a d ] g a n  c g i g a w ` y k a c ` b ] d a a m e _ m o
c k b d a  &  #  x  &  #
w ^ d _ d ] d a h m d ] ` a a `
_ ` d ] k  d m b 
   $ $  &   & i ` | i d c g w x ] d
a m e _ m c k b d  &   #   ^ _ g i m h c g ` a h d ] d _ i ` Œ ` h o
c g _ ` a n ” ] c k ^ ] ` “ i `
k
Œ ` h c g _ ` a w  m ` _ ` d ] k  d m b

   $ $  &   & i `
k
i d c g a r
Flops
Tiempo
Proceso(seg)
5.0e+07 1.0e+08
0.5
1.0
1.5
2.0
 k v m _ d

 \ f ` n ^ ] g i ` d f m a c ` i ` c k ` n ^ g a
  
        a “
R2
= R̄2
 ` d ]
1,4617 ∗ 10−8
flops 0,9225
+5,3197 ∗ 10−2
‘ _ g h ` a g
1,4592 ∗ 10−8
flops+ 0,9844
1,3185 ∗ 10−2
 d e ] d    ` ] d h k l b  ‹  ‘ o c k ` n ^ g
              
    
\ ] n g i ` ] g i ` c k ` n ^ g i ` ` f ` h m h k l b c g c d ] a ` Π`
k b  m ` b h k d i g ^ g _ ` ] n g i ` ] g i `  ‹  ‘ x ` ] n g o
i ` ] g i ` h g n m b k h d h k g b ` a r
\ b ` ] h d a g i ` ] c k ` n ^ g d a g h k d i g d g ^ ` _ d h k g b ` a
` b ^ m b c g  g c d b c ` w ] g t ` n g a g e c ` b k i g h g b ] d ` f ` o
h m h k l b a g e _ ` m b ” b k h g ^ _ g h ` a d i g _ r

` n g a  m `
h g b ` ] c k ` n ^ g d a g h k d i g a l ] g d ^ _ g h ` a g c ` b ` n g a
n d x g _ d f m a c `  m ` m a d b i g ` ] c k ` n ^ g _ ` d ]  c d e ] d
 “ w x  m ` ` ] d f m a c ` n m ` a c _ d m b ` _ _ g _ n m x _ ` o
i m h k g   k v r

“ w a k ` b i g d n e g a d f m a c ` a n m x ^ _ ` o
h k a g a r


] d
d i k _ ` ] € d h c g _ i ` ] d a h g n m b k h d h k g b ` a a `
h g n ^ ] k h d ` ] n g i ` ] g w x d  m ` d i ` n p a i ` ] c k ` n ^ g
_ `  m ` _ k i g ^ d _ d ] d a h g n m b k h d h k g b ` a w ] d a h g n m o
b k h d h k g b ` a h g ] ` h c k Πd a  m ` a ` ] ] ` Πd b d h d e g ^ _ ` o
a ` b c d b m b c k ` n ^ g d a g h k d i g d ] d a k b h _ g b k  d h k l b
i k € u h k ] i ` i ` c ` _ n k b d _ w d m b  m ` b g ` a n m x ` ] ` Œ d o
i g i ` e k i g d ] d i k a c _ k e m h k l b `  m k ] k e _ d i d i ` ] d
h d _ v d  m ` ^ _ ` a ` b c d ` a c d d ^ ] k h d h k l b r
368 Tecnologías Grid, Clusters y Plataformas Distribuidas
‚

† [ ˆ Y X ‰ † [ W X   [ W  X  Y „ Y …  X
\ b ` a c ` c _ d e d f g a ` t d ` a c d e ] ` h k i g m b n g i ` o
] g ^ d _ d ^ _ ` i ` h k _ ` ] _ ` b i k n k ` b c g i ` ] g a e ] g  m ` a
h g n ^ m c d h k g b d ] ` a n p a k n ^ g _ c d b c ` a i ` m b d d ^ ] k o
h d h k l b q _ k i ^ d _ d ` ] h g b c _ g ] i ` k b m b i d h k g b ` a r \ ]
n g i ` ] g a ` e d a d ` b ] d ` f ` h m h k l b ` y t d m a c k Πd i ` ]
h l i k v g x d e g _ i d c d b c g ] d h d _ d h c ` _ k  d h k l b i ` ]
h g a c ` i ` ] d a h g n ^ m c d h k g b ` a h g n g i ` ] d a h g n m o
b k h d h k g b ` a r
\ ] h g n ^ g _ c d n k ` b c g i ` ] d d ^ ] k h d h k l b ` a € p h k ] o
n ` b c ` ^ _ ` i ` h k e ] ` ` b h m d b c g d h g n ^ m c d h k g b ` a w
h g b ] g h m d ] ` a c ` ` ] ` n ` b c g  m ` i d h g _ _ ` h c d n ` b c `
i ` c ` _ n k b d i g r
\ ] n g i ` ] g i ` h g n m b k h d h k g b ` a a g e _ ` q _ k i ` a o
c p a k ` b i g i ` a d _ _ g ] ] d i g d h c m d ] n ` b c ` w x a ` c k ` o
b ` b ` a c k n d h k g b ` a d h ` _ c d i d a h g b h g n m b k h d h k g o
b ` a ^ m b c g d ^ m b c g { |

} r ‘ ` _ g ` ] m a g i `  ‘ 
z
 o
q h g n ^ ] k h d ` ] ` a c m i k g i ` ] d a h g n m b k h d h k g b ` a
v ] g e d ] ` a w ^ m ` a c g  m `  ‘ 
z
 o q i k € ` _ ` b h k d ` b
` ] a k a c ` n d i k a c k b c g a b k Π` ] ` a i ` h g n m b k h d h k g b ` a
 


 w ‹


 w ‹ g h d ] w r r r “ w a k ` b i g ] d ` a c _ d c ` v k d
i k a c k b c d a ` v ” b ] g a b k Œ ` ] ` a d ] g a  m ` a ` d h h ` i d r
‘ g _ ` f ` n ^ ] g w ` ] e _ g d i h d a c a ` k n ^ ] ` n ` b c d a ` o
h m ` b h k d ] d b k Π` ] 


 x h g n g p _ e g ] e k b d _ k g ` b
` ] _ ` a c g i ` ] g a b k Π` ] ` a r
~ b g e f ` c k Πg j b d ] i ` ` a c ` c _ d e d f g ^ g i _ u d a ` _
] d k b h g _ ^ g _ d h k l b i ` ] n g i ` ] g d m b v ` a c g _ i ` _ ` o
h m _ a g a q _ k i ^ d _ d g ^ c k n k  d _ a m _ ` b i k n k ` b c g r
 
…  ‡ W ˆ ‰ Z ‰ W [ „ † X
\ a c ` c _ d e d f g t d a k i g j b d b h k d i g ^ d _ h k d ] n ` b c `
^ g _ ` ]   

  
           o
 
| o    “
x ` ] ^ _ g x ` h c g   
 
 o

  ’  o
z

i ` ] 
z
•  r


i ` n p a w ] g a d m c g _ ` a d v _ d i ` h ` b d ]
z
` b c _ g i ` ]
m ^ ` _ h g n ^ m c d h k l b i ` q d ] k h k d 
z
\ q


“ ^ g _
] d a k b € _ d ` a c _ m h c m _ d a x a ` _ Œ k h k g a g € _ ` h k i g a r
V W  W … W [ ˆ ‰  X
{ | }
z
_ g a a q _ k i ‘ _ g f ` h c r
t c c ^     r ` m o h _ g a a v _ k i r g _ v r
{ }  \   o  k b k c ` \ ] ` n ` b c m _ € d h `
 d c ` _  g i ` ] k b v r
t c c ^     r e g a a k b c ] r h g n t c n ] € ` a  n a r t c n ] r
{  }  t `  ` a a d v ` ‘ d a a k b v  b c ` _ € d h `   ‘  “
a c d b i d _ i r
t c c ^  
  o m b k y r n h a r d b ] r v g Πn ^ k r
{  } ‘


‘  o ‘ ` _ € g _ n d b h `


‘  r
t c c ^  k h ] r h a r m c  r ` i m ^ d ^ k r
{

}  t `  ^ _ g f ` h c € g _ a c d c k a h d ] h g n ^ m c k b v r
t c c ^     r _ o ^ _ g f ` h c r g _ v r
{ Ž }

r r


i Π` r


b d ] x  k b v c t ` e ` t d Œ k g _ d b i
^ ` _ € g _ n d b h ` g € ^ d _ d ] ] ` ] ^ _ g v _ d n a r  ` h t o
b k h d ]  ` ^ g _ c
z
o   o | ’ ’  o |

| w | ’ ’  r
{  } r  d ] d x w  r  m a h t ` ] n d b w  r s r q _ g ^ ^ w
s r  d m a t k  w  r q r  b ` ^ ] ` x w ‹ r
z
r  h  b o
b ` a w  r  r n k c t w x  r  t d b v r ‘ \  h
 ` e ^ d v ` w
 
| r
t c c ^     r n h a r d b ] r v g Π^ ` c a h r
{  }  r  d _ _ ` c c w  r  ` _ _ x w  r  r
z
t d b w  r s ` n o
n ` ] w  r s g b d c g w  r s g b v d _ _ d w

r \ k f  o
t g m c w  r ‘ g  g w
z
r  g n k b ` w x  r

r

g _ a c r

   
 

     
 


   

   
 
 

 

 
    

 
 


        

    
  
 
    r 


 w | ’ ’  r
{ ’ }  r  g m ] ] l b w  r
z
r
z
d e d ] ` k _ g w  r s g d ] ] g w
‘ r q l b  d ] `  w s r  r  d _ c u b `  w  r  r  d _ o
c u b w  r
z
r  g m _ k
g w  r  r ‘ ` b d w x  r  r
 k Π` _ d r


^ ` _ € g _ n d b h ` ^ _ ` i k h c k g b c g g ] € g _
v _ k i ` b d e ] ` i d ^ ] k h d c k g b a r  g e ` ^ m e ] k a t ` i
k b ‹ r  r
z
r r
{ |

}  r  g m ] ] l b w  r
z
r
z
d e d ] ` k _ g w  r s g d ] ] g w
‘ r q l b  d ] `  w s r  r  d _ c u b `  w  r  r  d _ o
c u b w  r
z
r  g m _ k
g w  r  r ‘ ` b d w x  r  r
 k Œ ` _ d r  g i ` ] k b v ` y ` h m c k g b c k n ` g € a ` ] ` h o
c ` i h g n ^ m c d c k g b d b i h g n n m b k h d c k g b  ` _ o
b ` ] a g b q _ k i r


n a c ` _ i d n w  t `  ` c t ` _ o
] d b i a w  ` e r
  
r \ m _ g ^ ` d b q _ k i
z
g b € ` o
_ ` b h `  \ q
z

  
“ r
{ | | }  r
z
d _ n g b d ‘ g b c d  m ` r

 
 
 


 

 
 r
‘ m e ] k h d h k g b a ~  w ` e g g  ` i k c k g b w
  
r
{ | }  r q g c  w ~ r  ` _  g v w x  r  ` c c ` ] e d h t r
 m ] c k ^ _ g h ` a a g _ d b i i k a c _ k e m c ` i a x a c ` n
i ` a k v b   t ` k b c ` v _ d c k g b g € € m b h c k g b d ] a ^ ` o
h k j h d c k g b d b i ^ ` _ € g _ n d b h ` d b d ] x a k a m a k b v
a c g h t d a c k h ^ _ g h ` a a d ] v ` e _ d a r  b 

 
  







 
 
  


      

 w ^ d o
v ` a | | |  Ž w | ’ ’  r
XVI Jornadas de Paralelismo, JP '2005 369
{ |  }

r  r  d  x r  r ‹ m b i a c _ g n r ‘ _ ` o
i k h c k b v ^ ` _ € g _ n d b h ` g € ^ d _ d ] ] ` ] h g n ^ m c d o
c k g b a r 
  
  

    
   

     

  w
|   “ 

 

w | ’ ’

r
{ |  }  r


r  d _ a d b w q r
z
g b c ` w x q r  d ] e g r


h ] d a a g € v ` b ` _ d ] k  ` i a c g h t d a c k h ‘ ` c _ k b ` c a
€ g _ c t ` ^ ` _ € g _ n d b h ` ` Œ d ] m d c k g b g € n m ] c k o
^ _ g h ` a a g _ a x a c ` n a r 


  



 
 

  w  “  ’  | w | ’   r
{ |

} • r d d i r  

    
  
       
 
  

  
 
 

 
 
 r ‘  ‘ m e ] k a t k b v
z
g n ^ d b x w
| ’ ’

r
{ | Ž }  r k n n g b a x  r  g a  ` ] d r ‘ ` _ € g _ n d b h `
k b a c _ m n ` b c d c k g b d b i Œ k a m d ] k  d c k g b r 


 

  w | ’ ’

r
{ |  }  r

r

g _ a c r  

    
 


 
 
       
  
 
 
 
 

 
 
 r
z
d n e _ k i v ` ~ b k o
Œ ` _ a k c x ‘ _ ` a a w | 


^ _ r
 
 r
370 Tecnologías Grid, Clusters y Plataformas Distribuidas
&RPSDUDWLYDGHPHWDKHXUtVWLFDVXWLOL]DQGR*ULG&RPSXWLQJ
3LODU0RUHQR'tD] *DEULHO+XHFDV)HUQiQGH]7RULELR


-HV~V6iQFKH]$OOHQGH 
&DUORVGHOD9LHVFD6DQWDIp $OPXGHQD*DUFtD0DQVR 
   
                    
"
  #        '  ) *   * ,     /  *
0 1 2 3 5 7
     8  #      <  >    ? @      B
     C 8  E
 
F   
  G  H      I           J    K    * 
   8     8     *    G  H      *    J     * 8        

"
  #        M *    N        @     
0 1 P Q P
@     
H  /     C   
8 
 

5HVXPHQ

(QHVWHDUWtFXORVHSUHVHQWDXQSUREOHPDUHVXHOWR
PHGLDQWH ODV KHXUtVWLFDV E~VTXHGD WDE~ \
VLPXODWHG DQQHDOLQJ \ OD FRPSDUDFLyQ GH ODV
PLVPDVDSURYHFKDQGRSDUDHOORXQDSODWDIRUPDGH
JULG FRPSXWLQJ SDUD VX HMHFXFLyQ PDVLYD (VWH
HQWRUQR \ OD H[SHULHQFLD TXH VH SUHVHQWD VH
FRQYLHUWH HQ XQ HQWRUQR DSURSLDGR SDUD VX
LQFOXVLyQHQODGRFHQFLDDOWUDWDUVHGHXQHQWRUQR
GH OLEUH GLVWULEXFLyQ (Q HO DUWtFXOR VH SUHVHQWDQ
ORVUHVXOWDGRVREWHQLGRVGHODFRPSDUDWLYD\FRPR
HPSOHDUORHQXQHQWRUQRGRFHQWH
 ,QWURGXFFLyQ
8QRGHORVSUREOHPDVFRQTXHVHHQFXHQWUDQODV
LQVWLWXFLRQHV HGXFDWLYDV \ HQ SDUWLFXODU ORV
FHQWURV XQLYHUVLWDULRV HV OD SURJUDPDFLyQ GH ORV
H[iPHQHV/DHODERUDFLyQGHHVWRVFDOHQGDULRVQR
GHMD GH VHU XQ SUREOHPD KDELWXDO FX\R SULQFLSDO
PHFDQLVPR GH HODERUDFLyQ VH EDVD HQ FRJHU HO
FDOHQGDULRGHH[iPHQHVGHODxRDQWHULRU\ KDFHU
XQD WUDVODFLyQ HQ HO WLHPSR DSURSLDGD SDUD TXH
HQFDMH FRQ ODV IHFKDV YLDEOHV GH OD VLJXLHQWH
FRQYRFDWRULD
'DGRTXHVHWUDWDGHXQSUREOHPDFOiVLFRGH
FDOHQGDUL]DFLyQVHSUHVWDGHIRUPDHVSHFLDOPHQWH
EXHQD SDUD XWLOL]DU PHWDKHXUtVWLFDV GH E~VTXHGD
([LVWHQHQODOLWHUDWXUD PXOWLWXGGHDUWtFXORVTXH
WUDWDQ GH OD UHVROXFLyQ GHO SUREOHPD GH
FDOHQGDULRV GH FODVHV >@>@>@>@>@ R GH
H[iPHQHV>@>@>@>@>@ XWLOL]DQGR GLVWLQWDV
PHWDKHXUtVWLFDV
3DUD ORV REMHWLYRV PDUFDGRV VH HOLJLHURQ GRV
PHWDKHXUtVWLFDV TXH SRU VX VHQFLOOH] IDFLOLWD VX
H[SRVLFLyQ GRFHQWH \ OD HODERUDFLyQ GH SUiFWLFDV
FRQ ORV DOXPQRV D SDUWLU GH ODV PLVPDV (VWDV
PHWDKHXUtVWLFDV VRQ ODV GH E~VTXHGD WDE~ WDEX
VHDUFK>@ \ UHFRFLGR VLPXODWHG DQQHDOLQJ>@
SRU VX VLPLOLWXG HQ OD IRUPD GH RSHUDU \ OD
SRVLELOLGDGGHFRPSDUDUVXFRPSRUWDPLHQWRHQOD
UHVROXFLyQ GHO SUREOHPD /D LGHD HV XWLOL]DU HO
PLVPR PRGHOR GH VROXFLyQ YHFLQGDG \ YDORU GH
FRVWH HQ DPEDV LPSOHPHQWDFLRQHV \ YDULDU
VRODPHQWH HO DOJRULWPR GH E~VTXHGD VLQ DxDGLU
QLQJXQDKHXUtVWLFDSDUWLFXODUDOSUREOHPD
(Q HVWH VHQWLGR ORV DOJRULWPRV GH E~VTXHGD
WDE~ \ UHFRFLGR VH LPSOHPHQWDURQ GH OD IRUPD
FOiVLFDTXHVHLQGLFDPiVDGHODQWH
 3UREOHPDGHHODERUDFLyQGHH[iPHQHV
8QD XQLYHUVLGDG LPSDUWH DVLJQDWXUDV GH GLVWLQWDV
FDUUHUDVQRUPDOPHQWHXQDVGHFHQDVGHHOODV&DGD
XQD GH ODV FDUUHUDV FXHQWD FRQ XQ Q~PHUR GH
DVLJQDWXUDVTXHSXHGHRVFLODUHQWUHXQDYHLQWHQD\
FHUFD GH XQ FHQWHQDU (O PpWRGR WUDGLFLRQDO GH
HVWDEOHFHU ORV FDOHQGDULRV GH H[iPHQHV VXHOH
EDVDUVH HQ XWLOL]DU XQ FDOHQGDULR TXH H[LVWH
SUHYLDPHQWH \ TXH D YHFHV QR VH VDEH FRQ TXp
FULWHULRVVHJHQHUyVREUHHOTXHVHUHDOL]DQOHYHV
PRGLILFDFLRQHV TXH FRQVLVWHQ EiVLFDPHQWH HQ
UHDOL]DU XQD WUDVODFLyQ GH IHFKDV (VWH VLVWHPD
WLHQHODVVLJXLHQWHVGHVYHQWDMDV
(O SURFHVR GH DVLJQDFLyQ GH IHFKDV UHVXOWD
RVFXUR SDUD ORV DOXPQRV JHQHUDQGR FDVRV GH
GHVFRQILDQ]D
1R KD\ XQ FULWHULR XQLILFDGR SDUD GHFLGLU ODV
SULRULGDGHV HQ HO WLHPSR GH ORV H[iPHQHV GH
FLHUWDVDVLJQDWXUDV
6XHOH KDEHU XQ FRQMXQWR LPSRUWDQWH GH
HVWXGLDQWHVTXHPXHVWUDQVXGHVFRQWHQWRFRQHO
FDOHQGDULR \ XQ FLHUWR Q~PHUR GH ORV PLVPRV
FRQVRODSHV
5HVXOWDFRPSOLFDGRHVWDEOHFHUUHODFLRQHVHQWUH
DVLJQDWXUDVVLPLODUHVGHGLIHUHQWHVFDUUHUDVTXH
SHUPLWDRSWLPL]DUORVUHFXUVRVH[LVWHQWHV
(Q HO SUREOHPD VH HQFXHQWUDQ ORV VLJXLHQWHV
HOHPHQWRV
8Q FRQMXQWR GH FDUUHUDV SDUD ODV TXH KD\ TXH
JHQHUDUXQFDOHQGDULRGHH[iPHQHV
8Q FRQMXQWR GH DVLJQDWXUDV GH ODV TXH WHQGUi
H[iPHQHVDOXPQRVGHFDGDXQDGHODVFDUUHUDV
8QFRQMXQWRGHIHFKDVGHH[iPHQHVHQODVTXH
VH SRGUiQ ILMDU OD IHFKD GH UHDOL]DFLyQ GH ORV
H[iPHQHVSDUDFDGDXQDGHODVDVLJQDWXUDV
8Q FRQMXQWR GH UHVWULFFLRQHV VREUH OD SRVLEOH
UHDOL]DFLyQ GHO H[DPHQ GH GHWHUPLQDGDV
DVLJQDWXUDV
(Q FXDQWR D ODV IHFKDV GH H[iPHQHV VH
HVWDEOHFHQ GH DFXHUGR FRQ HO FDOHQGDULR GH FDGD
XQDGHODVFRQYRFDWRULDV1RUPDOPHQWHHOQ~PHUR
GHIHFKDVGLVSRQLEOHVVXHOHYDULDUGHSHQGLHQGRGH
ODFRQYRFDWRULD)HEUHUR-XQLR\6HSWLHPEUH\OD
DSDULFLyQGHSRVLEOHVILHVWDVRHYHQWRVHQWUHORV
GtDVGHFDGDXQDGHODVFRQYRFDWRULDV
/DVUHVWULFFLRQHVTXHVHHVWDEOHFHQVREUHXQD
DVLJQDWXUDVXHOHQVHUYDULDGDV\GHVGHXQSXQWRGH
YLVWD GH DVLJQDFLyQ GH UHFXUVRV SRGUtDQ YHQLU
FRQGLFLRQDGDV SRU HO PRPHQWR GH XVR GH
GHWHUPLQDGDV DXODV R OD GLVSRQLELOLGDG GH
GHWHUPLQDGRV SURIHVRUHV 3RU HMHPSOR FLHUWR
H[DPHQ GHEH UHDOL]DUVH SRU OD WDUGH R GHEH
UHDOL]DUVH XQ YLHUQHV TXH HV FXDQGR VH SXHGH
XWLOL]DUGHWHUPLQDGRODERUDWRULR
2WUR WLSR GH UHVWULFFLRQHV YLHQHQ
FRQGLFLRQDGDVSRUHOKHFKRGHTXHGRVDVLJQDWXUDV
XWLOLFHQ SRU HMHPSOR HO PLVPR ODERUDWRULR SDUD
UHDOL]DUHOH[DPHQ
$VtPLVPRVHHVWDEOHFHXQDJUDGXDFLyQGHODV
DVLJQDWXUDVSDUDFDOLILFDUODVFRPR)iFLO0HGLD\
'LItFLO(VWDJUDGXDFLyQSUHWHQGHUHFRJHUHOKHFKR
GHTXHDXQDDVLJQDWXUDVHOHDVLJQDUiHOJUDGRGH
GLItFLOVLHOQ~PHURGHDOXPQRVTXHYDQDUHDOL]DU
HO H[DPHQ HV VLJQLILFDWLYDPHQWH VXSHULRU D OD
PHGLD GH ODV DVLJQDWXUDV 'H OD PLVPD IRUPD D
XQDDVLJQDWXUDVHOHDVLJQDUiHOJUDGRGH)iFLOVLHO
Q~PHURGHDOXPQRVTXHYDQDUHDOL]DUHOH[DPHQ
HV VLJQLILFDWLYDPHQWH PHQRU D OD PHGLD 'H HVWD
IRUPD\FRPRVHJXUDPHQWHKD\DTXHFHOHEUDUPiV
GH XQ H[DPHQ HO PLVPR GtD \ KRUD VH SUHWHQGH
PLQLPL]DU HO SRVLEOH VRODSH GH H[iPHQHV HQWUH
DOXPQRV
3DUD OD IXQFLyQ GH FRVWH VH HVWDEOHFLy FUHDU
WUHVQLYHOHVGHFRVWHGHSHQGLHQGRGHOQLYHOGHODV
UHJODVTXHVHTXLVLHUDQFXPSOLU
œ 1LYHOIXHUWH&XEUHXQFRQMXQWRGHUHJODVTXH
VH GHEHQ FXPSOLU REOLJDWRULDPHQWH FRPR SRU
HMHPSOR
œ 'RVH[iPHQHVGHOPLVPRFXUVRQRGHEHQ
FRLQFLGLUHOPLVPRGtD\KRUD
œ 1RGHEHQFRLQFLGLUGRVH[iPHQHVGLItFLOHV
GHOPLVPRFXUVRHOPLVPRGtD
œ 1LYHOPHGLR&XEUHXQFRQMXQWRGHUHJODVTXH
VHLQWHQWDUiGHODPHMRUPDQHUDSRVLEOHTXHVH
FXPSODQVLHPSUHSRUHMHPSOR
œ /RV H[iPHQHV GH XQ FXUVR GHEHQ HVWDU
HTXLHVSDFLDGRV
œ 'RV DVLJQDWXUDV GLItFLOHV GH FXUVRV
VXFHVLYRVQRFRLQFLGDQHQGtD\KRUD
œ 1R GHEHQ MXQWDUVH H[iPHQHV GLItFLOHV GH
XQPLVPRFXUVR
œ 1LYHOGpELOFXEUHXQFRQMXQWRGHUHJODVTXH
VyOR SUHWHQGHQ PHMRUDU OD VROXFLyQ HQ FLHUWR
VHQWLGRSRUHMHPSOR
œ 1RGHEHQFRLQFLGLUHQHOGtDH[iPHQHVGH
FXUVRVVHSDUDGRVPHQRVGHWUHVFXUVRV
œ /RVH[iPHQHVGLItFLOHVQRGHEHQUHDOL]DUVH
HQOD~OWLPDVHPDQDGHH[iPHQHV
œ 3DUDORVH[iPHQHVGLItFLOHVGHEHKDEHUDO
PHQRV WUHV GtDV DQWHULRUHV VLQ H[iPHQHV
GHOPLVPRFXUVR
œ 6L VH GDQ GRV H[iPHQHV GHO FXUVRV
FRQWLJXRV HO PLVPR GtD HV SUHIHULEOH TXH
HOGHODWDUGHVHDGHPD\RUGLILFXOWDGTXH
HOGHODPDxDQD
(VWH FRQMXQWR GH UHJODV SUHWHQGH FRQVHJXLU
XQDGLVWULEXFLyQGHH[iPHQHVDSURSLDGRGHIRUPD
TXHIDFLOLWHDORVDOXPQRVWLHPSRQHFHVDULRSDUD
SUHSDUDUORVGHIRUPDDSURSLDGDVLDVtORGHVHDQ
 $OJRULWPRVXWLOL]DGRV
(QODGHVFULSFLyQGHORVDOJRULWPRVVHKDXWLOL]DGR
ODVLJXLHQWHQRWDFLyQ
œ UHSUHVHQWDHOHVSDFLRGHVROXFLRQHV


HVXQD
VROXFLyQ


HVODPHMRUVROXFLyQHQFRQWUDGD
œ 


UHSUHVHQWD OD YHFLQGDG GH XQD
GHWHUPLQDGDVROXFLyQ
œ
 

HV XQD IXQFLyQ GH HYDOXDFLyQ GH XQD
VROXFLyQ
%~VTXHGDWDE~
(ODOJRULWPRGHE~VTXHGDWDE~VHSUHVHQWDFRQHO
VLJXLHQWHHVTXHPD
Seleccionar s S
s*
s
Repetir
372 Tecnologías Grid, Clusters y Plataformas Distribuidas
buscar s’  (s)\T(s) minimiza f(s’)
s  s’
actualizar T(s)
Si f(s) < f(s*)
s*  s;
Si ha pasado un tiempo
s  nuevaSolucion()
Hasta un numero de iteraciones
  
 

   
           # %   & &  
(Q HVWH DOJRULWPR VH SXHGHQ HQFRQWUDU ORV
VLJXLHQWHVDVSHFWRVSURSLRVGHODOJRULWPR\TXHQR
WLHQHQHQFXHQWDHOSUREOHPDFRQFUHWR
œ /DOLVWDWDE~
) +  ,
(QHVWDOLVWDVHJXDUGDFRPR
UHSUHVHQWDQWHVGHODVVROXFLRQHVORVYDORUHVGH
- +  ,
8QRGHORVSDUiPHWURVDFRQVLGHUDUHVHO
WDPDxRGHODPLVPD
œ (O Q~PHUR GH LWHUDFLRQHV HV XQ Q~PHUR ILMR
TXHVHXWLOL]DFRPRSDUiPHWURGHODOJRULWPR
œ 3DUD HYLWDU TXH VH TXHGH HVWDQFDGR \ SXHGD
H[SORUDURWUDV]RQDVGHOHVSDFLRGHVROXFLRQHV
FDGD  LWHUDFLRQHV VH JHQHUD XQD QXHYD
VROXFLyQ D SDUWLU GH ORV HOHPHQWRV PiV
XWLOL]DGRV HQ ODV PHMRUHV VROXFLRQHV
HQFRQWUDGDV\VHOLPSLDODOLVWDWDE~$HVWH
HOHPHQWR VH OH VXHOH GHQRPLQDU PHPRULD D
ODUJR SOD]R (VWH YDORU VH REWXYR GH IRUPD
HPStULFDFRPRDSURSLDGR
5HFRFLGR
(ODOJRULWPREiVLFRGHUHFRFLGRHVHOVLJXLHQWH
Seleccionar solución inicial s S
s*  s
Seleccionar temp. inicial t0
> 0
Repetir
Repetir
Seleccionar un s’  (s)
d  f(s) – f(s’)
Si (d < 0) ó (U(0,1) < exp(-d/t))
s  s’
Si f(s) < f(s*)
s*  s;
Hasta un número de repeticiones
t  / (t)
Hasta condición de parada
  
 
0
   
        
     
(Q HVWH DOJRULWPR VH SXHGHQ HQFRQWUDU ORV
VLJXLHQWHVDVSHFWRVSURSLRVGHODOJRULWPR\TXHQR
WLHQHQHQFXHQWDHOSUREOHPDFRQFUHWR
œ 7HPSHUDWXUD LQLFLDO W2 3 (O YDORU GH OD
WHPSHUDWXUD LQLFLDO VH HVFRJH SDUD TXH
LQLFLDOPHQWHVHDFHSWHQFRQSUREDELOLGDG
HQWRUQRDOGHODVVROXFLRQHVYHFLQDV
œ 3URFHVR GH HQIULDPLHQWR aW 6H XWLOL]D XQ
GHVFHQVRH[SRQHQFLDOFOiVLFRGRQGHW4 5 6  aW4 
œ 1~PHUR GH UHSHWLFLRQHV (V HO Q~PHUR GH
HVWDGRVGHODFDGHQDGH0DUNRY(OEXFOHVH
UHSLWH KDVWD TXH VH KDQ YLVLWDGR \D XQ FLHUWR
Q~PHUR GH YHFLQRV GHSHQGLHQWH GHO WDPDxR
GHODYHFLQGDGRVHDFHSWHQXQFLHUWRQ~PHUR
GH HOORV XQD GpFLPD SDUWH GHO Q~PHUR
DQWHULRU
œ &RQGLFLyQGHSDUDGD6HWHUPLQDODE~VTXHGD
FXDQGR HO VLVWHPD VH KD HQIULDGR D XQD
GpFLPD (VWH YDORU VH REWXYR GH IRUPD
HPStULFDFRPRDSURSLDGR
(OHPHQWRVFRPXQHV
/RV HOHPHQWRV FRPXQHV D DPERV DOJRULWPRV VRQ
ORVGHSHQGLHQWHVGHOSUREOHPD
œ (VSDFLR GH VROXFLRQHV 6 (V HO FRQMXQWR GH
WRGRVORVSRVLEOHVFDOHQGDULRVGHH[iPHQHV
œ (VWUXFWXUD GH YHFLQGDG 67  6H GHILQH XQ
YHFLQR FRPR XQ FDOHQGDULR GRQGH HQ XQD GH
ODVWXSODVH[DPHQIHFKDVHPRGLILFDODIHFKD
GHOPLVPR
œ )XQFLyQ GH FRVWH IV 9DORU DVLJQDGR D OD
ERQGDGGHXQFDOHQGDULRGHH[iPHQHV
œ 6ROXFLyQ LQLFLDO V2  8QR GH ORV SRVLEOHV
FDOHQGDULRVGHH[iPHQHV6HJHQHUDGHIRUPD
WRWDOPHQWHDOHDWRULD
 3ODWDIRUPDGH*ULG&RPSXWLQJ
/DSODWDIRUPDXWLOL]DGDSDUDODHMHFXFLyQHQ*ULG
IXH$OFKHPL>@(VWDSODWDIRUPDHVWiHQGHVDUUROOR
HQODXQLYHUVLGDGGH0HOERXUQH6HWUDWDGHXQD
SODWDIRUPD GH OLEUH GLVWULEXFLyQ TXH SHUPLWH OD
LPSODQWDFLyQGHXQ*ULGHQXQDLQWUDQHWRDWUDYpV
GH,QWHUQHW6HHMHFXWDVREUHHOVLVWHPDRSHUDWLYR
0LFURVRIW:LQGRZV$GHPiVWLHQHODSRVLELOLGDG
GH LQWHUFRQH[LyQ FRQ VLVWHPDV *ULGEXV>@ D
WUDYpVGHVXXWLOLGDG&URVV3ODWDIRUP
/D SODWDIRUPD $OFKHPL HV XQ SURGXFWR PX\
VHQFLOOR SDUD FRQVHJXLU REWHQHU OD IXQFLRQDOLGDG
EiVLFDGH*ULG&RPSXWLQJ6XJUDQLQWHUpVUDGLFD
HQODIDFLOLGDGGHXWLOL]DUORHQXQHQWRUQRGRFHQWH
\ODSRVLELOLGDGGHTXHORVDOXPQRVSXHGDQYHUXQ
FyGLJRUHODWLYDPHQWHVHQFLOORGHIXQFLRQDPLHQWR
GHXQVLVWHPD*ULGFRQHOTXHSXHGHQLQWHUDFWXDU
XVI Jornadas de Paralelismo, JP '2005 373
/D SODWDIRUPD VH FRPSRQH GH WUHV SDUWHV
REOLJDWRULDV \ XQD RSFLRQDO /DV SDUWHV
REOLJDWRULDV SDUD VX IXQFLRQDPLHQWR VRQ ORV
FOLHQWHV GHO JULG OODPDGRV DOFKHPL H[HFXWRU HO
VHUYLGRUGHOJULGOODPDGRDOFKHPLPDQDJHU\XQD
EDVH GH GDWRV 0LFURVRIW 64/ 6HUYHU /D SDUWH
RSFLRQDO HV XQ PRQLWRU GHO VLVWHPD OODPDGR
DOFKHPLFRQVROHTXHSHUPLWHYLVXDOL]DUHOHVWDGR
GHHMHFXFLyQGHOJULG
/RVDOFKHPLH[HFXWRUUHFLEHQORVWUDEDMRVGHO
DOFKHPLPDQDJHU$OFKHPLPDQDJHUGLVWULEX\HOD
FDUJDGHWUDEDMRHQWUHORVFOLHQWHVFRQHFWDGRVHQ
HVHPRPHQWR\UHFLEHORVUHVXOWDGRVTXHJHQHUDOD
HMHFXFLyQHQORVFOLHQWHV
(Q OD EDVH GH GDWRV VH YDQ UHJLVWUDQGR ORV
WUDEDMRVHQHMHFXFLyQ\ORVHVWDGRVGHORVPLVPRV
/DSODWDIRUPDSHUPLWHGRVWLSRVGHHMHFXFLyQ
œ 3DUDOHOL]DGDV ORV SURJUDPDV VH HVFULEHQ
XWLOL]DQGR XQD $3, HQ OD TXH VH XWLOL]D HO
FRQFHSWRGH *ULG WKUHDGV GH IRUPD VLPLODU D
ORVWKUHDGVGHOVLVWHPDRSHUDWLYR&DGDWKUHDG
VH SODQLILFD VREUH XQR GH ORV HTXLSRV
FRQHFWDGRVDO*ULG
œ 3DUDPHWUL]DGDV VH HMHFXWD XQD DSOLFDFLyQ XQ
FLHUWR Q~PHUR GH YHFHV FRQ GLVWLQWRV
SDUiPHWURVGHHQWUDGD
(MHFXFLRQHVSDUDOHOL]DGDV
3DUD ODV HMHFXFLRQHV SDUDOHOL]DGDV VH XWLOL]D XQD
$3, TXH SURSRUFLRQD OD SODWDIRUPD SDUD HO
OHQJXDMH & (O GHVDUUROOR VH OOHYD D FDER
HQWRQFHV HQ HO HQWRUQR 9LVXDO 6WXGLR GH
0LFURVRIW (Q HVWH VHQWLGR SDUD ORV DOXPQRV
VXSRQH XQ VLVWHPD GH GHVDUUROOR FyPRGR 3DUD
DGHFXDUXQSURJUDPDKDEUtDTXHGHWHFWDUTXHSDUWH
HVSDUDOHOL]DEOHHQSULPHUOXJDU
/DFUHDFLyQGHXQSURJUDPDSDUDOHORVLJXHODV
VLJXLHQWHVIDVHV
œ &RQH[LyQ FRQ HO DOFKHPL PDQDJHU TXH
UHDOL]DUiODGLVWULEXFLyQGHORVJULGWKUHDGV
œ &UHDFLyQGHORVJULGWKUHDGV
œ /DQ]DPLHQWRGHORVJULGWKUHDGV
œ 5HFRJLGDGHORVUHVXOWDGRV&DGDJULGWKUHDG
TXH WHUPLQD JHQHUD XQ HYHQWR SDUD TXH HO
SURJUDPD TXH ODQ]y ODV HMHFXFLRQHV SXHGD
UHFRJHUHOUHVXOWDGRGHODHMHFXFLyQ
(VWH PRGHOR GH HMHFXFLRQHV SDUDOHOL]DGDV VH
SUHVWDGHIRUPDHVSHFLDODOGHVDUUROORGHSUiFWLFDV
GH ODERUDWRULR \D TXH VH FRQVLJXH DSOLFDU ODV
WpFQLFDV GH SDUDOHOL]DFLyQ GH SURJUDPDV \ VX
HMHFXFLyQUHDOHQXQHQWRUQRGLVWULEXLGR
(MHFXFLyQSDUDPHWUL]DGD
0HGLDQWH XQD XWLOLGDG OODPDGD DOFKHPL %ODVW HO
XVXDULR FRQILJXUD XQ DUFKLYR ;0/ HQ HO TXH VH
GHILQHQODVWDUHDVDODOFKHPLPDQDJHUHQUHDOLGDG
VHYDQDFRQYHUWLUHQJULGWKUHDGVLQGHSHQGLHQWHV
ORVDUFKLYRVTXHVHGHVHHQHMHFXWDU\SDUiPHWURV
GHHQWUDGD\VDOLGDHQWUHORVTXHVHSXHGHQLQFOXLU
DUFKLYRVGHGDWRVGHHQWUDGD
/D HMHFXFLyQ GH FDGD WDUHD HV LQGHSHQGLHQWH
GH ODV GHPiV XWLOL]DQGR FDGD XQD VXV SURSLRV
SDUiPHWURVGHHQWUDGD/DXWLOLGDGGHHVWHPRGHOR
HVWi HQ HMHFXWDU XQD PLVPD DSOLFDFLyQ FRQ
GLVWLQWRV SDUiPHWURV GH HQWUDGD HQ FDGD JULG
WKUHDG
%DWHUtDVGHSUXHEDV
3DUD SRGHU KDFHU FRPSDUDWLYDV DSURSLDGDV VREUH
XQDOWRQ~PHURGHHMHFXFLRQHVGHORVDOJRULWPRV
VH HPSOHy OD SODWDIRUPD GH *ULG &RPSXWLQJ GH
IRUPD TXH QRV SHUPLWLHVH HMHFXWDU WRGDV ODV
SUXHEDVHQXQWLHPSRUD]RQDEOH
6LQ HPEDUJR OD SURSLD SODWDIRUPD QR QRV
SHUPLWH UHDOL]DU XQD FRPSDUDFLyQ TXH VXHOH VHU
KDELWXDOGHWLHPSRVGHHMHFXFLyQ\DTXHHOWLHPSR
WRWDO GH HMHFXFLyQ GHSHQGH GH IDFWRUHV FRPR OD
FDUJDGHODUHGRODXWLOL]DFLyQGHORVHTXLSRV(OOR
VHGHEHDTXHORVHTXLSRVXWLOL]DGRVVHHQFXHQWUDQ
GLVSHUVRV HQ YDULRV ODERUDWRULRV LQFOXVR HQ
HGLILFLRVGLIHUHQWHVSXHGHQHVWDUVHXWLOL]DQGRSRU
SDUWH GH ORV DOXPQRV GXUDQWH OD HMHFXFLyQ \
DXQTXH VH KD LQWHQWDGR PLQLPL]DU HVWH VHJXQGR
DVSHFWRQRVHKDSRGLGRGHVFDUWDU
(QHVWHVHQWLGRODFRPSDUDFLyQVHKDUHDOL]DGR
VREUH GRV HOHPHQWRV TXH VRQ QHXWURV HQWUH ORV
DOJRULWPRVHOYDORUREWHQLGRSDUDODVROXFLyQHO
Q~PHUR GH VROXFLRQHV WRWDOHV DQDOL]DGDV \ HO
Q~PHURGHVROXFLyQJHQHUDGDGRQGHVHHQFRQWUyOD
PHMRUVROXFLyQ
(OQ~PHURGHSUXHEDVHVWLPDGDSDUDTXHIXHVH
VXILFLHQWHPHQWHVLJQLILFDWLYRVHHVWDEOHFLyHQ
SUXHEDV SDUD FDGD XQR GH ORV DSDUWDGRV /RV
GLVWLQWRV SDUiPHWURV TXH VH SUREDURQ SDUD FDGD
XQR GH ORV DOJRULWPRV IXHURQ ORV VLJXLHQWHV
GHVSXpV GH UHDOL]DU SUXHEDV EUHYHV GH XQDV 
HMHFXFLRQHV SDUD UHDOL]DU XQ VFUHHQLQJ GH OR
DSURSLDGRGHODHOHFFLyQGHORVSDUiPHWURV
374 Tecnologías Grid, Clusters y Plataformas Distribuidas






















































 
    

    

   
     
 
      
   ! # ! % &  ( ) % + , 
- . . 0
. . 2
. . 4
. . 6
. . 7
. .
0
.
4
.
7
. 8
.
- . .
0 9
7
.
0 9
8
.
0
8
. .
0
8
0
.
0
8
4
.
0
8
7
.
0
8 8
.
0 :
. .
; < = > ?
@
> ? A B ;
@
< C ? =
> B D B E <
F @
= > B > B G H
I J K L M N M O P J R S O T U K

V
W X Z \ ]
^
_ a c d e f g f i W c k ] \ ] f n ] n X c \ W e g c i f q r d s Z f i ] e ] q r
v w x y z { | x |
}
~ }
 }
€ }
 }
‚ } }
‚ ~ }
‚  }
‚ € }
} ƒ „ } ƒ € } ƒ ‡ } ƒ  } ƒ ‰ } ƒ ‰ „ } ƒ ‰ € } ƒ ‰ ‡ } ƒ ‰  } ƒ ‰ ‰
Ž   ‘ ’ “
”•–
— ˜
™ š › œ  ž Ÿ   ¡ ¢ £ ¤ £
¥
¦ ¥ ¥ ¥ ¥ ¥
§ ¥ ¥ ¥ ¥ ¥
¨ ¥ ¥ ¥ ¥ ¥
© ¥ ¥ ¥ ¥ ¥
ª ¥ ¥ ¥ ¥ ¥ ¥
ª ¦ ¥ ¥ ¥ ¥ ¥
ª § ¥ ¥ ¥ ¥ ¥
ª ¨ ¥ ¥ ¥ ¥ ¥
ª © ¥ ¥ ¥ ¥ ¥
¦ ¥ ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À
™ š › œ  ž Ÿ Á ¡ › ¤ š Á š   › ¤ ¢ £ ¤ £
¥
¬ ¥ ¥ ¥ ¥ ¥
ª ¥ ¥ ¥ ¥ ¥ ¥
ª ¬ ¥ ¥ ¥ ¥ ¥
¦ ¥ ¥ ¥ ¥ ¥ ¥
¦ ¬ ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À
v w x y z | x |
}
~ }
 }
€ }
 }
‚ } }
‚ ~ }
‚  }
‚ € }
‚  }
~ } }
} ƒ „ } ƒ € } ƒ ‡ } ƒ  } ƒ ‰ } ƒ ‰ „ } ƒ ‰ € } ƒ ‰ ‡ } ƒ ‰  } ƒ ‰ ‰
Ž   ‘ ’ “
”•–
— ˜
™ š › œ  ž Ÿ   ¡ £ ¤ £
¥
¦ ¥ ¥ ¥ ¥ ¥
§ ¥ ¥ ¥ ¥ ¥
¨ ¥ ¥ ¥ ¥ ¥
© ¥ ¥ ¥ ¥ ¥
ª ¥ ¥ ¥ ¥ ¥ ¥
ª ¦ ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À
™ š › œ  ž Ÿ Á ¡ › ¤ š Á š   › ¤ £ ¤ £
¥
¦ ¥ ¥ ¥ ¥ ¥
§ ¥ ¥ ¥ ¥ ¥
¨ ¥ ¥ ¥ ¥ ¥
© ¥ ¥ ¥ ¥ ¥
ª ¥ ¥ ¥ ¥ ¥ ¥
ª ¦ ¥ ¥ ¥ ¥ ¥
ª § ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À
Ã Ä Å
    Å 

 
 
 

 

 
                                
     


™ š › œ  ž Ÿ   ¡ " # $ £ ¤ £
¥
ª ¥ ¥ ¥ ¥ ¥
¦ ¥ ¥ ¥ ¥ ¥
% ¥ ¥ ¥ ¥ ¥
§ ¥ ¥ ¥ ¥ ¥
¬ ¥ ¥ ¥ ¥ ¥
¨ ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À
™ š › œ  ž Ÿ Á ¡ › ¤ š Á š   › ¤ " # $ £ ¤ £
¥
ª ¥ ¥ ¥ ¥ ¥
¦ ¥ ¥ ¥ ¥ ¥
% ¥ ¥ ¥ ¥ ¥
§ ¥ ¥ ¥ ¥ ¥
¬ ¥ ¥ ¥ ¥ ¥
¨ ¥ ¥ ¥ ¥ ¥
¯ ¥ ¥ ¥ ¥ ¥
¥ « ¬ ¥ « ¨ ¥ « ¯ ¥ « © ¥ « ° ¥ « ° ¬ ¥ « ° ¨ ¥ « ° ¯ ¥ « ° © ¥ « ° °
´ µ ¶ · ¸ ¹
º»¼
½ ¾¿À

V
W X Z \ ]
Ç
_ a c g k c \ e ] g W f É e c i f n ] n X c \ W e g c i f \ f Ê c Ê W i c _
3DUD E~VTXHGD WDE~ VH WXYLHURQ HQ FXHQWD HO
WDPDxRGHODOLVWDWDE~FRQYDORUHVHQWUH\
DLQWHUYDORVGH\HOQ~PHURGHLWHUDFLRQHVGHO
DOJRULWPRTXHVHUHDOL]DQFRQYDORUHVHQWUH\
 FRQ LQWHUYDORV GH  (O WRWDO GH SUXHEDV
UHDOL]DGDVIXHSRUWDQWRGH
3DUD HO DOJRULWPR GH UHFRFLGR VH WXYLHURQ HQ
FXHQWDHOIDFWRUGHHQIULDPLHQWRFRQYDORUHVHQWUH
\FRQLQWHUYDORVGH\HQWUH\
FRQLQWHUYDORVGH\HOWDPDxRGHODFDGHQD
GH0DUNRYFRQYDORUHV_6__6_\_6_(OWRWDO
GH SUXHEDV UHDOL]DV IXH SRU WDQWR WDPELpQ GH

(O WLHPSR GH HMHFXFLyQ HVWLPDGR SDUD WRGDV
ODVSUXHEDVHQXQ~QLFR3&ODHVWLPDPRVHQK
 GtDV ODERUDEOHV (MHFXWDQGR HQ HO *ULG VH
WDUGyHQSDVDUODVSUXHEDVXQDVKRUDV
(Q HO FDVR GHO DOJRULWPR GH UHFRFLGR VH
HOLJLHURQORVYDORUHVGHOIDFWRUGHHQIULDPLHQWRWDQ
GLVSDUHVSDUDFRPSUREDUWDPELpQVLFRQWDVDVGH
HQIULDPLHQWR PX\ UiSLGDV VH SRGUtDQ REWHQHU
VROXFLRQHV UD]RQDEOHPHQWH EXHQDV HQ XQ WLHPSR
PX\FRUWR3DUDFDGDXQRGHORVDOJRULWPRVVH
XVI Jornadas de Paralelismo, JP '2005 375

   

 

 

 

 

 

         
!"
# $
%&
'
%
' (
)
!
&
 *
*

+  *


, 



, 



,

- . / 0 1 2
3
4 3 3 3 3 3
5 3 3 3 3 3
6 3 3 3 3 3
7 3 3 3 3 3
8 3 3 3 3 3 3
8 4 3 3 3 3 3
8 5 3 3 3 3 3
4 9 3 3 4 6 3 3 4 ; 3 3 4 7 3 3 4 > 3 3 ? 3 3 3 ? 8 3 3
@ A B C D E F G F E A
JKL
M N
OP
Q
O
Q R
S
K
P
4 T
T
3 U 9 T
8 3 3 V 4 3 3
? 3 3 V 5 3 3
9 3 3 V 6 3 3


    X
Z   
          
       !    "   
   

SUREyVXFRPSRUWDPLHQWRFRQGRVFDOHQGDULRVGH
H[iPHQHVGLIHUHQWHVXQRFRQXQDSODQLILFDFLyQD
ORODUJRGHFXDWURVHPDQDVGtDVTXHUHVXOWDVH
UHODWLYDPHQWH VHQFLOOR GH HQFRQWUDU EXHQDV
VROXFLRQHVSRUODSURSLDGLVSHUVLyQGHODVPLVPDV
\ RWUR HQ GRV VHPDQDV  GtDV TXH JHQHUDVH
VROXFLRQHVGHQVDV
3DUD OD SODWDIRUPD GH HMHFXFLyQ VH XWLOL]DURQ
3&GHODERUDWRULR
œ  3& 3HQWLXP ,9 *+] 0% 5$0
FRQ:LQGRZV
œ 3&3HQWLXP,9*+]0%5$0FRQ
:LQGRZV
œ 3&3HQWLXP,9*+]0%5$0FRQ
:LQGRZV17
(OHMHFXWRUGH$OFKHPLVHLQVWDOyHQWRGRVORV
HTXLSRVFRPRXQVHUYLFLRGHOVLVWHPD
 5HVXOWDGRV
8QUHVXPHQGHORVUHVXOWDGRVREWHQLGRVVHSXHGH
YHUHQODVJUiILFDVGHODUWtFXOR3DUDHOFDVRGHOD
HMHFXFLyQ GHO DOJRULWPR GH E~VTXHGD WDE~ HQ OD
)LJXUDVHSXHGHREVHUYDUHOFRPSRUWDPLHQWRHO
YDORUREWHQLGRGHOFRVWHPHGLRUHVSHFWRDOQ~PHUR
GHLWHUDFLRQHV\HOWDPDxRGHODOLVWDWDE~
œ (Q DPEDV JUiILFDV VH REVHUYD TXH D PD\RU
Q~PHURGHLWHUDFLRQHVHOYDORUPHGLRGHFRVWH
REWHQLGRYDPHMRUDQGRDXQTXHHQHOVHJXQGR
FDVRHVPXFKRPHQRVVLJQLILFDWLYR
œ 3DUD HO FDVR GH  GtDV GRQGH REWHQHU XQD
VROXFLyQ HV PiV VHQFLOOR FRQVLJXH KDOODU
EXHQDVVROXFLRQHVPX\UiSLGDPHQWHPLHQWUDV
HQ SDUD  GtDV DO DXPHQWDU HO Q~PHUR GH
LWHUDFLRQHV YD PHMRUDQGR HO YDORU PHGLR GH
FRVWHREWHQLGR(OWDPDxRGHODOLVWDWDE~WLHQH
XQ FRPSRUWDPLHQWR GLIHUHQWH HQ DPERV
SUREOHPDV PLHQWUDV TXH SDUD SRFRV GtDV HV
PHMRU XQ WDPDxR EDVWDQWH JUDQGH SDUD
PXFKRVGtDVVHFRPSRUWDPHMRUXQDOLVWDWDE~
SHTXHxD
(QOD)LJXUDVHSUHVHQWDQORVUHVXOWDGRVSDUD
UHFRFLGR6HKDQHOHJLGRODVJUiILFDVGHOHMHPSOR
SDUD  GtDV SHUR SDUD HO FDVR GH  GtDV HO
FRPSRUWDPLHQWR \ FRQFOXVLRQHV VRQ H[DFWDPHQWH
LJXDOHVOD~QLFDYDULDFLyQHVHQORVYDORUHVILQDOHV
GHO FRVWH GH ODV VROXFLRQHV JHQHUDGDV (Q ODV
JUiILFDVVHSXHGHREVHUYDUTXHHOFRPSRUWDPLHQWR
GHVLPXODWHGDQQHDOLQJHVPXFKRPiVSUHGHFLEOH
FRQUHVSHFWRDORVSDUiPHWURV(QODVWUHVJUiILFDV
GH OD SDUWH GH OD L]TXLHUGD VH SXHGH REVHUYDU HO
FRVWHPi[LPRPHGLR\PtQLPRREWHQLGR(QODV
WUHV JUiILFDV FHQWUDOHV VH UHSUHVHQWD HO YHFLQR
YLVLWDGRHQHOTXHVHKDORJUDGRHOYDORUGHFRVWH
PtQLPR (Q ODV WUHV JUiILFDV GH OD GHUHFKD VH
REVHUYDHOQ~PHURWRWDOGHYHFLQRVYLVLWDGRVHQOD
HMHFXFLyQ'HHOODVVHGHGXFHTXHDODXPHQWDUHO
IDFWRUGHHQIULDPLHQWR
œ /DVROXFLyQREWHQLGDPHMRUDWDQWRHQHOYDORU
Pi[LPRFRPRHQHOPHGLRFRPRHOPtQLPR
œ /DGHVYLDFLyQGHORVUHVXOWDGRVGLVPLQX\HOR
TXH VH REVHUYD YLHQGR TXH GLVPLQX\H OD
GLIHUHQFLDHQWUHHOFRVWHPi[LPR\HOPtQLPR
œ $O DXPHQWDU HO WDPDxR GH OD FDGHQD GH
0DUNRY HO FRVWH PtQLPR PHMRUD SHUR QR
VXVWDQFLDOPHQWH'HKHFKRHOYDORUPtQLPRHV
HOPLVPRHQORVWUHVFDVRV\ORVYDORUHV
PHGLRV TXH VH REWLHQHQ SDUD HO FRQMXQWR GH
HMHFXFLRQHV VRQ UHVSHFWLYDPHQWH 
\
œ (O Q~PHUR GH VROXFLRQHV YHFLQRV TXH KD\
TXH YLVLWDU SDUD REWHQHU HO FRVWH PtQLPR YD
DXPHQWDQGR

376 Tecnologías Grid, Clusters y Plataformas Distribuidas
 


   


                      
          
          
$       


œ (O Q~PHUR GH VROXFLRQHV YHFLQRV WRWDOHV

JHQHUDGDVDXPHQWD
(Q OD )LJXUD  VH SXHGH YHU XQ JUiILFR GH
GLVSHUVLyQGHORVUHVXOWDGRVGHFRPSRUWDPLHQWRGH
DPERV DOJRULWPRV 6H KDQ UHPDUFDGR ORV
UHVXOWDGRV GH E~VTXHGD WDE~ (Q HVWH JUiILFR VH
SXHGH REVHUYDU FRPR YDUtD HO FRVWH PHGLR D OD
L]TXLHUGD\HOFRVWHPtQLPRDODGHUHFKDIUHQWH
DO Q~PHUR WRWDO GH YHFLQRV YLVLWDGRV 6H SXHGH
REVHUYDUTXH
œ %~VTXHGD WDE~ UHVXOWD PiV FRQVLVWHQWH HQ
FXDQWRDOUHVXOWDGR
œ 5HFRFLGR UHVXOWD PXFKR PiV SUHGHFLEOH HQ
FXDQWRDODUHODFLyQFRVWHQ~PHURGHYHFLQRV
 &RQFOXVLyQ
/D XWLOL]DFLyQ GH XQ VLVWHPD GH *ULG HQ OD
GRFHQFLD SHUPLWH D ORV DOXPQRV GLVSRQHUGH XQD
SODWDIRUPD GH HMHFXFLyQ GRQGH SUREDU GH IRUPD
PX\UiSLGDFLHUWRVDOJRULWPRVTXHGHRWUD IRUPD
OHV VXSRQGUtDXQ WLHPSR H[FHVLYR3RU RWUDSDUWH
VXSRQHXQHOHPHQWRPX\LQWHUHVDQWHTXHDEDMR
FRVWH SHUPLWH GLVSRQHU GH XQ VLVWHPD PX\
DSURSLDGRGHHMHFXFLyQGLVWULEXLGD
(QFXDQWRDOWUDEDMRSUHVHQWDGRHVGHGHVWDFDU
HOLQWHUpVGHUHDOL]DUODFRPSDUDWLYDSDUDQXHVWUR
FDVR GHO DOJRULWPR XWLOL]DGR SHUPLWLpQGRQRV
WRPDU XQD GHFLVLyQDSURSLDGD GHXVRGHDFXHUGR
FRQQXHVWURSUREOHPDFRQFUHWRDUHVROYHU
$XQTXHQRVHKDSUHVHQWDGRH[SOtFLWDPHQWHHQ
HODUWtFXORHOWUDEDMRHQFRQMXQWRFRQORVDOXPQRV
QRVKDSHUPLWLGRGRWDUDOVLVWHPD*ULGGHXQIURQW
HQGEDVDGRHQ:HETXHSHUPLWHDXQDOXPQRR
XVXDULR HQ JHQHUDO SUHYLD LGHQWLILFDFLyQ HQYLDU
XQDDSOLFDFLyQGHFXDOTXLHUDGHORVGRVWLSRVTXH
VH FRPHQWDQ HQ OD VHFFLyQ  \ REWHQHU OD
LQIRUPDFLyQ GH HMHFXFLyQ \ ORV UHVXOWDGRV GH OD
PLVPD (Q OD )LJXUD  VH SUHVHQWD D PRGR GH
HMHPSOR XQ YROFDGR GH SDQWDOOD GH OD SiJLQD GH
UHVXOWDGRV GH HMHFXFLyQ GH DSOLFDFLRQHV GH
HMHPSOR
(VWHSRUWDOGHDFFHVRDOVLVWHPDGHHMHFXFLyQ
GLVWULEXLGDUHVXOWDGHJUDQLQWHUpVSDUDGRWDUDORV
DOXPQRVGHXQPHFDQLVPR IOH[LEOHGHHMHFXFLyQ
LQFOXVR GHVGH IXHUD R QR GHO SURSLR UHFLQWR
XQLYHUVLWDULR
6LQ HPEDUJR KD\ TXH WHQHU FXLGDGR FRQ HO
VLVWHPDHQFXDQWRDODVHJXULGDGGHHMHFXFLyQGH
DSOLFDFLRQHV \D TXH QR HV SRVLEOH FRQWURODU HO
XVI Jornadas de Paralelismo, JP '2005 377
FRQWHQLGRGHODHMHFXFLyQGHODVPLVPDV(QHVWH
VHQWLGR HVWDPRV EDUDMDQGR OD LGHD GH HMHFXWDU HO
HQWRUQR VREUH XQ VLVWHPD RSHUDWLYR YLUWXDOL]DGR
GHPDQHUDTXHXQSRVLEOHXVRPDOLFLRVRQRDIHFWH
D OD PDTXLQD VXE\DFHQWH \ QRV SHUPLWD WHQHU XQ
HQWRUQR³VHJXUR´SDUDORVDOXPQRV
5HIHUHQFLDV
>@$EUDPVRQ'&RQVWUXFWLQJVFKRROWLPHWDEOHV
XVLQJ VLPXODWHG DQQHDOLQJ VHTXHQWLDO DQG
SDUDOOHO DOJRULWKPV 0DQDJHPHQW 6FLHQFH 
±
>@&RORUQL $ 'RULJR 0 0DQLH]]R 9
0HWDKHXULVWLFV IRU +LJK6FKRRO 7LPHWDEOLQJ
&RPSXWDWLRQDO 2SWLPL]DWLRQ DQG
$SSOLFDWLRQV±
>@'XQFDQ - /RLWHQ $ :HOVK . $OFKHPL
WXWRULDO2WRxRKWWSZZZHQJXDKHGX
aZHOVFKN$OFKHPL7XWRULDOKWPO
>@(%XUNH<%\NRY-1HZDOODQG63HWURYLF
³$ 7LPH3UHGHILQHG /RFDO 6HDUFK $SSURDFK
WR ([DP 7LPHWDEOLQJ 3UREOHPV´ &RPSXWHU
6FLHQFH 7HFKQLFDO 5HSRUW 1R 1277&675
8QLYRI1RWWLQJKDP
>@*ORYHU)/DJXQD0³7DEX6HDUFK´.OXZHU

>@.LUNSDWULFN 6 *HODWW &' \ 9HFFKL 03
³2SWLPL]DWLRQ E\ 6LPXODWHG $QQHDOLQJ´
6FLHQFHYROSS
>@/'L*DVSHURDQG$6FKDHUI³7DEX6HDUFK
7HFKQLTXHV IRU ([DPLQDWLRQ 7LPHWDEOLQJ´
7KH 3UDFWLFH DQG 7KHRU\ RI $XWRPDWHG
7LPHWDEOLQJ 3$7$7  6HOHFWHG 3DSHUV
(%XUNHDQG:(UEHQ(GV/HFWXUH1RWHV
LQ &RPSXWHU 6FLHQFH  6SULQJHU9HUODJ

>@/7*0HUORW1%RODQG%'+XJKHV 
3 - 6WXFNH\ ³$ +\EULG $OJRULWKP IRU WKH
([DPLQDWLRQ 7LPHWDEOLQJ 3UREOHP´ 3URF
3UDFWLFH DQG 7KHRU\ RI $XWRPDWHG
7LPHWDEOLQJ3$7$7¶
>@0 : &DUWHU DQG * /DSRUWH ³5HFHQW
'HYHORSPHQWV LQ 3UDFWLFDO ([DPLQDWLRQ
7LPHWDEOLQJ´ ,Q 3UDFWLFH DQG 7KHRU\ RI
$XWRPDWHG 7LPHWDEOLQJ )LUVW ,QWHUQDWLRQDO
&RQIHUHQFH 6HOHFWHG 3DSHUV ( %XUNH  3
5RVV (GV (GLQEXUJK 8.
$XJXVW6HSWHPEHU  /HFWXUH 1RWHV LQ
&RPSXWHU 6FLHQFH  6SULQJHU9HUODJ 

>@3UR\HFWR*ULG%XVHQKWWSZZZJULGEXVRUJ
>@6FKDHUI$7DEXVHDUFKWHFKQLTXHVIRUODUJH
KLJKVFKRROWLPHWDEOLQJSUREOHPV5HSRUW&6
5 &HQWUXP YRRU :LVNXQGH HQ
,QIRUPDWLFD$PVWHUGDP
>@6RX]D 0-) 2FKL /6 0DFXODQ 1 $
*5$637DEX VHDUFK DOJRULWKP IRU VROYLQJ
VFKRRO WLPHWDEOLQJ SUREOHPV ,Q 5HVHQGH
0*& 6RX]D -3 HGV 0HWDKHXULVWLFV
&RPSXWHU 'HFLVLRQ0DNLQJ .OXZHU
$FDGHPLF3XEOLVKHUV%RVWRQ±
>@7XDQ$QK 'XRQJ .LP+RD /DP
³&RPELQLQJ &RQVWUDLQW 3URJUDPPLQJ DQG
6LPXODWHG $QQHDOLQJ RQ 8QLYHUVLW\ ([DP
7LPHWDEOLQJ´ ,QWO &RQI 5,9)¶
)HEUXDU\+DQRL9LHWQDP
>@:LONH3*UŽREQHU02VWHU1$K\EULG
JHQHWLF DOJRULWKP IRU VFKRRO WLPHWDEOLQJ ,Q
$,  0F.D\ % DQG 6ODQH\ - HGV
$GYDQFHV LQ $UWLILFLDO ,QWHOOLJHQFH 6SULQJHU
/HFWXUH 1RWHV LQ &RPSXWHU 6FLHQFH 9RO
 6SULQJHU9HUODJ 1HZ <RUN 
±

378 Tecnologías Grid, Clusters y Plataformas Distribuidas
Soporte para el análisis de workloads en el proyecto eNANOS
Ivan Rodero, Julita Corbalán, Alejandro Duran, Jesús Labarta
Dept. Arquitectura de Computadors
Universitat Politècnica de Catalunya
Campus Nord. Jordi Girona 1-3
08034 Barcelona
{irodero, juli, aduran, jesus}@ac.upc.edu
Resumen
El proyecto eNANOS plantea la planificación
coordinada de trabajos entre varios niveles, desde
el entorno heterogéneo y dinámico de un Grid
hasta la ejecución de procesos y threads en las
CPU’s de un computador o un cluster. Para
estudiar las políticas de planificación se necesita
algún mecanismo de análisis de workloads. En
este artículo presentamos un mecanismo de
monitorización de trabajos integrado en el
planificador eNANOS Scheduler. También
presentamos una herramienta que a partir de la
información obtenida en la monitorización es
capaz de generar trazas que pueden ser
visualizadas y analizadas fácilmente con Paraver.
Para mostrar las ventajas del sistema planteado se
presenta la evaluación de un workload y se
compara con posibles alternativas.
1. Introducción
La planificación de trabajos en Grid es todavía
una cuestión que hay que resolver y en la cual se
están dedicando muchos esfuerzos. Normalmente
un Grid está formado por diversos recursos que
pertenecen a diferentes propietarios. Estos
recursos no tienen porqué estar dedicados
exclusivamente para ser utilizados por el Grid.
También hay que tener en cuenta que los recursos
Grid por definición son heterogéneos y tienen un
comportamiento muy dinámico. Por lo tanto, lo
más habitual es que los recursos de altas
prestaciones (HPC) de un Grid dispongan de
sistemas de planificación locales. Estos sistemas
de encargan de gestionar la planificación de los
trabajos a nivel local de un cluster mediante
sistemas de colas.
Esto nos sugiere que necesitaremos un modelo
de planificación global diferente al que se utiliza
habitualmente en un entorno local o centralizado.
Será necesario añadir un nuevo nivel de
planificación que se coordine con los diversos
gestores locales que se encuentran en los recursos
computacionales. Por lo tanto las decisiones de
planificación a nivel Grid deben ser tomadas
siendo conscientes de la información obtenida en
los niveles inferiores. Así, se pretende realizar una
planificación eficaz haciendo un uso óptimo de los
recursos del Grid. También hay que tener en
cuenta que un planificador o broker de Grid no
tiene control directo sobre los recursos
computacionales, por lo tanto necesita un
planificador local que los gestione. Aunque se está
trabajando en definir una arquitectura en la
planificación en Grid [21] todavía no se ha
decidido y no hay disponible ningún estándar. De
todos modos parece razonable pensar que estas
capas de planificación necesitan interactuar entre
ellas. Tampoco está claro el tipo de jerarquía que
debe formarse entre los distintos niveles de
planificación.
En nuestra propuesta planteamos la
planificador coordinada de tres niveles, desde el
Grid hasta la gestión de procesadores. De
momento hemos implementado la coordinación
entre los dos niveles inferiores de la arquitectura.
Para analizar el comportamiento del sistema
aplicando la coordinación entre eNANOS
Scheduler y NANOS-RM se necesita algún
mecanismo para analizar los workloads. En este
artículo presentamos una herramienta que nos
permite analizar y visualizar los workloads de
forma sencilla. A partir de la información de
monitorización en formato XML proporcionada
por el eNANOS Scheduler se genera una traza que
puede ser analizada con la herramienta de análisis
y visualización Paraver [2]. Este mecanismo nos
permitirá incluir la información de todos los
niveles de planificación en una única traza. La
información obtenida mediante estas trazas nos
permitirá analizar y mejorar las distintas políticas
de planificación, así como comprender el
comportamiento de nuestro entorno de ejecución.
El resto del artículo está organizado como
sigue a continuación. En el apartado 2 se presenta
la propuesta del proyecto eNANOS. En el
apartado 3 se hace un resumen de los principales
trabajos relacionados. Los apartados 4 y 5
presentan las principales características del
eNANOS Scheduler y del NANOS-RM
respectivamente. En el apartado 6 se expone el
mecanismo de monitorización y la herramienta
para generar las trazas. Mediante ejemplos reales,
en el apartado 7 se evalúan varios mecanismos
para analizar workloads y se muestra la utilidad de
la herramienta desarrollada. Finalmente en el
apartado 8 se presentan las conclusiones y las
posibles líneas de trabajo futuro.
2. Visión general del proyecto eNANOS
Nuestro proyecto se centra en la planificación
coordinada y de forma integral de todos los
componentes involucrados en la ejecución de
aplicaciones HPC en Grid, desde nivel Grid hasta
la planificación de procesadores. No sólo
queremos coordinar el planificador Grid con los
planificadores de los distintos recursos, sino que
queremos realizar la planificación consciente de
todos los niveles involucrados. Consideramos tres
niveles de planificación básicos, desde el entorno
heterogéneo y dinámico de un Grid hasta la
ejecución eficaz de procesos y threads en una o
varias CPU de un computador o un cluster. En la
Figura 1 se muestra un esquema de los principales
componentes involucrados. También se puede
apreciar el flujo de información, tanto la existente
(en negrita) como la que tenemos prevista añadir
más adelante (más claro). Esta información es
parte de la que se necesita para realizar la
planificación de forma coordinada
Este trabajo se enmarca dentro del proyecto
eNANOS [3] cuyo objetivo principal es la gestión
autónoma de recursos, una de las tareas necesarias
del autonomic computing [11]. Teniendo en
cuenta que la tecnología Grid es muy extensa, este
proyecto se centra en la ejecución de aplicaciones
paralelas de altas prestaciones en Grids
compuestos de computadores paralelos, con
arquitecturas de memoria compartida (SMP i CC-
NUMA) con un número medio-alto de
procesadores por nodo (16-128 CPU’s).
En aplicaciones HPC para Grid se acostumbra
a utilizar modelos de programación paralela como
es el caso de MPI o PVM. Estos modelos tienen
ciertas carencias de rendimiento en las
arquitecturas basadas en SMP. Nosotros
planteamos la utilización del modelo híbrido
MPI+OpenMP.
También hay que tener en cuenta que para
realizar una planificación eficiente es muy
importante la monitorización tanto de los recursos
como de las aplicaciones. Normalmente los
sistemas de monitorización se encargan de
proporcionar información sobre los recursos e
información muy general sobre la carga de las
CPU’s de los nodos. Nosotros queremos
proporcionar información más concreta sobre el
comportamiento de las aplicaciones, por ejemplo
el speedup que está obteniendo. Este tipo de
información dinámica nos podrá servir para tomar
decisiones de planificación, como puede ser la
ejecución de nuevas aplicaciones o la migración
de ciertos procesos o threads.
El primer paso realizado fue desarrollar un
resource broker, el eNANOS broker [18]. Este
broker está desarrollado sobre Globus Toolkit 3
como Grid Service y es compatible tanto con GT2
como con GT3. Para gestionar la planificación a
nivel local hemos implementado un planificador,
eNANOS Scheduler, que interactúa con el sistema
de colas LoadLeveler mediante su API. La
planificación a nivel de CPU’s se realiza a través
del NANOS-RM, sus principales características se
exponen en el apartado 5. Hemos adaptado el
NANOS-RM para proporcionar al eNANOS
Scheduler información sobre el comportamiento
de las aplicaciones de forma dinámica.
Figura 1. Coordinación entre los componentes del
proyecto eNANOS
380 Tecnologías Grid, Clusters y Plataformas Distribuidas
3. Trabajo relacionado
Existen diversas iniciativas que atacan de forma
individual la problemática de planificación en los
tres niveles que proponemos en nuestro proyecto.
Por un lado podemos encontrar diversos proyectos
de meta-schedulers o resource brokers para Grid
como son AppLes [1], Condor-G [6], EZ-Grid[5],
GridBus [14], GridLab Resource Management
System (GRMS) [7], o GridWay [8]. Estos
implementan diversas políticas como pueden ser
económicas, basadas en la información obtenida
de la monitorización de los recursos o mediante
mecanismos de predicción basados en
información histórica o heurísticas.
Por otro lado hay varios planificadores para
recursos de altas prestaciones (clusters) y que
trabajan de forma externa a los sistemas de colas,
por ejemplo MAUI scheduler [12], EASY [19] o
OAR Scheduler [17]. Estos planificadores
implementan diversas políticas y soportan
mecanismos como por ejemplo las advanced
reservations. También se pueden encontrar
diversos sistemas de monitorización que dan
soporte para Grid como pueden ser NWS [16],
Mercury [13] o Globus MDS [9].
A pesar de esto no conocemos ningún
proyecto que implemente la coordinación de todos
estos niveles tal y como proponemos en el
proyecto eNANOS. Del mismo modo tampoco
conocemos ninguna herramienta que nos permita
analizar los workloads en los tres niveles de forma
integral.
4. eNANOS Local Scheduler
El eNANOS Scheduler es el responsable de
ejecutar y controlar los trabajos que hay encolados
en el sistema de colas mediante la API que
proporciona LoadLeveler. Este planificador se
comunica con el NANOS-RM para obtener
información relacionada con el comportamiento
de las aplicaciones y de los recursos locales, y con
el eNANOS Broker para proporcionar
información al nivel superior. Adicionalmente,
está previsto que el planificador se comunique con
un servicio de predicción y un sistema de
información que están en desarrollo. También
proporciona información de log y monitoriza los
trabajos proporcionando una descripción detalla
de los workloads en formato XML.
El modulo principal del planificador se
encarga de controlar todos los trabajos que
encuentra en el sistema de colas de LoadLeveler.
Como es habitual, el funcionamiento es cíclico,
periódicamente el planificador realiza las
siguientes funciones básicas:
x Consulta los trabajos de sistema de colas
x Actualiza la información del sistema
x Evalúa la política de planificación
x Ejecuta los trabajos seleccionados
La configuración básica del scheduler se
realiza a través de un fichero de configuración. Se
pueden definir parámetros como puertos de
comunicación, nombres de ficheros, o el nivel de
multiprogramación inicial.
La comunicación con los otros componentes
de la arquitectura del sistema se realiza mediante
dos threads. El primero se encarga de interactuar
con el NANOS-RM. Éste recibe información del
runtime sobre el nivel de multiprogramación
admitido por los nodos u otra información
relacionada con las aplicaciones y el hardware,
por ejemplo la carga de los nodos, o las CPU’s
que utiliza cada thread OpenMP. El segundo
notifica los cambios relacionados con la ejecución
de los trabajos o con los recursos que puedan ser
relevantes para el nivel Grid. También puede
recibir instrucciones del broker pero como
actualmente esta parte está en desarrollo, de
momento la comunicación entre los dos
componentes se realiza indirectamente mediante
el jobmanager de Globus y variables de entorno.
Actualmente el scheduler implementa las
siguientes políticas de planificación: FIFO,
Backfilling [20] y CPUM-based. La política
basada en Backfilling se implementa a partir del
tiempo de ejecución límite especificado por el
usuario. La política CPUM-based utiliza la
información del NANOS-RM para determinar
cuando un nodo acepta la ejecución de nuevas
aplicaciones. La información del runtime y el
nivel de multiprogramación nos permiten
planificar la siguiente aplicación de la cola
siguiendo una política del tipo FIFO (según el
instante de envío del trabajo). Estamos trabajando
en la implementación de una política de
Backfilling basada en la predicción realizada por
un sistema de predicción externo.
XVI Jornadas de Paralelismo, JP '2005 381
Figura 2. Arquitectura general y coordinación entre NANOS-RM y eNANOS Scheduler
Para poder realizar una planificación
coordinada es muy importante la monitorización
de los trabajos y de los recursos. En el proyecto
eNANOS la idea es monitorizar los trabajos en
todos los niveles de planificación pero de
momento hemos implementado la monitorización
de los workloads en los dos niveles inferiores. El
eNANOS Scheduler proporciona información de
la monitorización de las aplicaciones que puede
ser utilizada por las políticas de planificación.
Esta información también puede ser muy útil para
el investigador ya que permite ver el
comportamiento del workload. De este modo se
puede disponer de información precisa para poder
ajustar las políticas de planificación. La
herramienta que se presenta en el apartado 6 es la
encargada de proporcionar esta información de
forma inteligible.
5. NANOS Resource Manager
El NANOS-RM es un gestor de procesadores
configurable cuya misión principal es recibir las
peticiones de las aplicaciones y distribuir los
procesadores entre ellos. Debido a las
características de los procesos/threads de AIX son
las propias aplicaciones las que fuerzan la
planificación decidida por el NANOS-RM.
El NANOS-RM también interactúa con el
eNANOS Scheduler, le indica el número máximo
de trabajos (o nivel de multiprogramación) que el
NANOS-RM admite para que el sistema funcione
sin tener sobrecarga. La idea es compartir la
información necesaria para mejorar el rendimiento
del sistema global sin penalizar el rendimiento de
las aplicaciones individualmente.
Las aplicaciones se instrumentan
dinámicamente para detectar comportamientos
ineficientes como por ejemplo desbalanceos de la
carga, speedups bajos, etc. El Performance
Monitor es el encargado de esta tarea y está
implementado como una librería que se carga
dinámicamente. Los objetos que gestiona el
NANOS-RM son: trabajos, tareas y CPU’s. En el
caso genérico, un trabajo es una aplicación
MPI+OpenMP. Cada uno de los procesos MPI se
considera una tarea e internamente puede pedir
procesos.
En la Figura 2 se muestra la estructura general
del NANOS-RM y la interacción con el eNANOS
Scheduler. El funcionamiento del NANOS-RM es
cíclico (asíncrono) y realiza las siguientes tareas
básicas:
x Planificación de procesadores
x Control de la carga del sistema
x Detección dinámica de aplicaciones multinivel
Dispone de tres threads principales: uno se
encarga de la interacción con el eNANOS
Scheduler, otro se coordina con las aplicaciones y
el último se encarga de realizar la planificación de
los procesadores. La inicialización y
configuración se realiza a través de la línea de
comando.
Las políticas de planificación son dinámicas y
tienen dos fases (multinivel). La primera fase es
entre aplicaciones, implementa una política FIFO:
1 aplicación tiene N procesos MPI y por lo tanto
382 Tecnologías Grid, Clusters y Plataformas Distribuidas
requiere de un mínimo de N procesadores. La
segunda fase es entre procesos de una misma
aplicación MPI+OpenMP e implementa dos
posibles políticas: Equipartición y Dynamic
Processor Balancing [4]. Esta última intenta
balancear la carga entre los procesos MPI de una
misma aplicación.
Para el análisis de rendimiento se detecta
automáticamente la estructura iterativa de las
aplicaciones para poder comparar. Internamente
se mide el tiempo dedicado a cálculo y a ejecutar
MPI. Se realizan medidas para evitar posibles
picos de desbalanceo y se descartan iteraciones
para evitar outliers. Más información sobre el
NANOS-RM y las técnicas de balanceo de la
carga puede encontrase en [4].
6. Soporte para análisis de workloads
El eNANOS Scheduler internamente se encarga
de monitorizar los trabajos y los recursos. El
planificador proporciona un fichero en formato
XML para cada trabajo que gestiona. En estos
ficheros XML describen la ejecución del trabajo y
siguen un esquema que incluye la siguiente
información (atributos más importantes):
x Identificador del trabajo a nivel local (StepID
asignado por LoadLeveler)
x Identificador del trabajo a nivel Grid (JobID
asignado por el eNANOS Broker)
x Nombre del workload
x Nombre del trabajo
x Topología de la aplicación (número de tareas
MPI y procesos OpenMP)
x Conjunto de eventos
Cada uno de los eventos de un trabajo incluye
el instante en el que se produce el evento
(timestamp), la identificación del evento, una
descripción y la información necesaria asociada al
evento. El conjunto de los eventos nos permite
determinar el ciclo de vida de los trabajos con una
precisión de segundos (escala de los timestamps).
Un conjunto de estos ficheros XML describen un
workload ya que uno de los atributos permite
identificarlo. Actualmente los workloads incluyen
la información correspondiente a los dos niveles
de planificación inferiores de la jerarquía
planteada. La jerarquía básica del esquema XML
planteado se muestra en la Figura 3, desde el nivel
Grid hasta el nivel thread.
Figura 3. Jerarquía básica del esquema XML
Para poder visualizar y analizar los workloads
hemos implementado una herramienta que a partir
de estos ficheros XML genera una traza que puede
ser visualizada con el software de visualización y
análisis Paraver. La herramienta lo primero que
hace es fusionar los ficheros XML
correspondientes a varios trabajos en un solo
fichero que contiene toda la información del
workload. A partir de la información de las tareas
y del conjunto de eventos generamos la traza.
Para las trazas utilizamos dos tipos de records
(líneas de las trazas de Paraver): records de estado
y records de evento. Los records de eventos
corresponden directamente a los eventos que se
describen en el fichero XML. Los records de
estado definen el estado de un trabajo en un
intervalo de tiempo determinado. Estos records se
determinan a partir de cada par de eventos y del
tipo de estos.
7. Evaluación
7.1. Arquitectura
La evaluación se ha realizado en un sistema IBM
con dos configuraciones: un IBM RS-6000 SP con
8 nodos de 16 Nighthawk Power3 @375Mhz (192
Gflops/s) con 64 Gb de RAM y un IBM p630 con
9 nodos de 4 p630 Power4 @1Ghz (144 Gflops/s)
con 18 Gb de RAM. Hay disponible un total de
446 Gflops y 1,8 TB de disco duro. Todos los
nodos están conectados mediante un SP Switch2
workload
Grid_job 1
Grid_job 2
Grid_job N
LL_job 1
LL_job 2
LL_job N
Appl i
Appl 1
Proc 1
Proc N
th N
th 1
XVI Jornadas de Paralelismo, JP '2005 383
funcionando a 500 MB/seg. El sistema operativo
es AIX 5.1 con el sistema de colas LoadLeveler.
7.2. Análisis numérico del workload
En este apartado presentamos el mecanismo de
análisis de workloads sin disponer de
herramientas de soporte. Para ello utilizaremos
dos workloads ejecutamos en un nodo de 16
CPU’s. Estos workloads están compuestos por
aplicaciones NAS [15] del tipo MZ y de la clase
A. Posteriormente se presentan las ventajas de
utilizar las herramientas de soporte para analizar
los workloads.
Workloads
0
200
400
600
800
1000
1200
1400
1600
w orkload 1 w orkload 2
Tiempo
Ejec.
(seg)
Figura 4. Tiempos de ejecución de los workloads
Los workloads utilizados están formados por 6
aplicaciones NAS, algunas de ellas BT y otras SP
de la clase A. El número de tareas MPI y threads
OpenMP no es el mismo para todas las
aplicaciones. En la Figura 4 se muestra el tiempo
de ejecución de los dos workloads con tres tipos
de configuraciones: LL, LL+RM(DPB) y
LL+SCH+RM(DPB). La primera corresponde a la
configuración por defecto del sistema en la cual se
aplica la política de backfilling a los trabajos
encolados. La segunda utiliza también política de
backfilling para planificar los trabajos pero las
aplicaciones son gestionadas por el NANOS-RM
aplicando la política de Dynamic Processor
Balancing (DPB) para balancear la carga. En el
último caso además de balancear las aplicaciones
con el NANOS-RM también se utiliza el
eNANOS Scheduler (en coordinación con el
NANOS-RM) para realizar la planificación.
En este caso la información que disponemos
es el tiempo de ejecución de los workloads
(Figura 4) y de las aplicaciones que componen los
workloads individualmente (Figura 5). Con esta
información analítica podemos apreciar ciertas
características de los workloads. Por ejemplo, en
el primer workload con la configuración de LL se
obtiene un tiempo de ejecución muy superior al
obtenido con las otras configuraciones (del orden
de seis veces más elevado). No podemos
determinar los motivos por los cuales el tiempo de
ejecución es tan elevado con esta configuración,
sólo podemos hacer ciertas hipótesis. En las otras
dos configuraciones, el tiempo de ejecución es
inferior y bastante similar entre ellas. Realizando
balanceo de la carga conseguimos una mejora
muy importante, pero de forma coordinada con el
planificador local todavía se consiguen mejores
resultados. De estos datos deducimos que el
balanceo de la carga ofrece mejoras y que el
planificador en coordinación todavía más, pero no
sabemos nada del comportamiento de los
workloads.
Workload 1
0:00:00
0:07:12
0:14:24
0:21:36
0:28:48
job 1 job 2 job 3 job 4 job 5 job 6
Tiempo
Ejec.
(seg)
Workload 2
0:00:00
0:00:43
0:01:26
0:02:10
0:02:53
0:03:36
0:04:19
0:05:02
0:05:46
job 1 job 2 job 3 job 4 job 5 job 6
Tiempo
Ejec.
(seg)
Figura 5. Tiempos de ejecución de las aplicaciones
En la Figura 5 podemos apreciar los tiempos de
ejecución de las aplicaciones que componen los
workloads de forma individual. Vemos como los
tiempos de respuesta de las aplicaciones son en
general mucho más reducidos utilizando los
planificadores coordinados. Así pues, en este caso
el planificador local también reduce el tiempo de
respuesta de las aplicaciones y permite aumentar
el throughput.
LL LL+RM(DPB) LL+SCH+RM(DPB)
LL LL+RM(DPB) LL+SCH+RM(DPB)
384 Tecnologías Grid, Clusters y Plataformas Distribuidas
Figura 6. Trazas de un workload, mediante AIX trace y
la herramienta presentada (XML)
7.3. Análisis y visualización con herramientas
Con el estudio anterior del workload hemos
podido apreciar cierta información mediante datos
cuantitativos. Con el uso de trazas podemos
analizar el comportamiento de las aplicaciones de
forma sencilla, rápida y eficaz. En la Figura 6 se
muestra el aspecto de las trazas, cada fila
corresponde a una aplicación en ejecución, el
color más claro corresponde al estado “running” y
el más oscuro al estado “idle”. La traza de más
arriba es directamente la obtenida mediante AIX
trace [10] y convertida al formato de Paraver. Más
abajo se muestran sólo los trabajos del workload
de la misma traza. La última es la obtenida a partir
de los ficheros XML de monitorización mediante
la herramienta que hemos desarrollado. Se puede
comprobar cómo las dos trazas tienen la misma
estructura, aunque puede haber alguna pequeña
diferencia por la escala.
En la Figura 7 se muestra una traza
correspondiente al detalle de la ejecución del
workload con la configuración LL. En este caso
las filas representan los threads que están en
ejecución en las CPU’s. Se puede apreciar como
los threads van cambiando de estado
constantemente en intervalos de tiempo muy
cortos. Esto es debido principalmente al uso
inadecuado de las CPU’s del nodo, llegando a
saturarlas y por lo tanto provocando una ejecución
ineficiente. En este caso se producen un número
muy elevado de cambios de contexto entre threads
que pelean para conseguir las CPU. Usando el
balanceo de la carga evitamos estas circunstancias
y además, con el planificador local evitamos
saturar tanto las CPU’s y mejorar el rendimiento.
Figura 7. Detalle de la ejecución de una aplicación
Teniendo en cuenta que con los dos sistemas
podemos obtener casi la misma información, el
principal motivo por el cual hemos optado por
este mecanismo es el reducido tamaño de las
trazas obtenidas. En la Figura 8 se muestra una
comparativa de tamaño entre los diferentes tipos
de trazas para workloads de diferentes duraciones
(traza binaria completa en formato Paraver, con
sólo los datos del workload y la traza obtenida a
partir de los ficheros XML). También hay que
tener en cuenta que el objetivo que perseguimos
es monitorizar los tres niveles de planificación
comentados anteriormente. Sería muy complicado
fusionar trazas de AIX trace de diversos nodos o
de diferentes sistemas. También hemos tenido en
cuenta otros factores, por ejemplo el hecho que
XML es un formato estándar, o la facilidad de
lectura, manejo y conversión a otros formatos.
binaria
paraver
paraver
filtrada
paraver
(XML)
10s 12 MB 8 MB 1,5 KB
1 min 150 MB 132 MB 40 KB
10 min 670 MB 640 MB 300 KB
Figura 8. Comparativa de tamaños de trazas
XVI Jornadas de Paralelismo, JP '2005 385
8. Conclusiones y trabajo futuro
En este artículo hemos presentado un mecanismo
que nos permite visualizar y analizar workloads,
mostrando el comportamiento de las aplicaciones
que lo componen. También hemos presentado los
resultados de la evaluación de workloads reales,
tanto analíticamente como mediante trazas. En la
evaluación de los workloads hemos comprobado
que la planificación coordinada entre eNANOS
Scheduler y NANOS-RM nos proporciona
mejoras tanto en el tiempo de ejecución del
workload como en el tiempo de respuesta de las
aplicaciones. Hemos visto como las trazas, que se
obtienen a partir de los ficheros XML que
describen los workloads, son un buen mecanismo
para analizarlos. En comparación con otros
posibles mecanismos, hemos visto que nuestra
propuesta tiene ventajas, sobre todo por el
reducido tamaño de las trazas y la posibilidad de
unificar la información de diversos niveles de
planificación en una única traza.
Planteamos dos líneas básicas de trabajo
futuro. Por un lado hay que añadir a la traza la
información de todos los niveles de planificación,
completando la coordinación entre niveles. Por el
otro lado, hay que mejorar el esquema XML de la
monitorización de los trabajos para soportar un
nivel de detalle superior en las trazas (información
relativa a CPU’s, threads, etc.).
9. Agradecimientos
Este trabajo está realizado con el soporte del
Ministerio de Ciencia y Tecnología, código
TIN2004-07739-C02-01, y del proyecto europeo
HPC-Europa con contrato 506079.
Referencias
[1] F. Berman, R. Wolski, et. al., “Application-
Level Scheduling on Distributed
Heterogeneous Networks”, Proceeding of
Supercomputing’96, 1996
[2] CEPBA Tools Web Site,
http://www.cepba.upc.es/tools.htm
[3] J. Corbalán, R.M. Badia, J. Labarta, “Enanos
Performance Tools for Autonomic Grid
Resource Allocation Management”, CEPBA-
IBM Research Institute, 2002
[4] J. Corbalán, A. Duran, J. Labarta, “Dynamic
Load Balancing of MPI+OpenMP
applications”, ICPP’04, 08-2004, Montreal,
Quebec, Canada
[5] EZ-Grid Resource Brokerage System,
http://www.cs.uh.edu/~ezgrid/
[6] J. Frey, T. Tannenbaum, M. Livny, I. Foster,
S. Tuecke, “Condor-G: A Computation
Management Agent for Multi-Institutional
Grids”. 10th HPDC, IEEE Press, Agosto 2001
[7] GridLab, A Grid Application Toolkit and
Testbed, http://www.gridlab.org
[8] GridWay Project Web Site,
http://www.gridway.org/
[9] Globus Information Services: Monitoring &
Discovery (MDS) Web Site,
http://www-unix.globus.org/toolkit/mds/
[10] IBM AIX trace facility Web Site,
http://publib.boulder.ibm.com/infocenter/pseri
es/index.jsp
[11] IBM Research, Autonomic Computing,
http://www.research.ibm.com/autonomic/
[12] MAUI Cluster Scheduler Web Site,
www.clusterresources.com/products/maui
[13] Mercury Grid Monitoring System Web Site,
http://www.lpds.sztaki.hu/mercury/
[14] K. Nadiminti, S. Venugopal, H. Gibbins, R.
Buyya, “The Gridbus Broker Manual (v.2.0)”,
GRIDS Laboratory,
http://www.gridbus.org/broker
[15] NASA Parallel Benchmarks Web Site,
http://www.nas.nasa.gov/
[16] Network Weather Service (NWS) Web Site,
http://nws.cs.ucsb.edu/
[17] OAR scheduler Web Site, http://oar.imag.fr/
[18] I. Rodero, J. Corbalán, R.M. Badia, J.
Labarta, “eNANOS Grid Resource Broker”,
P.M.A. Sloot et al. (Eds.): EGC 2005, LNCS
3470, Amsterdam, Junio 2005, pp. 111-121
[19] J. Skovira, W. Chan, H. Zhon, “The EASY –
LoadLeveler API Project ”, LNCS 1162,
1996, pp. 41-47
[20] A.M. Weil, D. Feitelson, “Utilization,
Predictability, Workloads and User Runtimes
Estimates in Scheduling the IBM SP with
Backfilling”, In IEEE Trans. On Parallel and
Distributed Syst. 12(6) pp.529-543, Jun 2001.
[21] R. Yahyapour, P. Wieder, “Grid Scheduling
Architecture-Requirements”, GGF GSA
Research Group, Enero 2005
386 Tecnologías Grid, Clusters y Plataformas Distribuidas
Asignación de réplicas en un Cluster Web basado en replicación
parcial de contenidos
José Daniel García, Jesús Carretero, Félix García,
José María Pérez y María Soledad Escolar
Grupo de Arquitectura de Computadores Comunicaciones y Sistemas
Universidad Carlos III de Madrid
Campus de Colmenarejo
28270 Colmenarejo, Madrid
josedaniel.garcia@uc3m.es
Resumen
En los últimos años han aparecido diversas
soluciones para la construcción de servidores
Web distribuidos. Normalmente estas solucio-
nes se basan en la replicación total de conte-
nidos o en la distribución total de contenidos.
Una tercera alternativa es la replicación par-
cial de contenidos. Esta alternativa exige resol-
ver el problema de la asignación de contenidos
a los nodos servidores. Este artículo presenta
un algoritmo para realizar dicha asignación.
Además se evalúa el efecto de esta estrategia
sobre el rendimiento global del sistema.
1. Introducción
El creciente desarrollo de las aplicaciones ba-
sadas en Web ha creado un enorme interés
en el diseño y la construcción de software y
hardware para este tipo de sistemas que per-
mita satisfacer las necesidades de rendimiento
de forma que las soluciones sean escalables en
cuanto al volumen de almacenamiento ofreci-
do y el rendimiento proporcionado. La forma
más tradicional de atacar el problema ha sido
el escalado hardware o software [5, 13, 12].
Otra alternativa es el uso de una arquitectu-
ra distribuida de servidor Web [8] en la que un
conjunto de nodos servidores alojan el servidor
Web. De esta forma la escalabilidad del rendi-
miento se alcanza incorporando nuevos nodos
al sistemas. En este tipo de sistemas debe re-
solverse el problema de distribuir la carga en-
tre los distintos nodos.
Las arquitecturas Web distribuidas pueden
clasificarse en tres grupos:
• Sistemas Web basados en cluster La
dirección IP de los nodos del cluster no
es visible para los clientes [14]. En lugar
de esto, los clientes utilizan una dirección
IP virtual que se corresponde con algún
dispositivo de distribución (switch Web)
situado entre los clientes y los nodos ser-
vidores.
• Clusters Web virtuales La dirección
IP de los nodos del cluster no es visible pa-
ra los clientes [16]. En su lugar, los clien-
tes utilizan una dirección IP virtual que
es compartida por todos los nodos servi-
dores.
• Sistemas Web distribuidos Cada nodo
dispone de una dirección IP distinta que
es pública y visible para todos los clientes
[4, 9]. No existe en este caso ningún dis-
positivo intermedio, por lo que cualquier
petición puede llegar a cualquier nodo.
Todas estas soluciones suelen basarse en la re-
plicación total de los contenidos (todos los ar-
chivos se encuentran replicados en todos los
nodos) o en la distribución total de los conte-
nidos (cada archivo se encuentra en un único
Figura 1: Arquitectura general de un sistema Web
basado en cluster
Figura 2: Arquitectura general de un cluster Web
virtual
Figura 3: Arquitectura general de sistema Web dis-
tribuido
nodo servidor). Entre la replicación total y la
distribución total, la replicación parcial apa-
rece como una tercera alternativa. En la repli-
cación parcial de contenidos, cada archivo se
aloja en un subconjunto del conjunto total de
nodos servidores.
Un problema que debe resolverse para poder
utilizar una arquitectura distribuida de servi-
dor Web basada en la replicación parcial, es
el de la asignación de réplicas a nodos servi-
dores. Dicho problema puede formularse de la
siguiente manera:
Dado un conjunto de N archivos y otro con-
junto de M servidores se debe seleccionar el
número de réplicas que deben realizarse de ca-
da archivo y se debe decidir en qué nodos se
alojan cada una de las réplicas de cada uno de
los archivos.
2. Presentación del problema
El problema de asignación de réplicas consiste
en asignar las distintas réplicas de cada ele-
mento a cada uno de los nodos servidores.
Un sitio Web está formado por un conjunto
388 Tecnologías Grid, Clusters y Plataformas Distribuidas
de elementos o recursos, donde cada uno de
ellos puede ser de un determinado tipo (pági-
na HTML, imagen, video, archivo de descar-
ga, música, etc). Se puede definir el conjunto
E como el conjunto de todos los elementos que
forman el sitio Web:
E = {e1, e2, . . . , eN }
donde cada elemento tiene asociado un tama-
ño ti.
Independientemente de la arquitectura utili-
zada, un servidor Web distribuido utiliza un
conjunto de nodos servidores para alojar y pro-
porcionar los contenidos de un sitio Web. Sea
S un conjunto de M nodos servidores:
S = {s1, s2, . . . , sM }
Cada nodo si tiene asociada una capacidad
de almacenamiento ci, que es el máximo vo-
lumen de almacenamiento que puede utilizar
para alojar contenidos.
La asignación de contenidos a nodos se puede
representar mediante la matriz de asignación
A
A = (aij)
aij = 1 ⇔ ei ∈ sj
aij = 0 ⇔ ei /
∈ sj
En general, el problema de la asignación con-
siste en encontrar los valores de una matriz
A que represente la asignación de elementos a
nodos. Como se verá en las próximas seccio-
nes, los valores de dicha matriz pueden estar
sujetos a distintas restricciones lo que dará lu-
gar a las soluciones que se proponen para dicho
problema.
3. Algoritmo de asignación
Una primera alternativa para la asignación de
réplicas, sería la selección de un mismo núme-
ro de réplicas para todos los archivos alojados
en el servidor. Esto sería apropiado si las pe-
ticiones de elementos se distribuyesen de for-
ma uniforme para todos los elementos de un
sitio Web. No obstante esto no suele ser así.
En un sitio Web, unos elementos son más po-
pulares que otros, de forma que las peticiones
recibidas sobre dichos elementos serán superio-
res en número. En estos casos, puede ser más
conveniente disponer de un mayor número de
réplicas para los elementos más populares, y
disponer de un menor número de réplicas para
los elementos menos populares. El problema
consiste en encontrar los valores ri y la matriz
de asignación A, de forma que el número de
réplicas de cada elemento ei sea ri y que no se
rebase la capacidad de almacenamiento cj de
ningún nodo. Es decir
M

j=1
aij = ri ∀i ∈ [1, N]
N

i=1
aijti ≤ cj ∀j ∈ [1, M]
por lo que
M

j=1
N

i=1
aijti ≤
M

j=1
cj
Por otra parte
M

j=1
N

i=1
aijti =
N

i=1
ti
M

j=1
aij =
N

i=1
tiri
y por tanto debe la restricción que debe man-
tenerse es la que se muestra a continuación
N

i=1
tiri ≤
M

j=1
ci
Si se conoce la probabilidad de que se realice
una petición sobre un elemento, se puede rea-
lizar una asignación de réplicas que asigne un
mayor número de réplicas para los elementos
más populares y un menor número de répli-
cas para los elementos menos populares. Sea
pi la probabilidad de que una petición haga
referencia al elemento ei. Se puede reordenar
los elementos de tal forma que
pi ≥ pi+1
Se puede realizar un reparto del espacio pro-
porcional a la probabilidad y que tenga en
XVI Jornadas de Paralelismo, JP '2005 389
cuenta las restricciones del problema. La idea
pasa por asignar inicialmente a cada elemen-
to una cuota de participación en el almacena-
miento global proporcional a su probabilidad
asociada. De esta forma, los elementos más
populares tendrán más espacio disponible que
los elementos menos populares. Por tanto, el
número de réplicas inicial para cada elemento
vendrá dado por
ri =
pi
M
j=1
cj
ti
No obstante, el número de réplicas de un ele-
mento no puede ser menor que 1 ni mayor que
M, por lo que es necesario realizar ajustes del
número de réplicas. Por tanto, se puede definir
r∗
i tal de la siguiente manera:
r∗
i = 1 ⇔ ri < 1
r∗
i = M ⇔ ri > M
r∗
i = ri ⇔ 1 ≤ ri ≤ M
Una vez realizado el ajuste de los número de
réplicas de cada elemento se puede utilizar un
algoritmo voraz de asignación de réplicas que
en el caso de llegar una solución que viole las
restricciones de almacenamiento realice la re-
ducción del número réplicas de algún elemen-
to. La idea de la reducción del número de ré-
plicas se basa en la determinación del valor αi
αi =
r∗
i
ri
Para aquellos elementos para los que ri fuese
menor que 1, r∗
i es exactamente 1 y por tanto
αi =
1
ri
> 1
Para el resto de elementos, αi expresa la pro-
ximidad entre los valores ri y r∗
i . Un valor de
αi muy próximo a 1 indica que dicho elemen-
to tiene asignados un número de réplicas muy
próximo al que le correspondería por su proba-
bilidad pi. Por tanto, el mejor candidato para
reducir réplicas, será aquel cuyo valor αi sea
más próximo a 1 sin sobrepasarlo.
∀i ∈ [1, N] determinar r∗
i
Ordenar los elementos ei tal que ti > ti+1
A ← 0
Mientras A = 0
li ← ci∀i
Para todo ei ∈ E
Generar la lista o de índices
de servidores por orden
decreciente de espacio lj
si ∃j ∈ o|ti > lj
Determinar αi
Elegir k| no ∃q : αq ≤ 1 ∧ αq > αk
A ← 0
Reiniciar bucle externo
Fin si
aij ← 1∀j = o1, . . . , or∗
i
lj ← lj − ti∀j = o1, . . . , or∗
i
Fin
Fin
Algoritmo 1: Asignación de réplicas no equitativa
Un aspecto importante a tener en cuenta es la
selección de las probabilidades pi asociadas a
cada uno de los elementos ei. Cuando la asig-
nación de réplicas es estática, no se tiene in-
formación sobre la probabilidad que tiene cada
elementos de ser solicitado. De hecho la única
información que se tiene sobre los elementos
del sitio Web es la relativa a su estructura y
a los tamaños de los elementos. No obstante,
a partir del tamaño de cada elemento se pue-
de realizar una estimación de la probabilidad
de petición. Diversos estudios empíricos [6, 1]
demuestran que si se ordenan los elementos en
orden de popularidad decreciente, la probabi-
lidad de acceso al i-esimo elemento sigue la
distribución propuesta por George Zipf [17].
p (i) =
k
i
Por la definición de probabilidad, debe verifi-
carse que
N

i=1
p (i) = 1
y por tanto
N

i=1
k
i
= k
N

i=1
1
i
= 1
390 Tecnologías Grid, Clusters y Plataformas Distribuidas
y el valor de k debe ser
k =
1
N

i=1
1
i
No obstante, no se tiene ningún conocimiento
a priori sobre la popularidad de las páginas.
Otros estudios [7, 2] demuestran que la popu-
laridad de un elemento es mayor cuanto menor
es su tamaño.
Ordenar los elementos ei por
tamaño creciente
k ← 1/
N
i=1
1
i
Para i ∈ [1, N]
pi ← k/i
Fin
Algoritmo 2: Asignación de probabilidades Zipf
4. Evaluación
Para evaluar el efecto de la utilización de
una política de replicación parcial se ha cons-
truido un modelo de simulación utilizando la
herramienta Omnet++. El caso evaluado rea-
liza una simulación en la que 800 clientes rea-
lizan peticiones a un sistema Web basado en
cluster de 16 nodos servidores. Se han reali-
zado 50 realizaciones de cada experimento de
simulación cambiando la semilla de los gene-
radores de distribuciones aleatorias.
En todos los casos se han comparado dis-
tintas alternativas para la distribución de los
contenidos:
RTOT Sistema totalmente replicado.
RPCI Replicación utilizando un número fijo
de réplicas y comenzando la replicación
cada vez por el nodo siguiente al primero
de la vez anterior.
RPCF Replicación utilizando un número fijo
de réplicas y comenzando la replicación
cada vez por el nodo siguiente al último
de la vez anterior.
Figura 4: Tiempo de respuesta para asignación es-
tática circular en un sistema Web basado en cluster
de 16 nodos
RNOEQ Replicación no equitativa basada
en probabilidades de acceso utilizando la
función de Zipf.
Como política de asignación de peticiones a
nodos se han utilizado variantes de las políti-
cas de asignación estática circular [10], asig-
nación al nodo menos cargado [15] y asigna-
ción dependiente de la localidad de referencias
LARD [3, 11].
En el caso de la política de asignación es-
tática circular se puede observar que, cuando
se utiliza una estrategia con un número fijo
de réplicas por elemento, se puede mejorar el
tiempo de respuesta aumentando el número de
réplicas de 2 a 4. Esto es posible, al permitir-
se la distribución de peticiones dirigidas a un
mismo elemento entre más nodos. La distri-
bución no equitativa presenta peor comporta-
miento debido a que se generan un alto número
de fallos en las cachés de los nodos servidores.
En general, la asignación cíclica inicial ofrece
el mejor tiempo de respuesta en este caso.
En el caso de la política de asignación al
nodo menos cargado, la estrategia no equitati-
va ofrece mejor tiempo de respuesta que la so-
lución totalmente replicada. Lo mismo ocurre
en el caso de la política de asignación LARD
5. Conclusión
La replicación parcial de contenidos es una
alternativa híbrida entre la replicación total
XVI Jornadas de Paralelismo, JP '2005 391
Figura 5: Tiempo de respuesta para asignación al
nodo menos cargado en un sistema Web basado en
cluster de 16 nodos
Figura 6: Tiempo de respuesta para asignación
LARD en un sistema Web basado en cluster de
16 nodos
de contenidos y la distribución total de con-
tenidos. Por una parte, un sistema totalmen-
te replicado ofrece una alta fiabilidad a costa
de consumir mucho espacio de almacenamien-
to y presentar problemas de escalabilidad en
cuanto al tamaño del sitio Web alojado. Por
otra parte, un sistema totalmente distribuido,
ofrece una fiabilidad mucho menor aunque el
volumen de almacenamiento disponible es mu-
cho mayor. La replicación parcial de conteni-
dos pretende ofrecer un equilibrio entre volu-
men de almacenamiento y fiabilidad.
En este artículo se ha presentado un algorit-
mo de asignación de réplicas basado en repli-
cación parcial y que utiliza las probabilidades
de acceso como criterio para realizar la asig-
nación de número de réplicas. Una ventaja de
este algoritmo es que se adapta bastante bien
a su utilización cuando el espacio de almace-
namiento de cada nodo es distinto.
Las evaluaciones realizadas muestran que el
uso de una estrategia de replicación parcial no
genera pérdidas en el rendimiento de un servi-
dor Web distribuido.
Actualmente estamos realizando trabajos
para determinar de forma analítica la fiabili-
dad y el volumen de almacenamiento de una
estrategia de replicación parcial para las dis-
tintas arquitecturas Web distribuidas existen-
tes.
Referencias
[1] Almeida, V., Bestavros, A., Crovella, M.
and Oliveira, A. Characterizing reference
locality in the WWW Proceedings of the
19996 International Conference on Parallel
and Distributed Information Systems, 92–
103, Diciembre, 1996.
[2] Arlitt, M.F. y Williamson, C.L. Internet
Web servers: Workload characterization
and performance implications IEEE/ACM
Transactions on Networking, 5(4):631–645,
Octubre 1997.
[3] Aron, M., Sandrs, D. Druschel, P. y Zwae-
nepoel, W. Scalable content-aware request
distribution in cluster-based network ser-
vers. Proceedings of the 2000 USENIX An-
392 Tecnologías Grid, Clusters y Plataformas Distribuidas
nual Technical Conference. 232–236, San
Diego, CA, USA. Junio 2000.
[4] Aversa, L. y Bestavros, A. Load abalan-
cing a cluster of Web servers: using dis-
tributed packet rewriting. Conference Pro-
ceedings of the 2000 IEEE International
Performance, Computing and Communica-
tions (IPCCC 2000). 24–29. Phoenix, AX,
USA, Febrero 2000.
[5] Banga, G., Druschel, P. y Mogul, J.C.
Resource containers: A new faicility for
reosurce management in server systems
Operating Systems Review, Special Issue
1998:45–58. 1999.
[6] Barford, P. y Crovella, P. Generating re-
presentative Web workloads for network
and server performance evaluation Perfor-
mance Evaluation Review, 26(1):151–160,
Junio 1998.
[7] Breslau, L., Cao, P., Fan, L., Phillips,
G. y Shenker, S. Web caching and Zipf-
like distributions: Evidence and implica-
tions Eighteenth Annual Joint Conference
of the IEEE Computer and Communica-
tions Societies (INFOCOMM’99) 126–134,
1999.
[8] Cardellini, V., Cassalicchio, E., Colajanni,
M., y Yu, P.S., The state of the art in loca-
lly distributed Web-Server systems, ACM
Computing Surveys, 34(2): 263–311, Junio
2002.
[9] Cardellini, V. Request redirection algo-
rithms for distributed Web systems IEEE
TRansactions on Parallel and Distributed
Systems, 14(4):355–368, Abril 2003.
[10] Linux Virtual Server Virtual server
scheduling algorithms, Mayo, 2001.
http://www.linuxvirtualserver.org.
[11] Pai, V.S., Aron, M., Banga, G. Svend-
sen, M., Druschel, P., Zwaenepoel, W.
y Nahum, E. Locality-aware request dis-
tribution in cluster-based network servers
ACM SIGPLAN Notices, 33(11):205–216,
Noviembre 1998.
[12] Pai, V.S., Druschel, P. y Zwaenepoel,
W. Flash: An efficient and portable Web
server, Proceedings of the USENIX 1999
Annual Techcnical Conference, 199–212.
Monterey, CA, USA, Junio 1999.
[13] Pai, V.S., Druschel, P. y Zwaenepoel, W.
IO-Lite: A unified I/O buffering and ca-
ching system ACM TRansactions on Com-
puter Systems. 18(1):37–66, Febrero 2000.
[14] Schroeder, T., Goddard, S. and Rama-
murthy,B. Scalable web server clustering
technologies IEEE Network. 14(3):38–45,
Mayo 2000.
[15] Teo, Y.M. y Ayani,R. Comparison of
load balancing strategies on cluster based
Web servers Simulation 77(5–6):185–195,
Noviembre 2001.
[16] Vaidya, S. y Christensen, K.J. A single
system image server cluster using duplica-
ted MAC and IP addresses Proceedings of
the 26th Annual IEEE Conference on Lo-
cal Computer Networks (LCN 2001), 206–
214. Tampa, FL, USA, Noviembre 2001.
[17] Zipf, G.K. Human behavior and the
Principle of Least Effort. Addison-Wesley,
1949.
XVI Jornadas de Paralelismo, JP '2005 393
Evaluación de un cluster OpenMosix para entornos de alta
productividad y de alto rendimiento
David Hernández Sanz, Rafael Menéndez de Llano Rozas, Pablo Abad Fidalgo
Grupo de Arquitectura y Tecnología de Computadores
ETSII y de Telecomunicación
Universidad de Cantabria
39005 Santander
rafa@atc.unican.es
Resumen
En este trabajo se ha llevado a cabo un estudio
exhaustivo del sistema operativo distribuido
OpenMosix, para lo cual se ha instalado un cluster
GNU/Linux con imagen única y replicación de
nodos a través de system imager [14] con un
golden client. Esto ha sido conveniente ya que la
instalación se ha realizado con y sin el kernel de
OpenMosix. Posteriormente se ha realizado una
serie de pruebas para comparar su rendimiento
frente a clusters tradicionales basados en librerías
estándar como MPI. Se ha concluido que gracias
al algoritmo implementado en la migración de
procesos que es usado para el balanceo de carga
apenas se pierde rendimiento frente al cluster
tradicional y en situaciones de carga elevada
incluso se mejoran sus resultados.
1. Introducción
El mundo de la computación ha cambiado mucho
desde sus comienzos, el aumento de la capacidad
de integración y la reducción del coste asociado a
la tecnología han permitido que podamos contar
con capacidades de cómputo inimaginables hace
tan solo una década. Es previsible que la
integración llegue a un techo tecnológico a partir
del cual serán necesarios nuevos paradigmas para
poder seguir aumentando esta capacidad. Uno de
esos paradigmas es el procesamiento paralelo,
entendiendo como tal la capacidad de utilizar
varios procesadores para ejecutar partes
diferenciadas de un mismo programa
simultáneamente.
Los llamados computadores paralelos han
presentado un precio muy elevado desde sus
comienzos debido a la complejidad de su
desarrollo y sobretodo al llamado coste de
escalabilidad, el cual incrementa casi
exponencialmente el coste de la máquina frente a
su capacidad de cómputo. La aparición en la
década de los 60 de las primeras redes de
computadores civiles hizo posible un nuevo
planteamiento para aprovechar ciclos de CPU de
otras máquinas conectadas a la red, dando origen a
los sistemas multicomputadores denominados
clusters. Dentro de éstos existe un grupo
denominado NOW (Network Of Workstations),
cuyas máquinas están construidas a partir de
computadores personales con tecnologías estándar
(commodity) y facilitan soluciones realmente
eficientes tanto en coste como en rendimiento. El
problema que surge al crear un cluster de este tipo
es cómo gestionar los recursos disponibles, esta
gestión debe realizarse mediante software y es una
parte crítica del sistema. OpenMosix [13] es una
nueva concepción que ha surgido de las ideas
relacionadas con los sistemas operativos
distribuidos y que deja al kernel ciertas decisiones
relacionadas con el paralelismo, lo que permite
incrementar el grado de acoplamiento entre las
máquinas del cluster hasta el punto de abstraer del
mismo al usuario final que lo ve como si fuera una
gran máquina SMP. OpenMosix es un sistema
operativo en pleno desarrollo y que ha recorrido
un gran camino en el mundo de los sistemas
operativos distribuidos, permitiendo crear
máquinas paralelas de una forma simple y eficaz
[11][4].
Para demostrar esto, hemos realizado una
serie de pruebas cuyo objetivo ha sido analizar el
comportamiento de OpenMosix frente a las
arquitecturas de clustering más tradicionales. El
resto del trabajo se ha organizado de la siguiente
manera: en el segundo apartado estudiaremos
OpenMosix y sus particularidades como sistema
operativo distribuido, definiendo las líneas básicas
de su diseño y los algoritmos que subyacen bajo
ellas. En el tercer apartado detallaremos el cluster
utilizado en las pruebas (construido con nodos
desechados en el grupo de investigación) así como
los servicios principales que implementa. En el
cuarto apartado expondremos las pruebas
realizadas así como los resultados obtenidos
explicando el porqué de los mismos. Por último
propondremos las conclusiones que consideramos
relevantes tras el estudio realizado.
2. OpenMosix
OpenMosix es una extensión/modificación del
kernel de GNU/Linux que permite un reparto
eficiente de todos los recursos del cluster entre
todos los usuarios. Lo que caracteriza a este
sistema es que es el propio cluster quien decide
dónde se ejecuta un trabajo mediante algoritmos
de balanceo de carga entre nodos (esto es lo que
se conoce como el paradigma del FORK and
FORGET [4][10]) que permiten una respuesta
eficiente en condiciones de alta impredecibilidad
debidas a la existencia de múltiples usuarios,
procesos y/o situaciones.
El kernel de OpenMosix modifica el kernel
GNU/Linux en un 3% aproximadamente y
presenta las siguientes partes [5]:
a) Un kernel inferior, íntimamente ligado al
procesador local y al hardware que lo
rodea, que contiene las rutinas específicas
de la máquina para acceder a los recursos
hardware de la misma. No tiene
conocimiento alguno sobre el resto de
nodos del cluster ni sobre si las peticiones
que recibe provienen del nodo local o de
un nodo remoto.
b) Un kernel superior, independiente de la
máquina, que provee a OpenMosix del
interfaz estándar de llamadas al sistema
GNU/Linux hacia el nivel de aplicaciones.
No conoce al procesador en el que se
ejecuta pero sí la localización de los
procesos y sus contextos.
c) Un enlazador (Mosix-Link) que permite la
comunicación entre los anteriores,
proporcionando una interfaz clara y eficaz
entre ambos.
Los algoritmos de OpenMosix se han
diseñado para responder a variaciones en tiempo
real del uso de los recursos de los nodos, esto se
hace posible migrando procesos de un nodo a otro
de forma transparente con el objetivo de balancear
la carga y evitar en lo posible el fenómeno de la
paginación. El éxito radica en una mejora del
rendimiento total y la creación de un entorno
multiusuario y de tiempo compartido para la
ejecución de aplicaciones, tanto secuenciales
como paralelas. Para la implementación de este
comportamiento la tecnología OpenMosix consta
de cinco partes fundamentales que implementarán
las tareas descritas y que se detallas a
continuación. [9]
2.1. Migración Transparente De Procesos
Consiste en la capacidad de migrar un proceso a
otro nodo de una forma completamente
transparente al usuario, al nodo y al proceso. Tras
su migración el proceso continúa interaccionando
con el entorno de su localización como si no
hubiera migrado. Para implementar la migración
los procesos se dividen en dos áreas [4][5]:
REMOTE: es el área de usuario y puede ser
migrada. Contiene el código del programa, el
stack, los datos, los mapas de memoria y los
registros de los procesos. DEPUTY: es el área de
sistema y no puede migrar puesto que es
dependiente del nodo raíz UHN (Unique Home
Node). Contiene una descripción de los recursos a
los que el proceso está ligado y un kernel-stack
para la ejecución del código de sistema del
proceso. La interface entre las dos áreas está bien
definida en la capa de enlace, con un canal de
comunicación especial para la interacción de tipo
openmosix_link.
Figura 1. Un proceso local y uno migrado.
396 Tecnologías Grid, Clusters y Plataformas Distribuidas
Esta técnica posee algunas limitaciones, que
pueden provocar que ciertos procesos no puedan
migrar o que se produzca un uso ineficiente de la
red, debido a las llamadas a sistema o los accesos
a disco remotos. Este último inconveniente se ha
intentado solucionar con técnicas como DFSA
(acceso directo a ficheros) o la utilización de una
cache especial que guarda todos los datos de una
llamada para enviarlos de una sola vez [9].
2.2. Balanceo De Carga
Determinar la localización óptima para un trabajo
en un cluster es un problema complejo, dado que
los recursos disponibles son en muchos casos
heterogéneos (memoria, CPU, necesidades de
comunicación, I/O, etc.) y no se pueden comparar
directamente, ya que no se miden con las mismas
unidades [4]. La mejor aportación de OpenMosix
es un algoritmo para seleccionar en qué nodo debe
ejecutarse un proceso ya iniciado. El modelo
matemático para este algoritmo se basa en el
análisis de coste de oportunidad (coste marginal)
en economías de mercado [3][6]. La idea clave
consiste en convertir el uso total de un
determinado conjunto de recursos en un solo coste
homogéneo, los trabajos se asignarán entonces a
la máquina en la que tengan el menor coste (como
en una economía de mercado tradicional),
permitiendo el reparto eficiente de los recursos de
toda la máquina paralela. Esta estrategia
económica permite unificar la localización de
computación, memoria, recursos de E/S y
comunicación llegando a soluciones cercanas a la
óptima a la hora de organizar dichos recursos.
Podemos encontrar algoritmos de balanceo
para la CPU y la memoria, así como para procesos
que hagan un uso constante de recursos de E/S,
bien sean de red o de disco duro. Existe otro grupo
de trabajos cuyo comportamiento es de tipo IPC
(Inter Process Comunication) por ejemplo trabajos
paralelos de tipo MPI [6]. Aunque es posible
definir un algoritmo de balanceo teórico para este
tipo de trabajos, no se ha podido implementar en
la práctica puesto que OpenMosix aún no dispone
de migración de sockets [4].
2.3. Memory Ushering
Este algoritmo permite a un nodo que ha agotado
su memoria principal, utilizar la memoria libre
que pueda existir en el resto de nodos, migrando
procesos hacia estos en vez de realizar paginación.
El objetivo final de la combinación de los
algoritmos de balanceo de carga y de “memory
ushering” es ejecutar el mayor número de
procesos en la memoria principal de los nodos,
evitando en lo posible la paginación que hace que
el rendimiento de los nodos caiga enormemente.
El algoritmo se activará cuando la memoria de
un nodo caiga por debajo de un cierto umbral de
memoria libre. En ese caso, el algoritmo se
impone sobre el de balanceo de carga e intenta
migrar procesos a otros nodos que tengan la
suficiente memoria libre. Este mecanismo actúa
de forma independiente del de equilibrado de
carga, dado que puede ocurrir que debido a su
actuación el cluster no presente un balanceo
óptimo de procesos, pero se asegura que no
existirá paginación mientras quede suficiente
memoria agregada para todos los procesos en
ejecución [7].
2.4. Omfs Y DFSA
Uno de los mayores problemas de los clusters con
imagen única es que cada nodo tiene que ser capaz
de ver el mismo sistema de ficheros que cualquier
otro nodo. Con este objetivo surgió el sistema de
archivos oMFS (open Mosix File System)
tratándose de una abstracción a nivel de cluster de
los sistemas de archivos de los nodos. Basado en
NFS, oMFS proporciona coherencia de Cache y
consistencia al nombrar los archivos de una forma
única para distinguirlos de los archivos de otros
nodos. Esto se consigue nombrándolos a partir de
un mismo directorio raíz (/mfs/nodo/…) [8].
Una carencia del sistema de archivos oMFS es
que un proceso migrado no podía acceder al
sistema de archivos del nodo en el que estaba
ejecutándose sin comunicarse a través de UHN, lo
que suponía una gran ineficiencia en el uso de la
red. Buscando entre las mejores investigaciones
de los modernos sistemas de ficheros y aplicando
nuevas ideas a OpenMosix surgió DFSA (Direct
File System Access). El DFSA fue diseñado para
reducir el exceso de carga de la ejecución de
llamadas al sistema orientadas a E/S de los
XVI Jornadas de Paralelismo, JP '2005 397
procesos migrados. Su gran ventaja radica en que
es posible migrar el proceso que realice la
entrada/salida al nodo donde tenga que hacerla
[1]. Esto se consiguió permitiendo la ejecución de
la mayoría de llamadas a sistema de forma local.
Conjuntamente a DFSA se generó un nuevo
algoritmo que hace un recuento de las operaciones
de E/S. Este algoritmo permitirá que un proceso
que requiera un número medio/alto de operaciones
de E/S migre al nodo donde realizará la mayoría
de estas operaciones. Una ventaja obvia es que al
migrar estos procesos se va a mejorar el
equilibrado de carga puesto que no deben
transmitirse las llamadas al sistema de archivos a
través de la red obligando al deputy a gestionarlas
y saturando la misma. A diferencia de NFS, que
sirve los datos desde el servidor hacia los nodos,
OpenMosix intentará migrar el proceso al nodo en
el que el fichero resida en aquel momento [2].
2.5. Algoritmo de Diseminación de Información
El algoritmo de diseminación de información es el
responsable del intercambio de la información
sobre la carga y el uso de la memoria entre los
procesadores del cluster (hablamos de
procesadores dado que puede haber nodos con
más de un procesador - SMP). Estos algoritmos
están descentralizados con lo cual no existe un
procesador que tenga un conocimiento global y
actual de todos los procesadores en un momento
dado. De hecho, cada nodo envía su información a
un número de procesadores aleatorio y, al mismo
tiempo, mantiene una ventana con información
reciente obtenida de un conjunto limitado de ellos,
de tal manera que en un tiempo corto se haya
recibido información de todo el sistema. El
algoritmo es probabilístico dado que basa la
elección de los nodos que van a ser informados en
un subconjunto aleatorio de todo el conjunto de
los nodos del cluster. Otra característica de este
algoritmo es que soporta configuración dinámica
en el sentido de que los nodos pueden añadirse y
eliminarse sin que afecte al resto de nodos que
sencillamente los darán como “inactivos” si no
reciben información actualizada referente a ellos
en un cierto tiempo. Este tiempo debe ser lo
suficientemente grande como para descartar la
probabilidad de que estén activos pero no
hayamos recibido datos sobre ellos [5].
3. Entorno De Pruebas
El cluster diseñado se compone de cinco máquinas
(todas obsoletas y desechadas por el grupo de
investigación). Los nodos de cómputo son cuatro
Pentium II trabajando a 266GHz con 128/160MB
de memoria RAM y discos de 8GB, más que
suficientes para nuestros propósitos. Por otro lado
está el frontend que consiste en un Pentium IV a
1.5GHz con 512MB de memoria RAM y un disco
duro de 40GB que nos va a permitir guardar la
imagen de uno de los nodos y replicarla
posteriormente. Se han instalado los nodos
mediante la replicación de la imagen de uno de
ellos (golden client) gracias a System Immager
[14]. Todos ellos están unidos mediante una red
Ethernet conmutada a 100Mbps. El esquema del
cluster con los servicios implementados se
muestra en la figura 2.
INET
Figura 2. Arquitectura del cluster OpenMosix y
servicios software implementados.
El frontend alberga un servidor DHCP que se
encarga de configurar los nodos y de instalar las
imágenes si así se indica en el arranque por PXE,
enviándolas mediante RSYNC. Además de esto,
se ha instalado un sistema de colas basado en
OpenPBS que se va a encargar de lanzar los
trabajos a los nodos. El frontend pertenece al
cluster pero va a ser un mero observador del
sistema gracias a las herramientas de área de
usuario que nos proporciona OpenMosix (mosmon
y openMosixView). Los nodos tienen instalada una
configuración mínima sin entorno gráfico dado
que sólo se van a utilizar para cómputo y no para
dar acceso a usuarios [10][11].
398 Tecnologías Grid, Clusters y Plataformas Distribuidas
4. Evaluación De Rendimiento
Lo que nos proponemos con las pruebas que
vienen a continuación es estudiar el
comportamiento de OpenMosix en un entorno de
alta computación HC (High Computing) tanto
para maximizar el número de trabajos (modo
throughput) realizados por unidad de tiempo
(HTC) como para minimizar el tiempo de
ejecución (modo performance) de un trabajo
(HPC) y comparar su rendimiento con el de
sistemas tradicionales (cluster usando MPI y
sistemas de colas) [12]. Para ello proponemos dos
bancos de pruebas, uno simple consistente en la
ejecución de un subconjunto del NPB 2.4 (NAS
Parallel Benchmark [15]) y otro, que
denominaremos banco de pruebas compuestas, en
el que vamos a ejecutar las pruebas anteriores
pero introduciendo en los nodos procesos
secuenciales que buscan producir desequilibrios
en la ejecución de los trabajos paralelos. Veremos
cómo reacciona OpenMosix en comparación al
cluster HPC sin balanceo de carga.
4.1. Pruebas Simples
Trataremos en este apartado de evaluar las
diferencias que existen entre ejecutar trabajos
paralelos utilizando un cluster tradicional (sin
balanceo de carga) y utilizando un cluster
OpenMosix. Las tres pruebas del conjunto de las
NAS 2.4 que se han escogido han sido las EP, BT
y LU, dado que presentan grados de utilización de
los recursos distintos y patrones de comunicación
bien diferenciados, lo que nos permitirá obtener
resultados significativos.
120
125
130
135
140
EP 04 EP 08 EP 16 EP 32 EP 64 EP 128
Número de Procesos
Tiempo
de
Ejecución
(segundos)
Con OpenMosix
Sin OpenMosix
Figura 3. Pruebas simples EP.
Dado que el grado de granularidad en
OpenMosix es el proceso, y que en nuestro
sistema tenemos sólo cuatro nodos de cómputo, en
muchos casos vamos a lanzar pruebas con un
número de procesos mayor que el número de
procesadores. Sabemos que esto no mejora la
eficiencia de la ejecución (de hecho a partir de
cuatro la empeorará), pero obviamente sí aumenta
el número de procesos que se van a ejecutar por
nodo, lo cual nos acerca a una situación más real.
0
200
400
600
800
1000
1200
1400
1600
1800
LU 04 LU 08 LU 16 LU 32 LU 64 LU 128
Número de procesos
Tiempo
de
Ejecución
(segundos)
Con OpenMosix
Sin OpenMosix
Figura 4. Pruebas simples LU.
0
500
1000
1500
2000
2500
BT 04 BT 09 BT 16 BT 25 BT 36
Número de Procesos
Tiempo
de
Ejecución
(segundos)
Con OpenMosix
Sin OpenMosix
Figura 5. Pruebas simples BT.
Los resultados para las pruebas seleccionadas
(en concreto para el tipo A que es el que se adecúa
más a nuestro sistema) se muestran en las figuras
3, 4 y 5. En los casos de las pruebas EP y LU
podemos observar como OpenMosix se acerca
mucho al cluster HPC tradicional, las diferencias
de tiempos son escasas, y se pueden achacar a que
en OpenMosix tenemos en ejecución servicios
adicionales como oMFS, el balanceo de carga y la
diseminación de información así como el
incremento de tiempo debido a las migraciones.
En la figura 5 observamos algunos puntos en
los que las diferencias de tiempos son apreciables
(nueve procesos en cuatro procesadores), en estos
casos la degradación adicional (ya que el
XVI Jornadas de Paralelismo, JP '2005 399
desbalanceo de carga es directo) de rendimiento
que produce OpenMosix es debida al tipo de
patrón de comunicación de las NAS BT (continuo
y voluminosos en el tiempo) y a que hay un
intento de migrar los procesos que al llegar al
nodo destino se ven sin datos suficientes para
continuar. El tiempo que se gasta en estas
migraciones es elevado puesto que las pruebas BT
ocupan bastante memoria respecto de las otras
pruebas.
4.2. Pruebas Compuestas
En este caso vamos lanzar las pruebas de la misma
forma que se hizo en el apartado anterior pero
pondremos en los nodos uno y dos procesos
secuenciales interferentes con un uso de CPU
masivo, repitiendo las pruebas para cada caso. La
idea es que a la ejecución de las NAS se añada la
ejecución de ese proceso o procesos secuenciales.
Esto significa que en los nodos en los que exista
un proceso interferente y llegue un proceso de una
NAS determinada, el procesador va a dividir su
tiempo de ejecución equitativamente entre ambos,
de modo que cada uno tendrá la mitad del mismo.
Si el número de procesos de la NAS que
añadamos al nodo es mayor que uno, entonces se
dividirá la CPU proporcionalmente entre todos los
existentes, incluido el interferente.
Es obvio que estas pruebas van a incrementar
enormemente el tiempo de ejecución de las NAS
puesto que vamos a desequilibrar la carga de las
mismas. Esto supondrá que unos procesos
terminen antes que otros con lo cual se quedarán a
la espera de los datos que vengan de los que aún
no han terminado. Pretendemos estudiar cómo
reacciona OpenMosix ante dichas situaciones.
Comenzaremos lanzando las pruebas EP dado
que se comportan prácticamente como procesos
de CPU aislados excepto al final, momento en que
comunican su información. Los resultados de la
ejecución se muestran en la figura 6. Se ha
parametrizado el sistema con un decaimiento de
estadísticas medio (unos 200 segundos). En
OpenMosix se llama decaimiento al tiempo
máximo en que se guardan y analizan los datos de
comportamiento generados por un proceso a lo
largo de su ejecución [10]. En ella observamos
que tanto con OpenMosix como sin él el tiempo
de ejecución va decreciendo con el tiempo (a
pesar de que en cuántos más procesos dividamos
el problema, más ineficiente es la resolución para
un mismo número de procesadores) hasta hacerse
más o menos constante en un valor entorno a 133
segundos, cercano al caso ideal. Esto es lógico
pues, como hemos dicho, las NAS van a competir
en igualdad de prioridad con los procesos
interferentes. Esto se traduce en que al aumentar
el número de procesos de las pruebas se comparte
la CPU entre un número mayor de procesos de los
cuales a lo sumo uno en cada nodo va a ser
interferente. De este modo, la interferencia que va
a producir va a ser menor relativamente cuanto
mayor sea el número de procesos lanzados a los
nodos lo que hace converger las pruebas hacia
valores cercanos al tiempo de ejecución sin
interferencia que se estudió en el apartado 4.1
para ese número de procesos.
0
50
100
150
200
250
300
Con OM Sin OM Con OM Sin OM
Segundos
EP 04
EP 08
EP 16
EP 32
EP 64
EP 128
Figura 6. Pruebas compuestas EP.
En la figura 6 además podemos ver que
OpenMosix ha mejorado notablemente los
tiempos de ejecución para los casos más
desbalanceados, cuando lanzamos las NAS de 4 y
8 procesadores. Esta mejora se debe a que el
balanceo de carga permite aislar el proceso
interferente y manejar correctamente el resto. Esto
es posible porque la comunicación no es frecuente
ni voluminosa y los procesos pueden ser tratados
de forma independiente. Aún así, el tiempo de
ejecución es peor que el ideal, lo que es lógico
puesto que las NAS deben estar equilibradas para
dar tiempos óptimos.
Las BT son pruebas puramente de tipo IPC
puesto que basan todo su equilibrio en el uso de la
red de forma voluminosa y espaciada. Durante un
cierto tiempo (no muy grande) cada proceso de la
NAS trabaja sobre sus datos y en un momento
dado envía toda la información calculada al resto
de procesos para sincronizarse con ellos. Esto
400 Tecnologías Grid, Clusters y Plataformas Distribuidas
supone que si uno de esos procesos va más lento
que el resto enseguida va a dejar sin datos a los
demás. Los resultados obtenidos se muestran en la
figura 7, en el caso de las pruebas de cuatro
procesos vemos como el desbalanceo producido
por los procesos interferentes no se ve mejorado
por OpenMosix. Las razones, ya comentadas,
derivan del algoritmo de balanceo de carga que no
sabe bien qué hacer cuando los procesos se
quedan sin datos. En ese momento tiende a migrar
el proceso que aún debe terminar su parte de
cálculo hacia uno de los nodos que acaban de
quedar sin carga debido a la suspensión de los
procesos de las NAS. Pero el tiempo empleado en
la migración (las NAS de tipo BT ocupan mucha
memoria) no se ve compensado por el tiempo que
tarda el proceso migrado en terminar sus cálculos
dado que enseguida pasa los nuevos datos al resto
de procesos y el sistema vuelve a desequilibrarse
como consecuencia de la reanudación de los
mismos.
El otro caso curioso es el de las NAS BT de
nueve procesos. Como se observa en los datos, se
ha reducido la diferencia que existía frente al caso
ideal (en proporción). La razón es que tenemos un
nodo ocupado con un proceso que favorece la
ejecución de procesos en el resto de nodos. Esto
se traduce en una mejora si el número de procesos
interferentes es de dos puesto que se asignan éstos
a un solo nodo, dejando tres nodos para el cálculo
de las NAS BT de nueve procesos lo cual es
mucho más eficiente que antes.
0
500
1000
1500
2000
2500
3000
3500
4000
Con OM Sin OM Con OM Sin OM
Segundos
BT 04
BT 09
BT 16
BT 25
BT 36
Figura 7. Pruebas compuestas BT.
El problema de OpenMosix es que no puede
asignar dos procesos que se comunican entre sí al
mismo nodo dado que aún no implementa sockets
migrables. Si lo hiciera seguramente mejoraría los
resultados al desbalancear la carga, esto nos lleva
a concluir que las pruebas de tipo BT nunca se
van a ver beneficiadas por OpenMosix si aparece
un desbalanceo de la carga en cualquiera de sus
formas. Diremos a favor de OpenMosix que si no
existe este desbalanceo, bien porque el número de
procesadores es proporcional al de procesos o bien
porque no existen procesos interferentes, el
tiempo de ejecución va a ser muy similar al que
pueda presentar un cluster HPC tradicional.
Las pruebas de LU son intermedias entre las
dos anteriores. Como vemos prácticamente se
igualan ambos casos aunque a veces lo empeora.
Esto se debe a que las mejoras que podría producir
el balanceo de carga se ven anuladas por el tiempo
empleado en hacer las migraciones. Dado que
estas pruebas no ocupan demasiado la memoria
estas migraciones no tardan tanto como en el caso
de las NAS BT y por eso no se observa un
incremento notable del tiempo de ejecución.
Además la comunicación es mucho más fluida y
los procesos se comportan de una forma bastante
estable dentro de la ineficiencia que supone
desequilibrar las NAS. En la figura 8 se
representan los resultados.
0
200
400
600
800
1000
1200
1400
1600
1800
Con OM Sin OM Con OM Sin OM
Segundos
LU 04
LU 08
LU 16
LU 32
LU 64
LU 128
Figura 8. Pruebas compuestas LU.
En esta figura se observa además que
aumentar el número de procesos de la NAS no
favorece una convergencia hacia mejores tiempos
de ejecución. Esto no se debe a los procesos
interferentes puesto que con una NAS de 128
procesos quedan totalmente ocultos para los
procesadores. Las razones del empeoramiento son
propias del problema que resuelven estas pruebas,
como se vio en el apartado 4.1, en concreto en la
figura 4. En ella se observa un crecimiento casi
exponencial del tiempo de ejecución al aumentar
el número de procesos puesto que existe una gran
ineficiencia a la hora de resolver el problema que,
como era de esperar, queda aquí reflejado.
XVI Jornadas de Paralelismo, JP '2005 401
5. Conclusiones
Hemos estudiado el comportamiento de
OpenMosix en el manejo de aplicaciones
puramente paralelas programadas en MPI. La
conclusión a la que hemos llegado es que
OpenMosix no mejora el cómputo de estos
trabajos en los casos en los que la carga está
balanceada, pero sí en los que está desbalanceada
a no ser que concurran dos circunstancias: que la
aplicación sea muy voluminosa en comunicación
IPC y que el tiempo de migración sea elevado
debido al espacio de memoria ocupado por el
proceso. La teoría propone una solución para
balancear la carga en estos casos pero aún no se
ha podido implementar por requerir el uso de
migración de sockets.
Por otra parte hemos comprobado que
OpenMosix nos independiza del número de
procesos con que esté lanzada nuestra aplicación y
del número de procesos que se estén ejecutando
en las máquinas, ya que el sistema siempre
tenderá a balancear la carga de forma eficiente
salvo en los dos casos comentados. Esto hace que
el sistema sea poco intrusivo de cara al usuario
final y consigue simplificar la utilización del
cluster.
Referencias
[1] Amar, L., Barak, A., Eizenberg, A. and
Shiloh, A. The mosix scalable Cluster File
Systems for Linux. June 2000.
[2] Amar, L., Barak, A. and Shiloh, A. The
MOSIX Direct File System Access method for
supporting Scalable Cluster File Systems. The
Hebrew University of Jerusalem, 2003.
[3] Amir, Y., Awerbuch, B., Barak, A.,
Borgstrom, R. S., Keren, A. An Opprotunity
Cost Approach for Job Assignment and
Reassignment in a Scalable Computing
Cluster. IEEE Trans. Parallel and Distributed
Systems, vol 11, no 7, pp 760-768, July 2000.
[4] Anu, Maya, Asmita, Snehal, Krushna
(MAASK). OpenMosix Presented by Dr.
Moshe Bar and MAASK.
[5] Barak, Amnon, Guday, Shai, Wheeler,
Richard G. Lecture notes in computer science.
The MOSIX distributed operating system.
Load balancing for UNIX. (Springer-Verlag).
[6] Barak, Amnon and Keren, Arie. Opportunity
Cost Algorithms for Reduction of I/O and
Interprocess Communication Overhead in a
Computing Cluster. IEEE Transactions on
paralell and Distributed Systems, VOL. 14.
NO 1, January 2003.
[7] Barak, A. and Braverman, A. Memory
Ushering in a scalable Computing cluster.
Journal of Microprocessors and
Microsystems, 22(3-4). Aug.1998.
[8] Barak, A. and O. La’adan. The Mosix
Multicomputer operating system for high
performance cluster conmputing. Journal of
Futura Generation Computer Systems 13(4-
5):361-372, March 1998.
[9] Barak, Amnon, La’adan, Oren and Shiloh,
Amnon. Scalable cluster computing with
Mosix for Linux. In Proceedings of Linux
Expo 1999, pages 95-100, Raileigh, NC.,
USA, May 1999.
[10] Buytaert, Kris. The OpenMosix Howto.
[11] Catalán i Coït, Miquel. El Manual para el
clustering con openMosix. (Versión 1.0).
[12] Gropp, William, Lusk, Ewin and Sterling,
Thomas. Beowulf cluster computing with
Linux. Second Edition. Scientific and
Engineering Computation Series.The MIT
Press Cambridge, Massachusets London,
England, December 2003.
[13] Web del proyecto OpenMosix :
http://openmosix.sourceforge.net/
[14] www.systemimager.org/
[15] www.nas.nasa.gov/Software/NPB/
402 Tecnologías Grid, Clusters y Plataformas Distribuidas

          


                     
              !  "  # $ ! % &  ' %  (  "    $  '    )   * +   , -    .  /    
0 1 2 3 4 5 6
7 8 9 : ;
3 1 < 3
: 8 =
5 1 > ? @ 2
:
3
=
5 ?
8 A
B C
; D
1
8 A ;
3
=
3 E ? F
;
3 G < C
;
<
=
5 1 >
=
3
=
F
:
C H
=
I ?
8
5
; J ; 8
? C
= K L M N K O = 8
< 1 F ? C
= K P
2
= ;
C 4
Q
R S
=
F
= 8
3
K =
5
: 8 =
C
K
@
= 8
<
K
T
= D ;
@
K
1 5
: = 8
5
K
R
1
A : A U V =
< 4
:
2 < 4 1 5
:
W X Y Z [ \ ] Z
^ _ ` a b c a d e f g h f h i f j k f e l f e k g e f a m n b o g ` ` m n g e p
g ` ` f ` b q f h j m d g r h _ k b r s a d f n a d e f g h k ` b j e g e m t
u
n f r ^ v d g k e g e f ` m j f f r _ k f h a w n g e g ` ` f ` b q f
k _ o d x b r h w y g n n ` b o g a b w r k z g ` a d w _ s d i f y w e f p
k f f a d g a b a o g r j f g s e f g a a w w ` y w e r f a i w e x
k f e l f e k h f l f ` w n f e k t { r a d b k n g n f e i f o w | n g e f
d w i f g k m b k a w n g e g ` ` f ` b q f a d f } w g i f j k f e l f e
_ k b r s
u
n f r ^ v z o w | n g e f h a w g n a d e f g h k n g e g ` p
` f ` b q g a b w r z g r h a d f n f e y w e | g r o f g o d b f l f h t ~ f
n e f k f r a a d f e f k _ ` a k w y g n g e g ` ` f ` b q g a b w r j g k f h
w r
u
n f r ^ v  t € z a d f h m r g | b o k f o a b w r k | w h f `
g r h n a d e f g h k t
 ‚ ƒ
Z [ „ … † ] Z ‡ „
ƒ ˆ ‰
„ Z ‡ Š \ Z ‡ „
ƒ
u
n f r ^ v ‹ Œ €  d g k k _ o o f k k y _ ` ` m j f f r _ k f h a w
n g e g ` ` f ` b q f g s e f g a r _ | j f e w y g n n ` b o g a b w r k b r
a d f k o b f r a b Ž o h w | g b r t   a f r k b l f i w e x d g k j f f r
h w r f a w y _ ` Ž ` ` a d f r f f h k w y k o b f r a b Ž o g n n ` b o g p
a b w r k b r k d g e f h | f | w e m f r l b e w r | f r a k t ‘ d f
n g e g ` ` f ` b k | a d g a g n n f g e k b r r _ | f e b o g ` g n n ` b o g p
a b w r k d g k k b s r b Ž o g r a ` m b r ’ _ f r o f h a d f h f Ž r b a b w r
w y a d f
u
n f r ^ v “ v { t ^ w k a i w e x h b k a e b j _ a b w r
k o d f | f k g e f k n f o b Ž o g ` ` m h f k b s r f h a w k _ n n w e a
a d f | g b r k w _ e o f w y n g e g ` ` f ` b k | w y k o b f r a b Ž o g n p
n ` b o g a b w r k ” n g e g ` ` f ` ` w w n k t • w e k m r o d e w r b q g a b w r
| f o d g r b k | k n e w s e g | | f e k o g r _ k f j g e e b f e k m r p
o d e w r b q g a b w r k z | _ a _ g ` f  o ` _ k b w r g r h g a w | b o
k m r o d e w r b q g a b w r k t
~ f d g l f k a _ h b f h a d f y f g k b j b ` b a m w y _ k b r s
u
n f r ^ v a w n g e g ` ` f ` b q f g i f j k f e l f e a w k a g e a
f  n ` w e b r s a d f o d g e g o a f e b k a b o k a d g a i b ` ` j f y w _ r h
b r a d f k f r f i g n n ` b o g a b w r k t ~ f j k f e l f e k g e f b r p
d f e f r a ` m n g e g ` ` f ` g n n ` b o g a b w r k g k a d f h b – f e f r a
e f — _ f k a k g e f _ r e f ` g a f h g r h y e f f w y h f n f r h f r o f k
j f a i f f r a d f | t ‘ d _ k z a d f e f — _ f k a k o g r j f d g r p
h ` f h b r n g e g ` ` f ` t ~ f j k f
e l f e k d g l f j f f r a e g h b p
a b w r g ` ` m n g e g ` ` f ` b q f h i b a d ˜ ™ š › œ  ž Ÿ   a f o d r b — _ f k
¡
| g b r ` m ¢ ˜ ™ š › œ  £ ¤ t
u
_ e w j ¥ f o a b l f b k a w k n f o p
b y m _ k f y _ ` f  a f r k b w r k b y a d f
u
n f r ^ v “ v { h w f k
r w a f g k b ` m k _ n n w e a a d f n g e g ` ` f ` b k | y w _ r h b r i f j
k f e l f e k t
~ f d g l f k f ` f o a f h a d f } w g ‹ ¦  i f j k f e l f e
g k a d f n ` g a y w e | a w j f n g e g ` ` f ` b q f h t § b – f e f r a
n g e g ` ` f ` k a e g a f s b f k d g l f j f f r h f l f ` w n f h t “ r
u
n f r ^ v l f e k b w r g ` ` w i f h _ k a w f l g ` _ g a f a d f
n e w s e g | | b r s f – w e a g r h a d f e f k _ ` a b r s n f e y w e p
| g r o f _ k b r s a d f o _ e e f r a
u
n f r ^ v k a g r h g e h t
“ ` k w z i f h f l f ` w n f h g l f e k b w r a d g a _ k f k a d f
n e w n w k f h  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ ‹   o w r k a e _ o a b w r k
a w o d f o x a d f b e _ k f y _ ` r f k k t • b r g ` ` m z g | g r p
_ g ` ¢ ˜ ™ š › œ  j g k f h l f e k b w r i g k h f l f ` w n f h a w h w
g o w | n e f d f r k b l f o w | n g e b k w r t “ ` ` a d e f f l f e p
k b w r k i f e f f l g ` _ g a f h g s g b r k a a d f w e b s b r g ` l f e p
k b w r i d b o d b k k b r s ` f a d e f g h f h t
¬ ­ ® ¯
\ Z
®
… ° „ [ ±
²
f l f e g ` g _ a d w e k d g l f o w | n g e f h
u
n f r ^ v l f e p
k _ k n a d e f g h k t ‘ d f k f o w | n g e b k w r k d g l f j f f r
b r k o b f r a b Ž o g n n ` b o g a b w r k w e o w | n g e b k w r k j f p
a i f f r j g k b o ` g r s _ g s f o w r k a e _ o a b w r k t ³ _ d r f a
g ` t o w | n g e f h a d f n e b | b a b l f k n e w l b h f h j m j w a d
| w h f ` k o w r o ` _ h b r s a d g a
u
n f r ^ v i g k f g k b f e a w
_ k f j _ a a d f m g ` k w n w b r a f h w _ a k w | f n e w j ` f | k
i b a d b e e f s _ ` g e g n n ` b o g a b w r k ‹ ´  t µ f f g r h § w i p
r g e o w | n g e f h j w a d ` g r s _ g s f k y w e g r _ o ` f g e e f p
g o a w e a e g r k b f r a o w h f ‹ ¶  t ‘ d f m w j a g b r f h k b | b ` g e
n f e y w e | g r o f i b a d j w a d
u
n f r ^ v g r h n a d e f g h k
j _ a
u
n f r ^ v i g k f g k b f e a w _ k f t } e f k d f g e k g r h
µ _ w r s o w | n g e f h j w a d | w h f ` k b r a d f o w r a f  a w y
g · w g k a g `
u
o f g r · b e o _ ` g a b w r ^ w h f ` ‹ ¸  t ‘ d f b e
o w r o ` _ k b w r i g k a d g a
u
n f r ^ v i g k f g k b f e a w _ k f
m b f ` h b r s a d f k g | f n f e y w e | g r o f a d g r n a d e f g h k t
§ f h _ f a g ` t o w | n g e f h j w a d | w h f ` k i b a d k w | f
g ` s w e b a d | k y e w | a d f g e a b Ž o b g ` b r a f ` ` b s f r o f Ž f ` h
‹  t ‘ d f m y w _ r h a d g a g ` a d w _ s d y w e e f s _ ` g e g n p
n ` b o g a b w r k
u
n f r ^ v i g k f g k b f e a w _ k f g r h w j p
a g b r f h a d f k g | f n f e y w e | g r o f a d g r n a d e f g h k y w e
b e e f s _ ` g e g n n ` b o g a b w r k
u
n f r ^ v i g k h b
o _ ` a a w
_ k f t
²
w | f w a d f e i w e x k d g l f a e b f h a w f  a f r h
u
n f r ^ v a w j f g j ` f a w o w n f i b a d b e e f s _ ` g e
g n n ` b o g a b w r k t “ k f r ¥ w f a g ` t f  n ` w e f h k w | f
a f o d r b — _ f k a w h f g ` i b a d n w b r a f e k g r h a e g l f e p
k g ` w y k a e _ o a _ e f k ‹ Œ  t
²
d g d f a g ` t b r a e w p
h _ o f h a d f  « š    ›  › ž Ÿ   © «  ›  ‹ Œ Œ  t ‘ d b k
n e w n w k g ` f  a f r h k a d f
u
n f r ^ v n e w s e g | | b r s
| w h f ` i b a d g r g ` a f e r g a b l f i w e x h b k a e b j _ a b w r
k o d f | f j g k f h w r a d f h f Ž r b a b w r w y   ›  › £ «

 « š  y e w | i d f e f a d f f  f o _ a b r s a d e f g h k f  p
a e g o a i w e x t ‘ d f f  a f r k b w r a g e s f a k g ` s w e b a d | k
a e g l f e k b r s | f | w e m g r h ` b r x f h h g a g k a e _ o a _ e f k t
‘ d f n e w n w k g ` d g k j f f r k _ o o f k k y _ ` j _ a b r a e w p
h _ o f k h e g | g a b o o d g r s f k b r a d f
u
n f r ^ v f  f p
o _ a b w r | w h f ` t ~ f n e f l b w _ k ` m n e w n w k f h a w _ k f
 ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ ‹   a w | b r b | b q f a d f o d g r s f k
w y a d f  « š    ›  › ž Ÿ   © «  ›  z b r i d b o d  ¨ Ÿ œ © ž ª
£ › ª ˜ ž « Ÿ £ g e f j g k f h t ~ f y _ e a d f e f  a f r h a d f k f p
| g r a b o k w y a d f  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ b r a d b k i w e x t

® 
„ \ 
®
X Y
®
[ Š
®
[
‘ d f } w g i f j k f e l f e g e o d b a f o a _ e f b k g k b r s ` f
a d e f g h f h f l f r a c h e b l f e ‘ ‘ v k f e l f e g e o d b a f o p
a _ e f t ‘ d b k x b r h w y g e o d b a f o a _ e f z _ r ` b x f a e g h b p
a b w r g ` i f j k f e l f e k z h w f k r w a y w e x y w e f g o d b r p
o w | b r s o w r r f o a b w r t { r k a f g h z } w g o w | f k i b a d
g r b r a f s e g a f h a g k x k o d f h _ ` f e a d g a d g r h ` f k | _ ` p
a b n ` f e f — _ f k a k o w r o _ e e f r a ` m j _ a r w a b r n g e g ` ` f ` t
} w g | _ ` a b n ` f  f k g ` ` w r s w b r s e f — _ f k a k z a e m b r s
a w | g  b | b q f a d f a d e w _ s d n _ a g r h | b r b | b q f a d f
e f k n w r k f a b | f t ‘ d f k o d f h _ ` f e _ k f k a i w e f — _ f k a
— _ f _ f k ” a d f š › œ  ¨ — _ f _ f x f f n k a d w k f e f — _ f k a k
g l g b ` g j ` f y w e y _ e a d f e n e w o f k k b r s t ‘ d f   « ª  › 
— _ f _ f x f f n k a d w k f e f — _ f k a k i g b a b r s y w e g r m
h g a g h f n f r h f r o f a w j f k g a b k Ž f h t { a f e g a b l f ` m z
a d f k f e l f e a e g l f e k f k a d f š › œ  ¨ — _ f _ f g r h y _ e p
a d f e n e w o f k k f k f g o d e f — _ f k a t ‘ d f k f e l f e _ k f k g
e w _ r h c e w j b r a f o d r b — _ f a w g l w b h ` g e s f e f — _ f k a k
k a g e l b r s w a d f e š › œ  ¨ e f — _ f k a k t } w g ` w s b o g ` ` m
h b l b h f k f
g o d e f — _ f k a b r k | g ` ` f e o d _ r x k w y i w e x
g r h f g o d a b | f g e f — _ f k a b k n e w o f k k f h g k b r s ` f
o d _ r x b k o w r k _ | f h t “ ` s w e b a d | Œ k d w i k g k b | p
n ` b Ž f h o w h f a d g a n e w o f k k f k a d f e f — _ f k a k y e w |
a d f š › œ  ¨ — _ f _ f t “ y a f e g e f — _ f k a b k n e w o f k k f h
Œ t { a b k x f n a b r a d f š › œ  ¨ — _ f _ f j f o g _ k f b a
k d w _ ` h j f y _ e a d f e n e w o f k k f h
¡
b t f t b a d g k
| w e f o d _ r x k g r h g ` ` h g a g g e f g l g b ` g j ` f ¤ t
 t { a b k | w l f h a w a d f   « ª  ›  — _ f _ f j f o g _ k f
a d f k f e l f e h f a f o a f h g r _ r k g a b k Ž f h h f n f r p
h f r o f
¡
f t s t b a r f f h k a w e f g h h g a g y e w | g
k w o x f a ¤ t

t { a b k y e f f h j f o g _ k f a d f ` g k a o d _ r x w y a d f
e f — _ f k a i g k o w r k _ | f h t
                            

     !   " 
    #  $        !    %        &
       '         %      &
  %     #  $ $ ( ) * + , &
- #   . %        &
 #     %     #  $ $ / 0 1 0 2 3 4 5 &
    %        &
 #  
.              
6
7 8 9 : ; < = > ? @ A B
1
9 :
1
A
3 2
8
? < 1
A A ;
C C
` w w n n k f _ h w c o w h f t
‘ d f k f e l f e a e g l f e k f k a d f   « ª  ›  — _ f _ f g r h
y w e f g o d e f — _ f k a b a o d f o x k b y a d f e f — _ f k a h f p
n f r h f r o f k g e f k g a b k Ž f h _ k b r s a d f b r y w e | g a b w r
b a o w ` ` f o a k i b a d a d f £ ›  › ª ˜ k m k a f | o g ` ` t ~ d f r g
e f — _ f k a d g k r w y _ e a d f e h f n f r h f r o f k b a b k | w l f h
g s g b r a w a d f š › œ  ¨ — _ f _ f t
“ ` s w e b a d |  k d w i k a d f k a e _ o a _ e f w y a d f | g b r
` w w n w y a d f k f e l f e t ‘ d b k ` w w n b k b r Ž r b a f g r h b r
f g o d b a f e g a b w r a d f k f e l f e
Πt n e w o f k k f k g r m n f r h b r s k b s r g ` t
 t a e g l f e k f k a d f   « ª  ›  — _ f _ f a w o d f o x a d f
h f n f r h f r o f k w y j ` w o x f h e f — _ f k a k t

t f k a g j ` b k d f k n f r h b r s r f i o w r r f o a b w r k _ k p
b r s a d f œ ª ª › ¢ ˜ k m k a f | o g ` ` t
404 Tecnologías Grid, Clusters y Plataformas Distribuidas
¸ t a e g l f e k f k a d f š › œ  ¨ — _ f _ f a w n e w o f k k | w e f
o d _ r x k w y a d f _ r j ` w o x f h e f — _ f k a k t
t o g ` ` k £ ›  › ª ˜ a w w j a g b r b r y w e | g a b w r g j w _ a
r f i o w r r f o a b w r k g r h a d f k a g a _ k w y b r o w | p
b r s g r h w _ a s w b r s h g a g t
'   #  % &

       
  #  %      &
"               " - #   .  
          
  #        # 
       '            %      &
                            
  #         "   # #
6
7 8 9 : ; < = > ?  A  = ;
C F ? ? 2 2
A
1
:
5 ?  < ? 5 1 4
} w g a e b f k a w e f h _ o f a d f r _ | j f e w y b k k _ f h
k m k a f | o g ` ` k j m © © œ ¢ ž Ÿ   ` w o g ` Ž ` f k b r a w a d f
k f e l f e | f | w e m t “ o g o d f w y « ¢ › Ÿ   › £
¡
b t f g o a b l f
| g n k ¤ z i d b o d b a b k o d f o x f h f g o d a b | f g r f i Ž ` f
b k e f — _ f k a f h z g l w b h k © © œ ¢ ž Ÿ   a i b o f a d f k g | f
Ž ` f t
‘ d f k f e l f e n f e y w e | k g ` ` b r n _ a  w _ a n _ a i b a d
r w r p j ` w o x b r s k m k a f | o g ` ` k a w f r k _ e f a d g a r w
k b r s ` f e f — _ f k a j ` w o x k a d f n e w o f k k b r s w y w a d f e k
a d g a g e f e f g h m t

\ [ \
¯ ¯ ® ¯
‡
‡
ƒ  
„ \
‘ d f | g b r k w _ e o f w y n g e g ` ` f ` b k | b r a d f } w g i f j
k f e l f e b k a d f n w k k b j b ` b a m w y w l f e ` g n n b r s a d f o w | p
n _ a g a b w r k e f ` g a f h a w h b – f e f r a e f — _ f k a k t “ k f  p
n ` g b r f h b r k f o a b w r

a d f e f — _ f k a k g e f n ` g o f h b r
a d f š › œ  ¨ g r h   « ª  ›  — _ f _ f k g r h a d f k f e l f e b a p
f e g a b l f ` m a e g l f e k f k a d f k f — _ f _ f k t v g e g ` ` f ` n e w p
o f k k b r s b k n w k k b j ` f j m n e w o f k k b r s f g o d f ` f | f r a
w y a d f — _ f _ f k b r n g e g ` ` f ` t ‘ d f k f e l f e o g r g ` k w
h w h b – f e f r a a g k x k b r n g e g ` ` f `
¡
f t s t g o o f n a b r s
r f i e f — _ f k a k g r h n e w o f k k b r s r f i e f — _ f k a k ¤ t
“ ` ` a d f l f e k b w r k h f k o e b j f h f  n ` w b a a d f k f k w _ e o f k
w y n g e g ` ` f ` b k | t
§ b – f e f r a n w b r a k b r a d f k f e l f e e f — _ b e f k f e b g ` p
b q g a b w r t • b e k a z | w h b Ž o g a b w r w y s ` w j g ` l g e b g j ` f k
¡
f t s t a d f r _ | j f e w y g o a b l f o w r r f o a b w r k ¤ t
²
f o p
w r h z | g r b n _ ` g a b w r k w y a d f š › œ  ¨ g r h   « ª  › 
— _ f _ f k t ‘ d b e h z g o o f n a g r o f w y r f i o w r r f o a b w r k t
• w _ e a d z g o o f k k a w a d f o g o d f w y w n f r Ž ` f k t “ r h
` g k a z i e b a f g o o f k k a w a d f k f e l f e ` w s Ž ` f k a w g l w b h
| b  b r s a d f w _ a n _ a w y h b – f e f r a a d e f g h k t
‘ d f w e b s b r g ` l f e k b w r _ k f k g ` w a w y £ ˜ œ ˜ ž ª l g e b p
g j ` f k b r k b h f k y _ r o a b w r k t ‘ d f k f l g e b g j ` f k i f e f
o w r l f e a f h a w f  a e g n g e g | f a f e k w y a d f y _ r o a b w r
a d f m i f e f b r t “ r w a d f e n w k k b j ` f w n a b w r i g k a w
_ k f n f e a d e f g h l g e b g j ` f k
¡
f t s t ˜ ™ š › œ  ¢ š ž  œ ˜ › b r
u
n f r ^ v ¤ t
~ f d g l f h f l f ` w n f h a d e f f n g e g ` ` f ` l f e k b w r k ”
g ¢ ˜ ™ š › œ  £ l f e k b w r z g n _ e f
u
n f r ^ v l f e k b w r
g r h g l f e k b w r _ k b r s  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ i d b o d
g e f r w r c k a g r h g e h t

@  = > ;       ;  8 8  8   ;  < : 
‘ d f ¢ ˜ ™ š › œ  n g e g ` ` f ` l f e k b w r f  n ` w b a k a d f n w k p
k b j b ` b a m w y n e w o f k k b r s h b – f e f r a e f — _ f k a k b r n g e p
g ` ` f ` z g k a d f m g e f _ r e f ` g a f h t ‘ d f n g e g ` ` f ` b q g p
a b w r _ k f k g n e w h _ o f e c o w r k _ | f e g n n e w g o d t
u
r f
a d e f g h f  f o _ a f k g ` ` a d f a g k x k b r a d f | g b r } w g
` w w n z h f k o e b j f h b r “ ` s w e b a d |  z f  o f n a e f p
— _ f k a k n e w o f k k b r s t ‘ d b k a d e f g h b k a d f n e w p
h _ o f e w y r f i š › œ  ¨ e f — _ f k a k t ‘ d f e f | g b r b r s
a d e f g h k o w r k _ | f a d f š › œ  ¨ e f — _ f k a k g r h n e w p
o f k k a d f | g k f  n ` g b r f h b r k f o a b w r

t “ ` s w p
e b a d |

k d w i k a d f o w h f a d f o w r k _ | f e a d e f g h k
f  f o _ a f t ‘ d f ¢ ˜ ™ š › œ  l f e k b w r _ k f k a d f k g | f
e w _ r h c e w j b r | f o d g r b k | w y a d f k f e b g ` l f e k b w r t
²
w z f g o d a b | f g a d e f g h f  a e g o a k g e f — _ f k a g
k b r s ` f o d _ r x b k o w r k _ | f h g r h a d f e f — _ f k a | g m
j f — _ f _ f h g s g b r a w a d f š › œ  ¨ — _ f _ f t
   %   &

'   #  %        
        & 
      ! "     ! #   . %

     ! #   . &
  %     
        &

   $        %        !      & 
6
      ! "     !   #   . %

     ! #   . & 
  %    &
      !        %    & 
6
7 8 9 : ; < = > ?  A
> ? 5 1  ?
8
3 
8
1
=
5 < ? C
A :
@ 1
8 A ;
C
a d f ¢ ˜ ™ š › œ  } w g l f e k b w r t
XVI Jornadas de Paralelismo, JP '2005 405
 
   
  =     ;    ;  8 8  8 <   = < : 
  
"   "    # #  #


                 
  
"   " -      
                            

  
"   " "     
       " 
  
"   "   
#    '   
            #  $
         %        &
  
"   " "     
       '         %      &
6
6
                            

  %             #  $ $ ( ) * + , &
- #   . %        &
 #     %             #  $ $ / 0 1 0 2 3 4 5 &
    %        &
 #  
.              
6
7 8 9 : ; < = > ?

A 
2 1 C

E
8
1
9 :
1
A
3
n e w o f k k b r s ` w w n n k f _ h w c o w h f t
• w e w _ e
u
n f r ^ v n g e g ` ` f ` b q g a b w r i f a g e s f a f h
a d f e f — _ f k a n e w o f k k b r s ` w w n “ ` s w e b a d | Œ t ~ f
i g r a f h a w h b k a e b j _ a f g ` ` a d f e f — _ f k a k b r a d f
š › œ  ¨ — _ f _ f g | w r s a d f g l g b ` g j ` f a d e f g h k j m
_ k b r s g i w e x k d g e f t ‘ d f r _ | j f e w y e f — _ f k a k b r
a d f — _ f _ f o g r l g e m h _ e b r s b a k a e g l f e k g `
¡
f t s t
b y g e f — _ f k a b k y e f f ¤ t } f o g _ k f b r
u
n f r ^ v
g ` ` a d e f g h k | _ k a k f f a d f k g | f b a f e g a b w r k i f
k n ` b a a f h a d f ` w w n b r a i w r f i ` w w n k ” w r f h w f k
r w a e f | w l f e f — _ f k a k a d f — _ f _ f i d b ` f a d f w a d f e
h w f k t { r a d f Ž e k a r f i ` w w n z a d f k f e l f e n e w p
o f k k f k f g o d e f — _ f k a b r a d f š › œ  ¨ — _ f _ f t ‘ d f
e f k _ ` a w y f g o d n e w o f k k b r s b k k a w e f h b r g r f i
Ž f ` h w y a d f e f — _ f k a k a e _ o a _ e f t ‘ d b k ` w w n i g k
n g e g ` ` f ` b q f h _ k b r s g ¢ œ š œ   ›  o w r k a e _ o a g r h i f
_ k f h g £ ž Ÿ    › i w e x k d g e f a w h b k a e b j _ a f a d f h b – f e p
f r a b a f e g a b w r k t  k b r s a d f e f k _ ` a y e w | a d f Ž e k a
` w w n a d f k f e l f e | w h b Ž f k a d f — _ f _ f k b r a d f k f o p
w r h ` w w n i d b o d | _ k a j f h w r f k b r s ` f p a d e f g h f h t
“ ` s w e b a d | ¸ k d w i k a d f
u
n f r ^ v n g e g ` ` f ` b q g p
a b w r w y a d f r f i ` w w n k t ~ d f r r f i e f — _ f k a k g e f
g o o f n a f h
a d f m g e f g h h f h a w a d f j f s b r r b r s w y
a d f — _ f _ f t } f y w e f a d f k f e l f e g o o f n a k g r m e f p
— _ f k a g ` ` a d e f g h k s e g j a d f d f g h w y a d f — _ f _ f t
‘ d b k s _ g e g r a f f k a d f m i b ` ` a e g l f e k f a d f k g | f f ` p
f | f r a k t

     ? <   = < :     ;  8 8  8 <   = < : 
‘ d f n e f l b w _ k n e f k f r a f h n g e g ` ` f ` b q g a b w r k i f e f
b r n e f l b w _ k k f o a b w r i f e f | g b r ` m n w k k b j ` f j f p
o g _ k f a d f k f e b g ` l f e k b w r d g h g ` e f g h m f | j f h h f h
g o w | n ` f  o w h f a d g a h f g ` a i b a d e f — _ f k a j ` w o x p
b r s g r h a d f b e k o d f h _ ` b r s
¡
b t f t a d f e f g h m — _ f _ f ¤ t
u
_ e — _ f k a b w r r w i b k ” o w _ ` h
u
n f r ^ v | g x f a d b k
i w e x f g k m a w a d f n e w s e g | | f e

‘ d f g l g b ` g j ` f n g e g ` ` f ` b k | o g r j f k f f r g k g
o w ` ` f o a b w r w y a g k x k t ~ f d g l f _ k f h a d f  ¨ 
Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ n e w n w k f h f  a f r k b w r a w f  n e f k k
a d b k n g e g ` ` f ` b k | f g k b ` m t  r h f e a d b k | w h f ` g k b r p
s ` f a d e f g h b k b r o d g e s f w y n f e y w e | b r s a d f k f p
e b g ` i w e x
¡
g o o f n a b r s e f — _ f k a k z f  a e g o a b r s a d f |
y e w | a d f j ` w o x f h — _ f _ f z t t t ¤ i d b ` f a d f e f | g b r p
b r s a d e f g h k f  f o _ a f a d f n g e g ` ` f ` a g k x k a d g a g e f
o e f g a f h
¡
b t f t g h m r g | b o k f o a b w r ¤ t
{ r a d b k l f e k b w r z i f d g l f e f | w l f h n g e a w y a d f
b r a f s e g a f h k o d f h _ ` f ” a d f e f g h m — _ f _ f d g k j f f r
e f | w l f h t { r k a f g h w y — _ f _ f b r s e f — _ f k a k b r a d f
š › œ  ¨ — _ f _ f r w i a d f a d e f g h k o e f g a f r f i h m p
r g | b o k f o a b w r k t “ r f i h m r g | b o k f o a b w r b k o e f p
g a f h
•
~ d f r g r f i e f — _ f k a b k g o o f n a f h z g r f i
k f o a b w r b k o e f g a f h y w e a d f Ž e k a o d _ r x w y
a d f e f — _ f k a t
•
~ d f r g e f — _ f k a d g k o w | n ` f a f h g o d _ r x z
b y b a i g k r w a a d f ` g k a z g r f i k f o a b w r b k o e f p
g a f h y w e a d f r f  a o d _ r x t ‘ d b k h m r g | b o
k f o a b w r b k o e f g a f h b r k b h f g r w a d f e t ~ f d g l f
f  a f r h f h a d f w e b s b r g ` | w h f ` a w g ` ` w i r f k a p
b r s w y
²
 · ‘ {
u 
o w r k a e _ o a k t
•
~ d f r g e f — _ f k a b k _ r j ` w o x f h z j f o g _ k f
a d f b e h f n f r h f r o f k g e f y _ ` Ž ` ` f h z g r f i k f o p
a b w r b k o e f g a f h y w e a d f r f  a o d _ r x t
406 Tecnologías Grid, Clusters y Plataformas Distribuidas
  
"   "    # #  #
  
"   "             "  
'   #  % &

       
  #  %      &
                 "    - #   .       

  %                     "   &

          "    - #   .       
  
"   "       
            %        &
     !        %        &
6
6
  %   '           &

      
  
"   "       
            %   '           &
      !        %   '           &
6
  #         "   # #
6
7 8 9 : ; < = > ? A  = ;
C F ? ? 2 2
A
1
:
5 ?  < ? 5 1
i b a d  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ t
“ ` s w e b a d | k d w i k w _ e n g e g ` ` f ` b q g a b w r w y a d f
o w h f w y a d f | g b r ` w w n _ k b r s a d f  ¨ Ÿ œ © ž ª £ › ª 
˜ ž « Ÿ £ t


Š \
¯
† \ Z ‡ „
ƒ

@    < ; :  ?   =
• w e w _ e f  n f e b | f r a k i f _ k f h g ¸ p i g m { r a f `
 f w r g a Œ t ¸  q i b a d   } w y  “ ^ a w e _ r
a d f i f j k f e l f e g r h g  p i g m { r a f `  f w r g a  t ¸
 q i b a d   } w y  “ ^ a w e _ r a d f j f r o d | g e x
o ` b f r a t “ ` ` a d f | g o d b r f k i f e f e _ r r b r s g  t ¦
µ b r _  x f e r f ` t ‘ d f r f a i w e x a d g a o w r r f o a f h a d f
| g o d b r f k i g k g k i b a o d f h  b s g j b a r f a i w e x t

  : ;  8 :   9    ;  = : ;
~ f _ k f h a a n f e y ‹  a w s f r f e g a f a d f h b – f e f r a
i w e x ` w g h k y w e a d f f  n f e b | f r a k t ‘ d b k a w w ` g ` p
` w i k a d f o e f g a b w r w y g o w r a b r _ w _ k ’ w i w y ‘ ‘ v
e f — _ f k a k a w a d f k f e l f e | g o d b r f t ‘ d f a w w `
g o o f
n a k g k w r f w y b a k n g e g | f a f e k a d f r _ | p
j f e w y o ` b f r a k n f e k f o w r h t • w e f g o d o ` b f r a z
b a w n f r k g k f k k b w r i b a d a d f k f e l f e a d e w _ s d g
n f e k b k a f r a ‘ ‘ v o w r r f o a b w r t ‘ d f r g k f e b f k
w y e f — _ f k a k g e f b k k _ f h j m a d f o ` b f r a z k w | f w y
a d f | n b n f ` b r f h z k w | f k n g o f h j m g ˜ ™ ž Ÿ  ˜ ž © › t
“ r w a d f e n g e g | f a f e w y a a n f e y b k a d f k f k k b w r k
h g a g j g k f y e w | i d f e f o ` b f r a k s f a a d f e f — _ f k a k
a d f m g k x y w e g r h a d f a d b r x a b | f k a w i g b a t
~ f d g l f _ k f h g h g a g j g k f f  a e g o a f h y e w | a d f
²
_ e s f ‹

 i w e x ` w g h s f r f e g a w e t
‘ d f k o f r g e b w n e w h _ o f h j m
²
_ e s f b k g k a g a b o
o w r a f r a i w e x ` w g h o d g e g o a f e b q f h j m k d w e a k f k p
k b w r ` f r s a d k g r h ` w i o w | n _ a g a b w r g ` o w k a k y w e
f g o d e f — _ f k a k f e l b o f h t ‘ d f
²
_ e s f h b k a e b j _ a b w r
b k j g k f h w r g | w h f ` h f l f ` w n f h y e w | a d f w j k f e p
l g a b w r w y e f g ` i f j k f e l f e ` w s k t

 
  ; < ?   = 
~ f f l g ` _ g a f h g ` ` h b – f e f r a l f e k b w r k w y a d f } w g
i f j k f e l f e _ k b r s a d f
²
_ e s f i w e x ` w g h i b a d h b y p
y f e f r a ` w g h k w y o ` b f r a k t ‘ d f k f ` w g h o w r Ž s _ e g p
a b w r k e g r s f h y e w | g ` w i ` w g h w y o ` b f r a k
¡
Œ € n f e
k f o w r h ¤ a w d f g l m ` w g h w y o ` b f r a k
¡
¶ € € o ` b f r a k
n f e k f o w r h ¤ t { r a d f y w ` ` w i b r s n ` w a k z i f ` g j f ` f h
a d f h b – f e f r a } w g l f e k b w r k g k y w ` ` w i k ”
•
« š ž   ž Ÿ œ   « œ e f y f e k a w a d f _ r | w h b Ž f h
k b r s ` f c a d e f g h } w g k f e l f e t
•
 « œ  ¢ ˜ ™ š › œ  £ e f y f e k a w a d f n g e g ` ` f ` l f e k b w r
a d g a _ k f k ¢ ˜ ™ š › œ  £ t
•
 « œ  « © ¢ e f y f e k a w a d f n g e g ` ` f ` l f e k b w r a d g a
_ k f k k a g r h g e h
u
n f r ^ v o w r k a e _ o a b w r k t
•
 « œ   £ › ª ˜ ž « Ÿ £ e f y f e k a w a d f n g e g ` ` f ` l f e k b w r
a d g a _ k f k  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ t
“ ` ` n g e g ` ` f ` l f e k b w r k i f e f e _ r i b a d  g r h ¸
a d e f g h k t
• b s _ e f Œ k d w i k y w e f g o d ` w g h w y o ` b f r a k a d f
a d e w _ s d n _ a w j a g b r f h j m f g o d } w g l f e k b w r t “ ` `
l f e k b w r k z f  o f n a a d f  « œ  « © ¢ l f e k b w r z w j a g b r f h
g k b | b ` g e a d e w _ s d n _ a _ n a w g i w e x ` w g h w y ´ € €
o ` b f r a k n f e k f o w r h t ‘ d f  « œ  « © ¢ l f e k b w r i g k
w _ a n f e y w e | f h j f o g _ k f a d f k f e l f e h b h r w a e _ r
g k | _ o d a b | f b r n g e g ` ` f ` g k a d f w a d f e l f e k b w r k
h w t § w _ j ` b r s a d f r _ | j f e w y a d e f g h k b r a d f
n g e g ` ` f ` l f e k b w r k h b h r w a e f k _ ` a b r g r w a b o f p
g j ` f b r o e f g k f w y a d e w _ s d n _ a j f o g _ k f
²
_ e s f b k
XVI Jornadas de Paralelismo, JP '2005 407
0
500
1000
1500
2000
2500
3000
3500
4000
0 100 200 300 400 500 600 700 800
replies/s
Number of clients/s
original boa
boa-dsections with 2 threads
boa-dsections with 4 threads
boa-omp with 2 threads
boa-omp with 4 threads
boa-pthreads with 2 threads
boa-pthreads with 4 threads
;
C
: 8
1
L


8
?
:
C  2
:
3 
8
1 2 F
;
1
A
2 1
8 A
1 < ? C 5  4
r w a · v  c b r a f r k b l f i w e x ` w g h g k b a i w e x k i b a d
k a g a b o o w r a f r a t ~ b a d ´ € € o ` b f r a k n f e k f o w r h
a d f ` b | b a w y a d f  b s g j b a r f a i w e x i g k e f g o d f h
g r h g ` ` l f e k b w r k a d e w _ s d n _ a h f a f e b w e g a f h g k
a d f m i f e f k g a _ e g a f h t
²
g a _ e g a b w r d g n n f r k f g e p
` b f e _ k b r s | w e f a d e f g h k j f o g _ k f o w r a f r a b w r b r
k d g e f h e f k w _ e o f k d g l f g s e f g a f e b | n g o a t ‘ d f
} w g k f e l f e _ k f k g | f o d g r b k | a d g a | b r b | b q f k
a d f f – f o a w y k g a _ e g a b w r ` b | b a b r s a d f r _ | j f e w y
g o a b l f o w r r f o a b w r k t ~ f h b k g j ` f h a d b k | f o d g p
r b k | w r n _ e n w k f k w i f o w _ ` h Ž r h a d f n w b r a g a
i d b o d f g o d n g e g ` ` f ` l f e k b w r k g a _ e g a f k t
• b s _ e f  k d w i k a d f g l f e g s f e f k n w r k f a b | f
y w e f g o d ` w g h w y o ` b f r a k g r h f g o d } w g l f e k b w r t
“ ` ` n g e g ` ` f ` l f e k b w r k g o d b f l f h g ` w i f e e f k n w r k f
a b | f a d g r a d f w e b s b r g ` } w g l f e k b w r t ~ b a d g
` w g h w y ¶ € € o ` b f r a k n f e k f o w r h e f k n w r k f a b | f
i g k e f h _ o f h g k | _ o d g k j m a d e f f t § w _ j ` b r s
a d f r _ | j f e w y a d e f g h k b r  « œ   £ › ª ˜ ž « Ÿ £ g r h
 « œ  ¢ ˜ ™ š › œ  £ i g k _ k f y _ ` e f h _ o b r s a d f e f k n w r k f
a b | f t ~ b a d y w _ e a d e f g h k  « œ   £ › ª ˜ ž « Ÿ £ g r h  « œ 
¢ ˜ ™ š › œ  £ j f d g l f h k w o ` w k f ` m a d g a a d f b e ` b r f k g e f
w l f e ` g n n f h t ~ b a d a i w a d e f g h k a d f m j f d g l f h
k b | b ` g e ` m f  o f n a i b a d g ` w g h w y ´ € € o ` b f r a k n f e
k f o w r h i d f e f  « œ  ¢ ˜ ™ š › œ  £ e f k n w r k f a b | f i g k
` w i f e t ‘ d f g l f e g s f e f k n w r k f a b | f y w e a d f  « œ 
« © ¢ l f e k b w r i g k l f e m ` w i z r f g e a w q f e w t ‘ d b k
e f k _ ` a b k | b k ` f g h b r s j f o g _ k f a d f k f e l f e i g k e f p
¥ f o a b r s | w e f a d g r ´  w y a d f e f
— _ f k a k t
 
„  \ [ ‡ Y „
ƒ
{ r a d b k k f o a b w r i f o w | n g e f a d f n e w s e g | | b r s
f – w e a e f — _ b e f h j m a d f a d e f f n g e g ` ` f ` l f e k b w r k ”
¢ ˜ ™ š › œ  £ z
u
n f r ^ v g r h  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ t
u
r f w y a d f | w k a o w r k _ | b r s a g k x k b r n g e g ` p
` f ` b q b r s g ` ` a d f l f e k b w r k i g k e f | w l b r s a d f k a g a b o
l g e b g j ` f k b r ` w o g ` y _ r o a b w r k t § _ f a w a d f ` g e s f
g | w _ r a w y £ ˜ œ ˜ ž ª l g e b g j ` f k a d g a | g m g n n f g e b r
k f e b g ` · o w h f k o w | n b ` f e k o w _ ` h n e w l b h f g r w n p
a b w r a d g a a e g r k y w e | f h g r m l g e b g j ` f i b a d £ ˜ œ ˜ ž ª
k a w e g s f a w g l g e b g j ` f i b a d ˜ ™ š › œ  ¢ š ž  œ ˜ › k a w e p
g s f t ‘ d b k w n a b w r i w _ ` h e f h _ o f a b | f k n f r a b r
n g e g ` ` f ` b q b r s ` g e s f · o w h f k t
“ r w a d f e f – w e a z o w | | w r b r g ` ` l f e k b w r k z i g k
n e w a f o a b r s k d g e f h h g a g i b a d o e b a b o g ` k f o a b w r k
g r h ` w o x k t ‘ d b k i w e x b r i g k — _ b o x f e h w r f
i b a d
u
n f r ^ v a d g r i b a d ¢ ˜ ™ š › œ  £ g k m w _ w r ` m
r f f h a w g h h a d f g n n e w n e b g a f h b e f o a b l f b r k a f g h
w y d g l b r s a w h f o ` g e f g | _ a f  l g e b g j ` f g r h _ k p
b r s  « ª  g r h  Ÿ  « ª  o g ` ` k t

f l f e a d f ` f k k z i d f r
m w _ r f f h g o e b a b o g ` k f o a b w r y w e f g o d f ` f | f r a
w y g k a e _ o a _ e f
¡
f t s t a d f w n f r Ž ` f k o g o d f ¤
y w e b | n e w l b r s n f e y w e | g r o f z b a b k g k h b
o _ ` a
408 Tecnologías Grid, Clusters y Plataformas Distribuidas
0
100
200
300
400
500
600
700
800
900
1000
0 100 200 300 400 500 600 700 800
ms
Number of clients/s
original boa
boa-dsections with 2 threads
boa-dsections with 4 threads
boa-omp with 2 threads
boa-omp with 4 threads
boa-pthreads with 2 threads
boa-pthreads with 4 threads
;
C
: 8
1

B
1
A
2 ? C
A
1 3
;
@ 1  @
A
 4
b r
u
n f r ^ v g k b a b k b r ¢ ˜ ™ š › œ  £ j f o g _ k f m w _
r f f h a w _ k f w | n


` w o x k t ~ f a d b r x g n w k k b p
j ` f i g m a w k w ` l f a d b k n e w j ` f | i w _ ` h j f g ` ` w i p
b r s h m r g | b o g ` ` m r g | f h o e b a b o g ` k f o a b w r k
¡
f t s t
o g o d f


` w o x ‹ b  ¤ t ~ b a d a d f k f x b r h w y o e b a b o g ` k f o p
a b w r k a d f k g | f o w h f n e w a f o a b r s g k b r s ` f f r a e m
w y g o w | n ` f  k a e _ o a _ e f i w _ ` h i w e x y w e g ` ` a d f
f r a e b f k i d b ` f f g o d w r f i b ` ` k a b ` ` d g l f b a k w i r
` w o x t
‘ d f ¢ ˜ ™ š › œ  l f e k b w r e f — _ b e f h k f l f e g ` | w h b p
Ž o g a b w r k a w a d f w e b s b r g ` k w _ e o f o w h f t · w h f y w e
a d f o w r k _ | f e a d e f g h k i g k h f l f ` w n f h t “ r h z g ` p
a d w _ s d b a i g k r w a l f e m h b
o _ ` a j f o g _ k f a d f e f
i g k w r ` m w r f a m n f w y a g k x a w o w r k _ | f
¡
b t f t e f p
— _ f k a k ¤ b a e f — _ b e f h k w | f f  n f e a b k f a w d g r h ` f
g o o f k k a w a d f — _ f _ f o w e e f o a ` m g r h f
o b f r a ` m t
²
w | f w a d f e o d g r s f k i f e f e f — _ b e f h a w a d f o w h f
w y a d f n e w h _ o f e a d e f g h b r o ` _ h b r s ” o e f g a b r s a d f
o w r k _ | f e k z b r b a b g ` b q b r s a d f ` w o x k z g r h e f | w l p
b r s a d f e f — _ f k a n e w o f k k b r s ` w w n t “ ` k w z | _ a f 
` w o x k i f e f g h h f h a w n e w a f o a a d f g o o f k k a w a d f
š › œ  ¨ g r h   « ª  ›  — _ f _ f k t ‘ d f w l f e g ` ` f – w e a
i g k | w h f e g a f t
‘ d f
u
n f r ^ v l f e k b w r h b h r w a e f — _ b e f g k
| g r m o d g r s f k b r a d f k w _ e o f o w h f o w | n g e f g k
a d f ¢ ˜ ™ š › œ  l f e k b w r t } _ a z b a r f f h f h g s e f g a
h f g ` w y g a a f r a b w r a w | g b r a g b r a d f o w e e f o a r f k k
w y a d f £ ž Ÿ    › i w e x k d g e f
¡
b t f t a d g a g ` ` a d e
f g h k
f  f o _ a f h g ` ` a d f b a f e g a b w r k ¤ t ‘ d b k e f k a e b o a b w r
g ` k w o g _ k f h a d f e f h _ o a b w r b r n f e y w e | g r o f t { r
a d f w a d f e l f e k b w r k z a d f a d e f g h k o w _ ` h f  f o _ a f
g a g k x g k k w w r g k b a i g k e f g h m z w e f l f r e _ r
b r n g e g ` ` f ` e f — _ f k a n e w o f k k b r s g r h g o o f n a b r s
r f i o w r r f o a b w r k t { r a d f
u
n f r ^ v l f e k b w r g ` `
a d e f g h k | _ k a i g b a _ r a b ` g ` ` a d f e f — _ f k a k z a d g a
i f e f g l g b ` g j ` f i d f r a d f a e g l f e k g ` k a g e a f h z g e f
n e w o f k k f h f l f r b y a d f e f g e f r f i e f — _ f k a k a w n e w p
o f k k t ‘ d b k k _ s s f k a k a d g a o _ e e f r a i w e x k d g e f k
g e f r w a i f ` ` k _ b a f h y w e d g r h ` b r s b e e f s _ ` g e n g e p
g ` ` f ` b k | t
} _ a j w a d a d f ¢ ˜ ™ š › œ  l f e k b w r g r h a d f
u
n f r ^ v l f e k b w r i f e f f g k b f e a w h f l f ` w n j f p
o g _ k f a d f w e b s b r g ` l f e k b w r d g h b r a f s e g a f h g
o w | n ` f  o w h f a d g a f r g j ` f h e f — _ f k a o w r o _ e p
e f r o m t
u
a d f e i b k f z a d f n e w s e g | | b r s f – w e a
i w _ ` h d g l f j f f r s e f g a f e t
u
r a d f w a d f e d g r h z
a d f  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ l f e k b w r i g k k b | n ` f e g k
a d f n e w s e g | | f e h b h r w a r f f h a w o w h f a d f | g r p
g s f | f r a w y a d f š › œ  ¨ a g k x k t  l f r y e w | g k b | p
n ` f e l f e k b w r w y a d f k f e b g ` l f e k b w r a d f n e w s e g | p
| b r s f – w e a i b a d  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ i w _ ` h d g l f
j f f r | b r w e t
 ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ g ` k w g ` ` w i a w f g k b ` m | b 
h b – f e f r a x b r h k w y n g e g ` ` f ` a g k x k t ~ d b ` f a d f
XVI Jornadas de Paralelismo, JP '2005 409
¢ ˜ ™ š › œ  £ o w h f i w _ ` h j f o g | f | w e f g r h | w e f
o w | n ` f  b y b a d g h a w h f g ` i b a d h b – f e f r a x b r h k
w y n g e g ` ` f ` a g k x k a d f  ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ o w | n ` f  p
b a m i w _ ` h e f | g b r o w r k a g r a t

„
ƒ
]
¯
† Y ‡ „
ƒ
Y
{ r a d b k n g n f e z i f d g l f f  n ` w e f h a d f _ k f w y
u
n f r ^ v a w n g e g ` ` f ` b q f g i f j k f e l f e t ~ f d g l f
k d w i r d w i z g h h b r s g y f i h b e f o a b l f k z a d f e f p
— _ f k a n e w o f k k b r s ` w w n w y a d f i f j k f e l f e o g r
j f n g e g ` ` f ` b q f h t } _ a a d b k k b | n ` f l f e k b w r h b h
r w a n f e y w e | f
o b f r a ` m t ~ f _ k f h a d f n e w n w k f h
 ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ a w b | n ` f | f r a g k b | n ` f e n g e p
g ` ` f ` i f j k f e l f e
¡
b t f t i b a d w _ a g n n ` b o g a b w r ` f l f `
a g k x | g r g s f | f r a ¤ t  l g ` _ g a b w r k d w i f h a d g a
a d b k l f e k b w r d g h g n f e y w e | g r o f z b r a d e w _ s d p
n _ a g r h g l f e g s f e f k n w r k f a b | f z g k s w w h g k a d f
n f e y w e | g r o f w j a g b r f h j m a d f k f e l f e h f l f ` w n f h
i b a d ¢ ˜ ™ š › œ  £ t } _ a b r a d f ¢ ˜ ™ š › œ  l f e k b w r a d f
n e w s e g | | f e r f f h f h a w h f l f ` w n g k n f o b Ž o a g k x
| g r g s f | f r a y w e a d f g n n ` b o g a b w r i d f e f g k a d f
 ¨ Ÿ œ © ž ª £ › ª ˜ ž « Ÿ £ l f e k b w r k b | n ` b Ž f h a d f n e w p
s e g | | b r s t
­ ®
®
[
® ƒ
]
®
Y
‹ Œ   t “ k f r ¥ w z • t · w e j f e g z  t  _ a b  e e f q z
^ t “ t

g l g e e w z
u
t v ` g a g z g r h  t µ t  g n g a g t
u
n a b | b q g a b w r a f o d r b — _ f k y w e b e e f s _ ` g e g r h
n w b r a f e p j g k f h n e w s e g | k t { r  š « ª › ›  ž Ÿ   £ «

˜ ™ ›   ˜ ™   š «  ž ª š « « Ÿ

› š › Ÿ ª › « Ÿ  œ š œ  
 › 
 ž £ ˜ š ž   ˜ ›  œ Ÿ   › ˜  « š    œ £ ›   š « 
ª › £ £ ž Ÿ      
  
z n g s f k Œ Œ c Œ

z • f j e _ g e m
 € € ¸ t
‹    g b e w } g ` g e a z “ ` f ¥ g r h e w § _ e g r z ^ g e o
 w r q  ` f q z  g l b f e ^ g e a w e f ` ` z  h _ g e h
“ m s _ g h  z g r h  f k  k µ g j g e a g t

g r w k | f e p
o _ e b _ | ” g e f k f g e o d o w | n b ` f e y w e w n f r | n t
{ r  š « ª › ›  ž Ÿ   £ «

˜ ™ ›   š « ¢ › œ Ÿ  « š  £ ™ « ¢
« Ÿ  ¢ › Ÿ   
  
z
u
o a w j f e  € € ¸ t
‹

 v t } g e y w e h g r h ^ t · e w l f ` ` g t  f r f e g a b r s
e f n e f k f r a g a b l f i f j i w e x ` w g h k y w e r f a i w e x
g r h k f e l f e n f e y w e | g r o f f l g ` _ g a b w r t { r
 › œ £ 
š œ © › Ÿ ˜ œ Ÿ   «  ›  ž Ÿ   «

« © ¢  ˜ › š

¨ £ ˜ › © £ z n g s f k Œ Œ c Œ ¦ € z Œ ¶ t
‹ ¸  · t } e f k d f g e k g r h v t µ _ w r s t · w | n g e b k w r
w y w n f r | n g r h n a d e f g h k i b a d b r g o w g k a g `
w o f g r o b e o _ ` g a b w r | w h f ` o w h f t { r  « š  
£ ™ « ¢ « Ÿ  ¢ › Ÿ    ¢ ¢  ž ª œ ˜ ž « Ÿ £ œ Ÿ   « «  £ z
 _ ` m  € € € t
‹   _ s f r § f h _ z
²
a f n d g r f  b g ` ` f z g r h
· ` g _ h f ‘ b | k b a t · w | n g e b k w r w y w n f r | n
g r h o ` g k k b o g ` | _ ` a b p a d e f g h b r s n g e g ` ` f ` b q g p
a b w r y w e e f s _ ` g e g r h b e e f s _ ` g e g ` s w e b a d | k t
{ r

«

˜  œ š ›  Ÿ   ž Ÿ › › š ž Ÿ    ¢ ¢  ž ›  ˜ «  › ˜ 
 « š  ž Ÿ   œ Ÿ   œ š œ   › 

 ž £ ˜ š ž   ˜ ›  « © 
¢  ˜ ž Ÿ  

  

z n g s f k

c ¦ € z  € € € t
‹ ¦  µ g e e m § w w ` b a a ` f g r h  w r

f ` k w r t } w g i f j p
k f e l f e k b a f t d a a n ”   i i i t j w g t w e s t
‹ ´  } w j ³ _ d r z v g _ ` v f a f e k f r z g r h  g | w r r
u 
‘ w w ` f t
u
n f r | n l f e k _ k a d e f g h b r s b r
o  o   t « Ÿ ª  š š › Ÿ ª ¨   š œ ª ˜ ž ª › œ Ÿ    
¢ › š ž › Ÿ ª › z Œ  ” Œ Œ ¦ c Œ Œ ´ ¦ z  € € € t
‹ ¶  § t  t µ f f g r h ‘ t  t § w i r g e t ‘ d f g n p
n ` b o g a b w r w y n w k b  a d e f g h k g r h w n f r | n
a w a d f _ t k t r e o r f _ a e w r x b r f a b o k o w h f
n g e o k t { r  t  b s f r | g r r g r h ^ t  t  w k k z
f h b a w e k z  š « ª › ›  ž Ÿ   £ «

˜ ™ ›  Ÿ ˜ › š Ÿ œ ˜ ž « Ÿ œ 
 « š  £ ™ « ¢ « Ÿ  ¢ › Ÿ    ¢ ¢  ž ª œ ˜ ž « Ÿ £ œ Ÿ 
 « «  £ 
 
 z l w ` _ | f  Œ € ¸ w y › ª ˜  š ›  « ˜ › £
ž Ÿ « © ¢  ˜ › š

ª ž › Ÿ ª › z n g s f k ¦ c ¶

z  _ ` m
 € € Œ t
‹  § t ^ w k j f e s f e g r h ‘ t  b r t d a a n f e y c g a w w `
y w e | f g k _ e b r s i f j k f e l f e n f e y w e | g r o f t { r
! ž š £ ˜  « š  £ ™ « ¢ « Ÿ  Ÿ ˜ › š Ÿ › ˜

› š  › š  › š 

« š © œ Ÿ ª › z n g s f k c ¦ ´ z  _ r f Œ ¶ t
‹ Œ € 
u
n f r ^ v
u
e s g r b q g a b w r t
u
n f r | n
y w e a e g r g n n ` b o g a b w r b r a f e y g o f z l t  t € t
   " « ¢ › Ÿ © ¢ " « š   z  _ r f  € € € t
‹ Œ Œ 
²
t
²
d g d z  t g g j z v t v f a f e k f r z g r h
 t ‘ d e w w n t • ` f  b j ` f o w r a e w ` k a e _ o a _ e f k y w e
n g e g ` ` f ` ` b k | b r w n f r | n t { r  £ ˜   š « ¢ › œ Ÿ
 « š  £ ™ « ¢ « Ÿ  ¢ › Ÿ   z
²
f n a f | j f e Πt
410 Tecnologías Grid, Clusters y Plataformas Distribuidas
OpenMP para clusters *
Antonio J. Dorta and Francisco de Sande José M. Badı́a and Enrique S. Quintana
Dep. de Estadı́stica, I.O. y Computación Dep. de Ingenierı́a y Ciencia de Computadores
Universidad de La Laguna Universidad Jaume I
38271–La Laguna 12.071–Castellón
{ajdorta,fsande}@ull.es {badia,quintana}@icc.uji.es
27 de mayo de 2005
Resumen
(llc) es un lenguaje que hemos diseñado pa-
ra extender OpenMP a sistemas de memo-
ria distribuida. Presentamos el trabajo que se
está realizando en la implementación de un
compilador que traduce código llc y que gene-
ra código para arquitecturas de memoria dis-
tribuida. Nuestra aproximación genera códi-
go para las comunicaciones utilizando directa-
mente MPI. Se presentan resultados computa-
cionales de dos aplicaciones diferentes para un
cluster de PCs. Los resultados reflejan un ren-
dimiento similar para la versión compilada con
llc y una implementación MPI ad-hoc, inclu-
so para aplicaciones con paralelismo de grano
fino.
Keywords
MPI, OpenMP, computación en clusters,
memoria distribuida, compilador de OpenMP
1. Introducción
La ausencia de lenguajes paralelos de al-
to nivel y de propósito general es uno de los
mayores inconvenientes que limitan la expan-
sión de la computación de altas prestaciones
(CAP). Hay una clara separación entre los
usuarios que precisan las técnicas de la CAP y
*
Este trabajo ha sido financiado parcialmente por
el proyecto PI2003/113 del gobierno de Canarias, y
también por los proyectos EC (FEDER) y MCyT
(Plan Nacional de I+D+I, TIC2002-04498-C05-05 y
TIC2002-04400-C03-03).
los expertos que diseñan y desarrollan los len-
guajes. En general los usuarios no poseen los
conocimientos requeridos para explotar las he-
rramientas necesarias para desarrollar aplica-
ciones paralelas. Cualquier esfuerzo para dis-
minuir esta separación entre usuarios y herra-
mientas desarrollando lenguajes de mayor ni-
vel y más fáciles de usar será positivo.
MPI [7] es hoy en dı́a la herramienta más
utilizada para desarrollar aplicaciones para-
lelas debido a su portabilidad (está disponi-
ble para memoria compartida y distribuida) y
su alto rendimiento. Como alternativa a MPI,
OpenMP [10] ha surgido en los últimos años
como un estándar industrial para el desarrollo
de aplicaciones en sistemas de memoria com-
partida. El API de OpenMP está basado en
un pequeño conjunto de directivas de compi-
lación, junto con una librerı́a de rutinas y unas
variables de entorno.
Uno de los mayores inconvenientes de usar
MPI es que el desarrollo de aplicaciones para-
lelas consume gran cantidad de tiempo debi-
do a que el código secuencial de partida pre-
cisa de modificaciones sustanciales. En otras
palabras, paralelizar una aplicación secuencial
usando MPI requiere un considerable esfuerzo
y experiencia. En este sentido se suele afirmar
que MPI representa el lenguaje ensamblador
de la computación paralela: es posible obtener
un gran rendimiento pero a costa de un gran
esfuerzo en desarrollo.
Por otra parte, la rápida expansión de
OpenMP se debe fundamentalmente a su sim-
plicidad. Una primera aproximación parale-
1
la se puede construir fácilmente partiendo de
un código secuencial sin necesidad de realizar
cambios significativos. Sin embargo, también
es cierto que obtener un buen rendimiento de
un programa OpenMP requiere un esfuerzo es-
pecializado en tareas de sintonización.
La creciente popularidad de los clusters de
PCs, justificada por su mejor relación precio/-
rendimiento, está en el origen de los recientes
avances en la traducción de códigos OpenMP
a arquitecturas de memoria distribuida (MD),
aceptando una pequeña pérdida en el rendi-
miento de las aplicaciones. La falta de porta-
bilidad de OpenMP al mundo de MD es posi-
blemente su mayor inconveniente. En el pasa-
do más inmediato se han realizado diferentes
aproximaciones a este problema. La mayorı́a
de desarrollos para extender OpenMP a entor-
nos de MD emplean sistemas software de me-
moria compartida distribuida (SDSM) véase
por ejemplo [8, 11, 5].
También hay un segundo grupo de aproxi-
maciones que no se sustentan en la coheren-
cia de memoria suministrada por un SDSM.
En este segundo grupo podemos destacar los
trabajos de Huang y otros [6], que basan la
estrategia de traducción en el uso de Global
Arrays, o los de Yonezawa y otros [13], que
utilizan un descriptor de secciones de vector
al que denominan quad, para implementar la
traducción.
En este trabajo presentamos el lenguaje llc,
que se ha diseñado para extender OpenMP a
sistemas de MD, y llCoMP, el compilador de
llc, que ha sido construido sobre MPI. Nues-
tra aproximación consiste en generar código
para comunicaciones directamente sobre MPI
y, por tanto, tampoco depende de una capa
software que resuelva la coherencia de memo-
ria compartida. A través del uso de dos códi-
gos de ejemplo, mostramos los resultados com-
putacionales obtenidos usando la implementa-
ción preliminar de los nuevos constructos que
han sido incorporados al lenguaje, con el fin
de contemplar los patrones de acceso irregular
a memoria.
El resto del artı́culo está organizado como
sigue: En la Sección 2 presentamos el modelo
computacional en el que se basa nuestra estra-
tegia. Seguidamente discutimos algunos deta-
lles de la implementación del compilador de
llc en la Sección 3. Los casos de estudio y la
evaluación experimental de la implementación
preliminar de los nuevos constructos son estu-
diados en la Sección 4. La Sección 5 concluye
el trabajo con la presentación de conclusiones
y trabajos futuros.
2. El modelo computacional de llc
El compilador llCoMP es un traductor de
fuente a fuente implementado sobre MPI. El
compilador traduce código C anotado con di-
rectivas llc a código C con llamadas explı́ci-
tas a rutinas MPI. El resultado es compilado
usando el compilador nativo y enlazado con
la librerı́a MPI. Siempre que ello es posible,
los pragmas de llc son compatibles con sus
contrapartidas en OpenMP, de modo que sólo
se requieren pequeñas modificaciones sobre un
mismo código fuente para obtener un ejecuta-
ble secuencial o una versión paralela que utilice
MPI u OpenMP.
El lenguaje llc sigue el modelo computacio-
nal OTOSP (One Thread is One Set of Pro-
cessors). Aunque el lector puede consultar [2]
para obtener información más detallada, co-
mentaremos brevemente algunas caracterı́sti-
cas del modelo necesarias para comprender la
semántica del lenguaje y el comportamiento
del compilador.
El modelo OTOSP es un modelo computa-
cional de MD en el que todas las direcciones de
memoria son privadas a cada procesador. Un
concepto clave del modelo es el de conjunto
de procesadores. Al comienzo de la ejecución
de un programa (y también en las partes se-
cuenciales del mismo), todos los procesadores
disponibles en el sistema pertenecen a un úni-
co conjunto. El conjunto de procesadores sigue
un modelo de computación fork-join: el con-
junto se divide (fork) en subconjuntos como
consecuencia de la ejecución de un constructo
paralelo, y los subconjuntos se unen de nue-
vo cuando finaliza la ejecución del constructo.
En cualquier punto del código, todos los pro-
cesadores pertenecientes a un mismo conjun-
to replican la misma computación, es decir, se
412 Tecnologías Grid, Clusters y Plataformas Distribuidas
comportan como un único thread de ejecución.
Cuando diferentes (sub-)conjuntos de pro-
cesadores se unen en un mismo conjunto, al
finalizar la ejecución de un constructo parale-
lo, los procesadores socios han de intercambiar
los contenidos de las áreas de memoria que han
modificado dentro del constructo paralelo. La
replicación del cómputo que realizan los pro-
cesadores de un mismo conjunto, junto con las
comunicaciones de las zonas de memoria modi-
ficadas al final del constructo paralelo, son los
mecanismos usados en OTOSP para garanti-
zar una imagen coherente de la memoria.
Aunque hay diversos constructos paralelos
implementados en el lenguaje, en este trabajo
centraremos nuestra atención en el constructo
parallel for.
3. El compilador llCoMP
La simplicidad del modelo OTOSP facilita
en gran medida su implementación en sistemas
de MD. En esta sección se expone la traduc-
ción de bucles paralelos que realiza llCoMP.
Para cada uno de los códigos contenidos en el
NAS Parallel Benchmark [1] (columnas de la
tabla) en el Cuadro 1 se indica el número de
apariciones de la correspondiente directiva (fi-
las de la tabla).
A continuación mostraremos que a cada una
de estas directivas se le puede asignar un senti-
do semántico coherente en el modelo OTOSP,
y también que puede ser implementada usando
MPI en un sistema de MD:
parallel. Al principio de una ejecución,
todos los procesadores están ejecutando
en paralelo, de modo que la directiva
parallel no requiere traducción.
parallel for. En cualquier código, los
bucles son la mayor fuente de paralelis-
mo. Por este motivo las directivas for y
parallel for son las más comunes en un
programa OpenMP (como refleja la Ta-
bla 1). La implementación de estos bucles
será comentada en detalle en los siguien-
tes párrafos.
master. Una porción de código que sólo
debe ser ejecutado por el thread master
en un conjunto OpenMP de threads pue-
de ser fácilmente implementado en MPI
usando el identificador de cada procesa-
dor.
single. De modo similar se logra que
una parte del código sea ejecutada por un
solo procesador usando directamente su
identificador. No obstante, en la mayorı́a
de los casos la traducción de la directiva
single a MD puede ser ignorada.
critical. Esta directiva se usa para con-
trolar el acceso concurrente a zonas es-
pecı́ficas de la memoria. En el modelo
OTOSP cada procesador posee su propio
espacio de direcciones, de modo que esta
directiva puede ser ignorada.
barrier. Esta directiva se implementa di-
rectamente usando la rutina MPI Barrier.
flush. Esta directiva establece un punto
de sincronización en el cual la memoria
deberı́a ser consistente para todos los pro-
cesadores. Esta propiedad puede lograr-
se usando los mismos mecanismos que se
usan en el caso de la directiva parallel
for.
threadprivate. Esta directiva no requie-
re traducción especı́fica, ya que en el mo-
delo OTOSP toda la memoria es privada
.
Las cláusulas de atributos de datos usadas
en conjunción con algunas directivas OpenMP
también pueden ser implementadas en el mo-
delo OTOSP. Especial atención requiere el tra-
tamiento de las variables compartidas (en el
sentido de OpenMP). Concretamente, cual-
quier variable compartida que aparezca en el
lado izquierdo de una sentencia de asignación
que se encuentre en el ámbito de un parallel
for debe ser anotada con una cláusula llc
result o nc result. Ambas cláusulas se em-
plean para notificar al compilador la región de
memoria que es potencialmente susceptible de
ser modificada por el grupo de procesadores
que ejecuta el bucle paralelo. Las sintaxis de
cada directiva es similar en ambos casos: el
primer parámetro es un puntero a la región
XVI Jornadas de Paralelismo, JP '2005 413
BT CG EP FT IS LU MG SP
parallel 2 2 1 2 2 3 5 2
for 54 21 1 6 1 29 11 70
parallel for 3 1
master 2 2 1 10 4 2 1 2
single 12 5 2 10
critical 1 1 1 1 1
barrier 1 2 3 1 3
flush 6
threadprivate 1
Cuadro 1: Directivas en los códigos del NAS Parallel Benchmark.
de memoria (addr), el segundo es el tamaño
de dicha región (size), y el tercer parámetro,
sólo presente en nc result, es el identificador
de la variable ligada a esa región de memo-
ria. La directiva result se utiliza cuando todas
las direcciones de memoria en el rango [addr,
addr+size] son (potencialmente) modificadas
por el grupo de procesadores. Éste es el caso,
por ejemplo, cuando se modifican posiciones
adyacentes de un vector. Si existen accesos de
escritura a posiciones no contiguas de memoria
dentro del bucle paralelo, estos accesos deben
ser anotados con la cláusula nc result.
llCoMP utiliza Descriptores de Memoria
(DM) para garantizar la consistencia de me-
moria al final de la ejecución de un constructo
paralelo. Los DM son estructuras de datos ba-
sadas en colas, utilizados para gestionar la in-
formación necesaria sobre las regiones de me-
moria modificadas por el conjunto de procesa-
dores. Antes de su comunicación a otros con-
juntos de procesadores, las regiones de memo-
ria son compactadas para minimizar el coste
asociado a las comunicaciones.
En [2] se presentaron varios ejemplos de
códigos que utilizan la directiva result. En
este trabajo nos centraremos en la implemen-
tación de patrones de acceso a memora no con-
tiguos, la caracterı́stica más reciente que he-
mos incorporado a llCoMP. En particular, con-
sideremos el código del Listado 1, que muestra
la paralelización usando llc del bucle princi-
pal de la operación producto matriz dispersa-
vector y = y + αAx, donde x e y son vectores
y A es una matriz dispersa. Esta operación
2 # p r a g m a omp p a r a l l e l for p r i v a t e ( ptr , temp ,
k , j )
3 for ( i = 0 ; i < Blks −
>s i z e 1 ; i++) {
4 p t r = Blks −
>p t r [ i ] ;
5 t e m p = 0 . 0 ;
6 k = i n d e x 1 _ c o o r d i n a t e ( p t r ) ; // 1 s t
element in i−t h row
7 for ( j =0; j<
e l e m e n t s _ i n _ v e c t o r _ c o o r d i n a t e ( Blks ,
i ) ; j++) {
8 t e m p += v a l u e _ c o o r d i n a t e ( p t r ) ∗
9 x [ i n d e x 2 _ c o o r d i n a t e ( p t r ) ∗ i n c x ] ;
10 i n c _ c o o r d i n a t e ( p t r ) ;
11 }
12 #p r a g m a l l c n c _ r e s u l t (&y [ k∗ i n c y ] , 1 , y )
13 y [ k∗ i n c y ] += a l p h a ∗ t e m p ;
14 }
Listado 1: Una paralelización de la operación
usmv.
es conocida como usmv en el nivel-2 de BLAS
disperso. La directiva parallel for de la lı́nea
1 indica que el conjunto de procesadores que
ejecuta el bucle de la lı́nea 2 ha de dividirse
para ejecutar el bucle. La directiva nc result
especı́fica de llc de la lı́nea 11 indica al com-
pilador que el valor del elemento y[k*incy] ha
de ser “anotado”.
4. Resultados Computacionales
Los experimentos que presentamos en esta
sección fueron desarrollados en un cluster for-
mado por 32 procesadores Intel Pentium Xeon
con una frecuencia de 2.4 GHz, con 1 GBy-
te de memoria RAM cada uno, y conectados
por una red Myrinet. El sistema operativo del
414 Tecnologías Grid, Clusters y Plataformas Distribuidas
ad hoc MPI llCoMP
30000 40000 30000 40000
#Proc. 1 % 2 % 1 % 2 % 1 % 2 % 1 % 2 %
SEC 11.09 21.55 26.67 45.16 11.09 21.55 26.67 45.16
2 5.85 11.99 11.59 30.11 8.24 15.15 21.70 34.08
4 3.64 6.65 8.26 16.72 4.85 8.18 10.34 21.34
8 2.23 3.33 4.44 11.39 2.93 4.23 6.42 10.57
16 1.62 2.13 2.86 6.76 1.86 2.68 3.48 6.57
24 1.45 1.82 2.43 6.15 1.80 2.32 3.29 6.23
32 1.27 1.55 2.00 5.25 1.94 2.40 3.02 4.35
Cuadro 2: Tiempo de ejecución (segundos) para las versiones MPI ad hoc y llCoMP del código
usmv. Se utilizaron tamaños de problema 30000 y 40000 con grados de dispersión del 1 % y 2 %.
cluster es Debian Sarge Testing Linux y se ha
utilizado la implementación de mpich [4] ba-
sada en la librerı́a de comunicación propietaria
GM-1.6.3.
Para evaluar el rendimiento de la traduc-
ción de llCoMP hemos utilizado dos códigos: el
producto de matriz dispersa-vector usmv y un
código de simulación de Dinámica Molecular
(md) [12]. Estos benchmarks fueron seleccio-
nados porque contienen accesos no contiguos
a memoria, y también porque son códigos sim-
ples representativos de un conjunto mayor de
algoritmos. Además, la operación usmv es una
operación muy común en álgebra lineal disper-
sa, extremadamente útil en un vasto conjunto
de aplicaciones entre las que destacan el diseño
VLSI, la mecánica estructural, la ingenierı́a, la
computación quı́mica o el electromagnetismo.
Usando MPI y llCoMP hemos desarrollado
dos versiones paralelas del código usmv. Con-
sideremos en primer lugar la paralelización
usando MPI. Por simplicidad, asumiremos que
ambos vectores x e y están replicados. Con
la matriz A distribuida por filas, el producto
matriz-vector se implementa como una serie
de productos internos que pueden realizarse en
paralelo. Se requiere una comunicación de ti-
po todos-a-todos en la etapa final para replicar
el vector y resultante en todos los nodos. Por
otra parte, utilizando llc para implementar
el producto se ha paralelizado el bucle exter-
no, de modo que cada thread se encarga de un
grupo de productos internos (ver el Listado 1).
Puesto que todas los procesadores comparten
los vectores x e y, en este caso no es necesa-
rio realizar una comunicación adicional de los
resultados parciales.
El Cuadro 2 compara el tiempo de ejecución
acumulado de 100 ejecuciones para el código
usmv usando la implementación MPI ad hoc y
la traducción producida por llCoMP. Las ejecu-
ciones corresponden a matrices dispersas alea-
torias de dimensiones 30000, 40000 y factores
de dispersión del 1 % y 2 %.
El paralelismo de grano fino presente en el
código usmv y la escasa carga computacional
inherente a esta operación son la causa de la
limitada aceleración que refleja el experimen-
to. Como cabrı́a esperar, algoritmos de grano
grueso son el mejor escenario para lograr al-
tos rendimientos para las traducciones produ-
cidas por llCoMP. No obstante, si comparamos
los resultados obtenidos con un programa MPI
ad hoc con los producidos por la versión llc,
podemos esperar que en muchas situaciones el
coste añadido será compensado por el conside-
rable menor esfuerzo invertido en el desarrollo
del código paralelo.
El código fuente para el código md escrito en
OpenMP puede ser obtenido desde el OpenMP
Source Code Repository [9, 3]; la traducción de
este código usando llc es muy simple. Con es-
XVI Jornadas de Paralelismo, JP '2005 415
Figura 1: Aceleraciones para el código MD con MPI, llCoMP (result y nc result).
te experimento nuestra intención es evaluar la
sobrecarga introducida por llCoMP en la ges-
tión de patrones de accesos no regulares. El
código md muestra un patrón de acceso re-
gular, pero puesto que la cláusula nc result
es un caso general de result, hemos imple-
mentado el código usando ambas cláusulas. La
Figura 1 muestra la aceleración obtenida por
el código md con tres implementaciones dis-
tintas: una implementación MPI ad hoc y dos
implementaciones diferentes de llc, una usan-
do result y otra con nc result. Se observa
un comportamiento de la aceleración casi li-
neal para todas las implementaciones. Para es-
te código en particular, no se aprecian diferen-
cias relevantes al usar cláusulas de patrones de
accesos a memoria regulares y no regulares.
5. Conclusiones y trabajo futuro
Creemos que respetar la semántica secuen-
cial de los programas es una clave fundamental
para conseguir el objetivo de reducir la difi-
cultad del desarrollo de aplicaciones paralelas.
Indudablemente, la extensión del modelo de
programación de OpenMP al caso de MD es
una meta deseable. Actualmente la tecnologı́a
y las ideas no están lo suficientemente madu-
ras como para considerar que existe un cami-
no claro hacia la solución de este problema.
Según esta interpretación, nuestra aproxima-
ción no pretende competir con el trabajo de
otros autores. En este trabajo hemos mostra-
do que un compilador que funciona bajo las
premisas del modelo de computación OTOSP
y usa generación directa de código MPI para
las comunicaciones, puede producir resultados
aceptables, incluso en el caso de algoritmos pa-
ralelos con paralelismo de grano fino.
El trabajo que ya está en fase de realización
en el contexto de este proyecto incluye los si-
guientes aspectos:
Descargar al usuario final de la respon-
sabilidad de la especificación de aquellas
regiones de memoria a ser comunicadas
(usando la cláusula result).
Explorar las fuentes potenciales de mejora
del prototipo del compilador.
Recopilar aplicaciones OpenMP suscepti-
bles de ser implementadas en llc.
Referencias
[1] D. H. Bailey et al. The NAS parallel
benchmarks. Technical Report RNR-
416 Tecnologías Grid, Clusters y Plataformas Distribuidas
94-007, NASA Ames Research Center,
Moffett Field, CA, USA, October 1994.
Electronically available at
http://www.nas.nasa.gov/News/Techreports/
1994/PDF/RNR-94-007.pdf.
[2] Antonio J. Dorta, Jesús A. González, Ca-
siano Rodrı́guez, and Francisco de Sande.
llc: A parallel skeletal language. Para-
llel Processing Letters, 13(3):437–448, sep
2003.
[3] Antonio J. Dorta, Arturo González-
Escribano, Casiano Rodrı́guez, and Fran-
cisco de Sande. The OpenMP source co-
de repository. In Proc. of the 13th Eu-
romicro Conference on Parallel, Distribu-
ted and Network-based Processing (PDP
2005), pages 244–250, Lugano, Switzer-
land, Feb 2005.
[4] W. Gropp, E. Lusk, N. Doss, and A. Sk-
jellum. A high-performance, portable im-
plementation of the message passing in-
terface standard. Parallel Computing,
22(6):789–828, September 1996.
[5] Y. Charlie Hu, Honghui Lu, Alan L. Cox,
and Willy Zwaenepoel. OpenMP for
Networks of SMPs. Journal of Parallel
and Distributed Computing, 60(12):1512–
1530, 2000.
[6] Lei Huang, Barbara Chapman, and Zhen-
ying Liu. Towards a more efficient im-
plementation of openmp for clusters via
translation to global arrays. Techni-
cal Report UH-CS-04-05, Department of
Computer Science, Univeristy of Houston,
dec 2004. Electronically available at
http://www.cs.uh.edu/docs/preprint/
2004 11 15.pdf.
[7] Message Passing Interface Forum. MPI:
A Message-Passing Interface Standard.
University of Tennessee, Knoxville, TN,
June 1995. http://www.mpi-forum.org/.
[8] Seung-Jai Min, Ayon Basumallik, and
Rudolf Eigenmann. Supporting realistic
OpenMP applications on a commodity
cluster of workstations. In Proc. of of
WOMPAT 2003, Workshop on OpenMP
Applications and Tools, pages 170–179,
Toronto, Canada, Jun 2003. Electroni-
cally available at
http://www.ece.purdue.edu/~eigenman/
reports/wompat03.pdf.
[9] OmpSCR OpenMP Source Code Reposi-
tory.
http://www.pcg.ull.es/ompscr/ and
http://ompscr.sf.net.
[10] OpenMP Architecture Review Board.
OpenMP C/C++ Application Program
Interface, March 2002. Electronically
available at
http://www.openmp.org/specs/
mp-documents/cspec20.pdf.
[11] Mitsuhisa Sato, Hiroshi Harada, and
Atsushi Hasegawa. Cluster-enabled
OpenMP: An OpenMP compiler for the
SCASH software distributed shared me-
mory system. Scientific Programming,
Special Issue: OpenMP, 9(2-3):123–130,
2001.
[12] W. C. Swope, H. C. Andersen, P. H. Be-
rens, and K. R. Wilson. A computer si-
mulation method for the calculation of
equilibrium constants for the formation
of physical clusters of molecules: Appli-
cation to small water clusters. Journal of
Chemical Physics, 76:637–649, 1982.
[13] Naoki Yonezawa, Koichi Wada, and Ta-
kahiro Ogura. Quaver: OpenMP compiler
for clusters based on array section des-
criptor. In Proc. of the 23rd IASTED
International Multi-Conference Parallel
and Distributed Computing and Net-
works, pages 234–239, Innsbruck, Austria,
2005. IASTED /Acta Press. Electroni-
cally available at
http://www.actapress.com/
Abstract.aspx?paperId=6530.
XVI Jornadas de Paralelismo, JP '2005 417
Running BT Multi-Zone on non-shared memory machines with
OpenMP SDSM instead of MPI
David Ródenas, Xavier Martorell, Juan José Costa, Toni Cortes, Jesús Labarta
Universitat Politècnica de Catalunya
{drodenas,xavim,jcosta,toni,jesus}@ac.upc.edu
Abstract
In this paper we show how we can use an every-
thing-shared SDSM to achieve a similar perform-
ance on clusters using MPI with BT-MZ bench-
mark without to face extra complexity: work
distribution, data movement, and synchronization.
Multi-Zone Computational Applications involve
the solving of the application on collections of
loosely coupled discretization meshes allowing
the use of distributed memory more efficiently.
We have also improved the OpenMP environment
to achieve better results. Techniques applied
involves the runtime, compiler and, in some cases,
a bit collaboration of the programmer.
1. Introduction
Clusters or networks of workstations are becom-
ing one of the most widely used platforms to run
parallel applications. The reasons behind this
trend are mainly two: the cost of these systems is
quite affordable and the technology to build them
has reached a maturity point to make them stable
and easy enough to be exploited.
Hybrid models like the combination of the
MPI and OpenMP [14] paradigms are becoming
very popular. MPI [12] provides the support of
distributed memory programming, process com-
munication and synchronization. The OpenMP
[13] paradigm provides ease programming with
directives and takes advantage of shared memory.
MPI uses message passing and it does not
needs shared memory, but the programmer have
to face the complexity of managing parallelism at
application level: handling work distribution, data
movement and synchronization. It makes the
program more complex and more difficult to code
and debug. OpenMP is easier to use: you simply
write a serial application and add the parallel
directives incrementally. You can always run your
application in serial to test and debug. You don’t
need to think about nodes, processors, synchroni-
zations or other kind of machine dependant stuff.
But it cannot be used between non-shared memory
nodes.
Software Distributed Shared Memory runtime
system allow us to run OpenMP applications
across different nodes simulating shared memory
through mechanisms like page fault handling, but
unfortunately they do not provide real shared
memory. In order to improve performance many
tricks have to be done by the programmer ([1],
[8]). It makes the development of this kind of
applications as complex as the MPI ones.
Multi-Zone Computational Applications are
usually developed using MPI + OpenMP ([16]).
They consist of two main levels of parallelism:
coarse grain parallelization (inter-zone, loosely
coupled parallel computation, MPI part) and
parallelization within zones (intra-zone, high
coupled parallel computation, OpenMP part).
These applications can be written entirely in
OpenMP [2] using nested parallelism [4]: the
inter-zone parallelism is implemented by creating
groups of threads and by assigning one or more
zones to a thread group; intra-zone computation
open the nested parallelism in each group.
Our proposal is to analyze the performance of
these kinds of applications in a simple everything
shared SDSM without adding the complexity of
coherence relaxation and also without the com-
plexity to face of synchronizations and communi-
cations. We expect that the low communication
between inter-zone computations will allow us to
reach a similar performance than MPI versions.
2. Environment
Our research was run on a cluster of Intel Pentium
machines. We have used NanosDSM as the soft-
ware distributed shared memory. The NanosCom-
piler and NthLib runtime provides us an OpenMP
environment. We have executed the NAS-MZ 3.0
benchmarks for MPI and OpenMP multi-zone
version.
2.1. SDSM
NanosDSM [6] is an everything-shared SDSM,
meaning that its entire address space is shared. It
implements sequential consistency ensuring an
order between all the read/write transactions from
the nodes. It uses the mmap call to “generate”
memory at the remote nodes, and the mprotect call
and the pagefault handling mechanism to manage
the different pages used by the application.
A communication framework based in mes-
sage passing is used to communicate information
between the different nodes. This framework is
also available to the programmer: the re-
mote_queues. These allow extra performance
optimizations by directly passing messages be-
tween nodes.
NanosDSM consists of a library and a daemon
server. The application is linked with the library
and a server is started at each running node. The
application is run at the master node and
NanosDSM will connect automatically with the
slave nodes to provide the parallelism.
2.2. OpenMP
The Nanos OpenMP environment is based on
NanosCompiler [7] and the NthLib runtime li-
brary [11]. OpenMP uses the fork/join execution
model in which a program begins execution as a
single process or thread. This thread executes
sequentially until a PARALLEL construct is
found. At this time, the thread creates a team of
threads and it becomes its master thread. Work-
sharing constructs (DO, SECTIONS and
SINGLE) are provided to divide the execution of
the enclosed code region among the members of
the PARALLEL team. The NanosCompiler is a
source-to-source translator for Fortran77 based on
Parafrase-2 [14] that replaces OpenMP directives
by calls to the NthLib runtime. The NthLib run-
time is designed to provide an efficient support to
the OpenMP execution model on shared-memory
multiprocessors. The NthLib runtime has support
for nested OpenMP PARALLEL regions and we
had ported it to NanosDSM environment.
2.3. OpenMP Extensions
The Nanos OpenMP extensions to support multi-
level parallelization are based on the concept of
thread groups. A group of threads is composed of
a subset of the total number of threads available in
the team to run a parallel construct. To define
groups of threads, the NanosCompiler [7] supports
the GROUPS clause extension [3] to the
PARALLEL directive. See Algorithm 1.
C$OMP PARALLEL GROUPS(...)
Algorithm 1. Clause groups.
Different formats for the GROUPS clause ar-
gument are allowed. The current specification for
OpenMP includes the NUM_THREADS clause,
but this extension requires that the programmer
explicitly control the allocation of threads. The
NanosCompiler GROUPS clause is more modular
since the context is implicit in the OpenMP run-
time support and the code is valid in all possible
situations guaranteeing the exploit of data locality.
2.4. Benchmark’s platform
The platform used for running our experiments is
a cluster of 6 Intel Dual Pentium II at 266MHz,
128 Mb of RAM, and a Myrinet interconnection
network. When we start this research NanosDSM
didn’t had support to multithreading and only one
processor could be used for each node.
3. Application
We have used a representative benchmark of
multi-zone computational applications: BT-MZ.
This is a nested parallel multi-zone computational
application with different zone sizes. Two imple-
mentations are provided: one hybrid MPI with
OpenMP, and another one with nested OpenMP.
420 Tecnologías Grid, Clusters y Plataformas Distribuidas
3.1. NAS-MZ 3.0
BT-MZ is part of NAS-MZ 3.0 applications. The
purpose of the NAS-MZ is to capture the multiple
levels of parallelism inherent in this kind of appli-
cations. Multi-zone versions of NAS Parallel
Benchmarks [5] LU, BT, and SP were developed
by dividing the discretization mesh into a two-
dimensional tiling of three-dimensional zones.
Multi-zone versions are called BT-MZ, SP-MZ
and LU-MZ. The same kernel solvers from NAS
parallel benchmarks [5] are used in the single-
zone codes. Boundaries exchange takes places
after each time step.
The nested OpenMP version data exchange is
done in parallel by reading from and writing to the
original application data structures. There is no
need for using any special primitives such as MPI
communication routines. The implementation just
requires the addition of less than half a dozen
OpenMP directives in each application.
3.2. BT-MZ
We have focused our study on BT-MZ bench-
mark. Benchmark’s zones sizes grow with the
problem size. The overall mesh is partitioned such
that the sizes of the zones span a significant range.
This is accomplished by increasing sizes of suc-
cessive zones in a particular coordinate direction
in a roughly geometric fashion, as seen in Figure 1
largest zone involves a fifth of all computation
effort. This makes harder to balance the load and
also allows us to make more improvements. If we
use more than five nodes we will have unbalance
and total time should be the same than using five
nodes, except if we are able to split one zone
between two processors.
C$OMP PARALLEL DO PRIVATE(zone)
GROUPS(num_groups, who, howmany)
Algorithm 2. Clause groups used at NAS-MZ
The implementation uses the clause GROUPS
from NanosCompiler. GROUPS can use three
kinds of arguments: num_groups; num_groups
and weight for each group; and finally
num_groups, who, and how many. The first ver-
sion splits the number of threads equally across
available processors. The second assigns more or
less processors to each group depending the num-
ber of available processors. Three arguments call
specifies for each group which processor group
will execute each zone it and how many proces-
sors should be used. Of course this specification is
scaled to any number of processors. NAS-MZ
uses the three arguments version; see Algorithm 2.
For five processors you can find an example
of optimal values of zone, howmany and who in
Table 1.
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
Figure 1. The mesh of class A from BT-MZ
benchmark showing a horizontal cut
through mesh system.
Zone 1 2 3 4 5 6 7 8
Who 2 4 3 1 2 1 3 4
Howmany 1 1 1 1 1 1 1 1
Zone 9 10 11 12 13 14 15 16
Who 4 3 3 1 2 4 2 0
Howmany 1 1 1 1 1 1 1 1
Table 1. BT-MZ A groups assignations
3.3. Optimizations
We have classified the optimizations in two
groups: inter-zone optimizations and intra-zone
optimizations. Our objective is to provide a simple
environment to develop efficient parallel applica-
tions, for that reason most of the optimizations are
XVI Jornadas de Paralelismo, JP '2005 421
performed on the runtime and SDSM. We have
only done small changes on application code.
3.4. Traces
To analyze the application and environment be-
havior we have used traces. Those traces tells to
us which pages are faulted, times of execution of
different parts, and much more. In Figure 2 and
Figure 3 shows which memory regions are faulted.
Each row is one node, and each column is a block
of 16Mb of memory. If block is white there aren’t
any page faults, gray a few faults, black lots of
faults. Figure 4, Figure 5, and Figure 6 shows one
zone execution in time, each horizontal bar is one
processor; each block is the execution of one
parallel function. Time scale is the same in the
three figures; whole bar represents the total time
of one zone execution.
4. Inter-Zone optimization
Our main objective is to take profit of the low
communication between zones. This is the inter-
zone parallelization. Our optimizations can be
classified in three: work distribution, synchroniza-
tion, and data distribution.
4.1. Work Distribution
NanosDSM is an everything-shared SDSM, which
implies that at the first moment we are sharing all
memory. For this reason the first porting of
NthLib didn’t cared about of remote communica-
tion. Work distribution is based on spin-locks,
memory queues, and other structures that use
memory and idle-loops to feed work. Steps done
for each new thread are:
1. Dequeue a stack from the free stack queue at
target processor.
2. Master processor creates the stack activation
block.
3. Master registers at target processor queue the
created stack.
4. Target reads the queue and gets the stack.
5. Target processor changes the context to the new
stack and starts its executions.
6. When it finishes, the target processor reads the
dependence counter from master stack and dec-
rements it.
7. If dependence counter is zero the target proces-
sor enqueues the master stack at master.
8. Target enqueues the used stack into its own free
stacks queue.
Each step requires a minimum of one page
Figure 2. Memory faults map with without enhanced optimizations and zone 16 split.
Figure 3. Final optimized version memory faults map without zone 16 splitting.
422 Tecnologías Grid, Clusters y Plataformas Distribuidas
that is not present in current node. These page
faults can be seen on memory map shown in
Figure 2: middle column’s there are page faults
from the NthLib structures, at right we can see the
fault pages because stacks movement.
NanosDSM offers to us a message queues: we
don’t need to know where are the processes
placed or how many nodes we had, but the mes-
sages will be send through network. The opti-
mized version for each new thread consist in:
1. Master creates the activation block and sends it
to the target using a message queue.
2. Target reads the queue and constructs the stack.
3. Target processor changes the context to the new
stack and starts its executions.
4. When target finishes sends a message to master.
5. Master reads the message and decrements its
own dependence counter.
6. When master dependence counter reaches zero
enqueues it once again.
This implementation doesn’t have page faults
and only uses two messages: one sending the
work, and other to notify that the work is finished.
It has also other advantage: the messages for all
threads are sent in parallel, you don’t need to wait
paying the latency for a once. Spawning overhead
is reduced. We can see now in Figure 3 that there
aren’t page faults for library queues and slaves
stacks (as seen at Figure 2).
4.2. Synchronization
We have two mechanisms to do a lock: sharing
memory (spinlocks) o through net messages
(NanosDSM remote locks). Spinlocks are much
slower on distributed nodes, but remote are much
slower on local nodes. The first porting of NthLib
has replaced all spinlocks with remote locks. An
obvious optimization seems to use both: remote
and local locks. But the same locks will synchro-
nize local and remote threads: for example, previ-
ous seen ready queue can be accessed locally
(many processors in the same node) or remotely
(other nodes).
The work distribution optimization does
spinlocks access locally: there is not need to use
remote locks and multithreading can use local
spinlocks efficiently. Figure 3 shows no
spinlocks’ faults (there are not dark boxes in the
middle region of memory map).
Because at this moment NanosDSM didn’t
supports multithreading we can only evaluate the
impact on the overall overhead on each one thread
spawning parallelism. We can see the overhead in
Figure 7 shows that the overhead in one thread
execution of original SDSM is larger than opti-
mized SDSM.
4.3. Data distribution
On shared memory environments data distribution
is not needed, it is done automatically. SDSM
memory is not really shared: you can read the
same line simultaneously from different proces-
sors, but you can only have one copy when you
need to write this.
OpenMP user usually tries to avoid false shar-
ing between lines, but on SDSM this effect is
more critical: the time to resolve one page fault is
many times larger, and a page is larger than a
cache line. This two effects makes critical take
care about data distribution.
Nanos OpenMP environment takes care about
line size to ensure that there aren’t false sharing,
in the first porting was used the page size as sys-
tem dependant line size. This has done previously
in the porting for other architectures.
While other optimizations are done only at
level of compiler and runtime making all of them
transparent to users, this problem needs their
collaboration. In some cases a smart compiler can
do this job, but on NAS-MZ is not easy. At begin-
ning of the application reserves an entire array to
place all zones elements. It has an algorithm that
decides at which element starts each zone.
...
zone_size = nxmax(zone_no)*...
x_face_size = (y_size(j)-2)*...
y_face_size = (x_size(i)-2)*...
zone_size = zone_size + 512
x_face_size = x_face_size + 512
y_face_size = y_face_size + 512
...
Algorithm 3. NAS-MZ zone assignment modification.
Now adds 512 elements, one page.
The memory map reveals false sharing be-
tween zones (Figure 2 left columns). Our solution
XVI Jornadas de Paralelismo, JP '2005 423
was very easy: add one page of distance between
zones (Algorithm 3). This modification changes
only three source code lines but it is very effec-
tive, there aren’t these page faults on Figure 3.
5. Intra-Zone optimization
We have seen that BT-MZ has zones of different
sizes; because of it we cannot use more than five
nodes as we explained. But, if we can split zones
among multiple nodes, we can balance better and
use more processors.
5.1. Zone split
We have decided to split the largest zone (16
Figure 1). It is one fifth of all computation and the
constraint to five processors, and SDSM can
exploit better the parallelism of large data sets.
Our experiments do not result successfully.
While inter-zone communications are done once
per iteration, intra-zone has a fine grain communi-
cation with lots of page faults (Figure 2 lower
addresses, left columns, two last nodes, two bot-
tom rows) making parallel versions slower. In this
case the split zone takes more than a twice longer
than serialized one. We can check this in the
Paraver trace, Figure 4 and Figure 5.
5.2. Read to write predictor
When we have studied the Paraver trace (Figure
4) with more detail we have seen many read faults
immediately before write faults on the same
pages. The reading of a not present page in the
current node will cause a page fault. When it
occurs we need we look for that page in other
node, and get a copy. This page can be only read,
because there are other copies. If we need to write,
we must to invalidate all other copies and then,
when we are sure that it is done, we can write.
This is the second page fault.
Many operations need a previous load to mod-
ify, write, a structure. That means make two page
faults and add extra latencies. The runtime has
avoided these using dummies to write first and
later perform the operation, but this is not always
possible and also needs an extra overhead.
The read to write predictor was designed to
avoid this problem. Instead the use of a dummy
variable to make a write fault before a read fault
uses a predictor mechanism to convert read faults
into a write faults. The algorithm is very simple:
Figure 4. Final optimized paraver trace of BT-MZ zone 16 without splitting. Total time: 3.099 seconds.
Figure 5. Paraver trace of BT-MZ zone 16 split on two nodes. Total time: 5.696 seconds.
Figure 6. Paraver trace of BT-MZ zone 16. split with read-write predictor. Total time: 5.601 seconds
424 Tecnologías Grid, Clusters y Plataformas Distribuidas
x When a read fault is detected reads the IP of
instruction. If this is checked as write, a write
fault is emulated. Otherwise it is stored as
read fault information detection: IP address
and the page address faulted.
x When a write fault is detected it looks for the
faulted page at read fault information detec-
tion. If it was found checks the IP of instruc-
tion as write fault, and removes the read fault
information detection.
x When an invalidation message is received
from other node, it looks for the requested
page at read fault information detection. If it
was found removes it.
We had tested this algorithm; we have gain
near one hundred milliseconds per zone iteration
but is not enough. As seen in Figure 4, Figure 5
and Figure 6 zone split keeps larger than a serial-
ized one.
6. Final Results
The first execution on SDSM we get very bad
results as shown in Figure 7, SDSM Original.
Optimized version is many times faster than origi-
nal one. We can see that speedup of optimized
version is near to MPI version.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
1 2 4 5
nodes
speed-up
MPI SDSM original SDSM optimized
Figure 7. BT-MZ class A speed-up
7. Conclusions
OpenMP paradigm allows a very rapid develop-
ment of the parallel code. Our optimizations are
done basically on the runtime and SDSM library,
only one optimization involves the user: padding
between zones. This keeps the work of the user
simply, and also keeps our main objective: do
simple the job to the user.
If we take a look to Figure 7 we can see that
OpenMP version is very close to MPI version.
This makes OpenMP with an SDSM nearest to be
an efficient tool to allow the rapid development of
parallel applications.
The Inter-Zone optimizations have allowed us
to improve BT-MZ achieving very good results.
But the intra-zone optimizations have not enough
good performance. We need an extra effort to
improve the intra-zone communication. We are
working on a runtime that improves these kind
applications for SDSM, but currently has no effect
on BT. We need to have a good speed-up in fine
grain applications to be able to split the zones with
good performance results.
8. Future Work
Final one thread version is significantly slower
than serial one. This tells to us that it is needed
optimize better one thread version and reduce all
overheads.
The NthLib provides two mechanisms to
spawn threads: one using an entire stack for each
thread, and other using a small work-descriptor
[10] with function and arguments needed. The
idea is combine both solutions. Threads with
stacks are needed for the outer levels; work de-
scriptors have a little overhead and can be used in
the inner level. We expect that the combination of
both techniques should improve the global per-
formance and reduce the overheads.
The presented numbers are run in a standard
SDSM without any improvement. In this imple-
mentation, when BT-MZ does the frontiers ex-
change, the destination nodes fails the pages and
wait to receive they. It is possible to detect, learn,
which pages will be failed and presend them
before the other node fail. Presend will reduce the
latency needed to request those pages.
We have not used multithreading, more than
one processor per node. Doing multithreading we
can split the zone 16 in two processors of the
same node and get profit of real shared memory.
Multithreading should do possible scale beyond 5
nodes at BT-MZ class A.
In [6] is studied how to execute OpenMP ap-
plications efficiently on SDSM clusters. This kind
XVI Jornadas de Paralelismo, JP '2005 425
of applications has a high intercommunication
between different nodes, like intra-zone calcula-
tions. May be interesting to combine both studies
in order to obtain better results.
All this study was focused initially on BT-
MZ, because it is unbalanced, but our principal
objective was study the inter-node behavior. We
expect run several multi-zone benchmarks into a
near future.
Acknowledgments
This research has been supported by the Ministry
of Science and Technology of Spain under con-
tract TIN2004-07739-C02-01 and the European
Union under contract IST-2001-33071.
References
[1] C. Amza, A. L. Cox, S. Dwarkandas, P. Kele-
her, H. Lu, R. Rajamony, W. Yu, and W.
Zwaenepoel. ThreadMarks: Shared Memory
Computing on Networks of Workstation. IEEE
Computer, 29(2):18-28, Feb. 1996.
[2] E. Ayguade, M. Gonzalez, J.Labarta, X. Mar-
torell, and G. Jost. NanosCompiler: Employ-
ing Nested OpenMP for the Parallelization of
Multi-Zone Computational Fluid Dynamics
Applications. 18th International Parallel and
Distributed Processing Symposium
(IPDPS'04), Santa Fe, April 2004.
[3] E. Ayguade, M. Gonzalez, J.Labarta, X. Mar-
torell, N. Navarro, and J. Oliver. NanosCom-
piler: A Research Platform for OpenMP Ex-
tensions. In Proceedings of the 1st
European
Workshop on OpenMP, Sweeden, Oct99.
[4] E. Ayguade, X. Martorell, J. Labarta, M.
Gonzalez and N. Navarro. Exploiting Multiple
Levels of Paralelism in OpenMP: A Case
Study. Proc. Of the 1999 International Confer-
ence on Parallel Processing, Ajzu, Japan, Sep-
tember 1999.
[5] D. Bailey, T. Harris, W. Saphir, R van der
Wijngaart, A. Woo, and M. Yarrow. The NAS
parallel benchmarks 2.0. Technical Report
NAS-95-020, NASA Ames Research Center,
December 1995
[6] J. J. Costa, Toni Cortes, Xavier Martorell,
Eduard Ayguadé, Jesús Labarta. Running
OpenMP Applications Efficiently on an Every-
thing-Shared SDSM. 18th International Paral-
lel and Distributed Processing Symposium
(IPDPS'04), Santa Fe, New Mexico, April
2004.
[7] M. Gonzalez, E. Ayguade, X. Martorell, J.
Labarta, N. Navarro, and J. Oliver.
NanosCompiler: Supporting Flexible Multi-
level Parallelism Exploitation in OpenMP.
Concurrency: Practive & Experience
(12):1205/1218, October 2000.
[8] W. Hu, W. Shi, and Z. Tang. JIAJIA: An SVM
System Based on A New Cache Coherence
Protocol. In Proceedings of the High Per-
formance Computing (HPCN’99), volume
LNCS 1593, pages 463-472, Amsterdam,
Netherlands, Apr. 1999.
[9] H. Jin, M. Frumkin, and J. Yan. The OpenMP
implementation of the NAS parallel bench-
marks and its performance. Technical Report
NAS-99-011, NASA Ames Research Center,
October 1999
[10] X. Martorell, E. Ayguade, N. Navarro, J.
Corbalan, M. Gonzalez, and J. Labarta.
Thread Fork/Join Techniques for Multi-level
Parallelism Exploitation in NUMA Multiproc-
essors. In 13th
International Conference on
Supercomputing (ICS’99), June 1999
[11] X. Martorell, J. Labarta, N. Navarro, and E.
Ayguade. A Library Implementation of the
Nano-Threads Programming Model. In Euro-
Par, Vol. II, pages 644-649, August 1996.
[12] MPI 1.1 Standard, http://www-
unix.mcs.anl.gov/mpi/mpich
[13] I. Organization. OpenMP Fortran applica-
tion interface, v.2.0 www.openmp.org, June00
[14] C.D. Polychronopoulos. M. B. Girkar, M. R.
Haghighat, C. L. Lee, B. P. Leung, and D. A.
Schouten. Parafrase-2: An environment for
parallelizing, partitioning, synchronizing and
scheduling programs on multiprocessors. In
1989 International Conference on Parallel
Processing, Vol. II, pages 19-48, St. Charles,
Ill., 1989.
[15] J. Taft. Achieving 60 GFLOP/s on the Pro-
duction CFD Code OVERFLOW-MLP. Paral-
lel Computing, 27 (2001) 521.
[16] R. F. Van Der Wijngaart, H. Jin. NAS Paral-
lel Benchmarks, Multi-Zone Versions. NAS
Technical Report NAS-03-010, NASA Ames
Research Center, Moffet Field, CA, 2003.
426 Tecnologías Grid, Clusters y Plataformas Distribuidas


 

  

 




  1

 
 
1




 2

 



1,3

1


   
  
 
  
2 


 
 
 





3  

 

 




  
   
 
  
 
  
   



 
 
  
 

     
 
 

  
 
  


 
   
  
 


  
  

 
   
  
 


 

   




 
 

 
   



 


   
 
  



 !  
 
  

 

 

   
 
 "#
  

 
 
   

    


    

  !
 


"

"
 #
  



  
   
 
  
 
  
   



 
 
  
 

     
 
 

  
 
  


 
 
  

  

 
  
 

 



    
  
 



  



  
 $ 

 

 
    
  
 
 
 
    

$


 
  
    


 

  

    

 
 

 
 
   

  
 


    


 %&'
  
   $ 
 

  
  

  

      
  


 



         (


  
  

   
    

 
 %)'*       

 
  
  


 

  
 
 

 


   
  
      +,,-  


 
 

 
   
.
  
   / 
 



   
 
  



 
 
   . 
 



   

 
 


 0  
  

 
  


 
   
  
 



 
   





  

 
   






   
 
 



 !  
 
 
 
  

 

 
   
 "# / 
 
 

 


  

  
   

   
 

     1 



 
 
    
  

  
  
  


   
 
   

 

   



    
 

  
  
  
   
 
 
  


 


  

 
   
  


   
  


  

    
  


 

  !  
 

 "

 

 
  
 



 

  
#$ 
% &'
 ()*
#
'
 (++*  #'
 (,* - 

  ()* 

  
 
 
  

&'
   
     


    
 

 

 
      
 


 
.

$ 
 / 
 0.$/1  $  $ 
 / 
 0$$/1     
 
 
 

  



$2& 
  3

   (++* 


 
  

  0   


 





1 
 #
'


  
 


  


     



 

   %  


 $



 


 
 
  

    


 3
'
  
  4  4


   (,*  
 
 

 
 
  
 #'
   

        
 

   
 

  


 
    
 %  
5 

  6   


 
0781 
   
  
  
0 381  
  
   0$$81

  
    
 

&'
   
/ 
 

 



 

 

    
 
 


   

    



 

 
 / 9 
   (+*
   
  
#
'
 
  
     
  
  

(++*  

   



 

 

  
 



 
  
 3


 


  : 5  

 
 

 
 
    






    

 
 
  (+  ; +"* .


 
   




   
  


 

  
 

        

 
 
/   
 

   


  
 



  
  
 
%

 
  

      


 
     

  


 
  

 
  


 
 !
<
 &=&   

 

$ 
 

 

 

 

      

 

 

 
   

 

 
 
 
  
  


 


     
 !  
  
   
 

    

    




  
 (+)*    
 5

 


  
>  

? 
    


  
  

   



  

 
<    

 

@


  

 

+  



 
  
   


 5 -





   

    

 
 



 

 
? 

 
 
  

    
   
 


  
 

    

   

  
  
 

 

%    (+* 9

  
5  


  



@

 -

  

@

 5
% 
   5
 
<




 
 
   
  

 

  


 

 
  
 
  !  $ 




 
 
 

 

  &$ 
  
 


 


 


 
 ( *
  (*  

 




  

   
 
428 Tecnologías Grid, Clusters y Plataformas Distribuidas

 

 
  

 

  
 

 
  
   



    
   



 

 

 

! "  
   

   # 
 $  
  %&


 
$ '
 (

 $    # 




 
"
 

 "

     
  




   
)
 
) 

  
 & 
  


 
(

"  
   


  


  %
 


 
 

  
   
)
     *
•
 $

 
"   
 
     

  $ )
) 
 
 " 
      "
 
  $)
   
 

 
) 
 
 

 
)   
 + 
 , )

 
 

)   
  

 
    
   
#
" 
• 
 ,   
 
  

 


 


  
  $ 


  
 
#  + 

"
)  
   -

 
  ) 
 
.  / 
" 
 

#  )
) 

•  
  $
  



  
 
  $ .


   





 


"
 



 " " )


   
!    
) 


#
% 
 

  

 
)  
)
   



 0#    
 #

 $ 

  

 
#  + 
" 
1
"  )
) 
 

 
#  

)


  
$  " #    
232 45    #   " 
#  +  )
  

  
)

 1
" )
 
%
   

 ,.  


)     


4 $  

) 

  
"
" 

) 
 
)  , 
 ,. 


#
6 
 

)
)   
) 
 
   


 7
8    49 
  

)
 ,. 


#

 %
    
 " 

)
 
 ) 
%
 , )
   

  )  



  
 %  "
 $     

+   " 


 
)  
 $



 

 
   :
#   

# 


 
 ,. 

 

)
    '      
 
  :
#  
)  

 1
"
 

 
  
 
 %  "
    

)
  
 

"   
 
#  
)
    

'    
+   
 " + 
"  #  
" #   #

 +   

 +     " + 


" 

 

#  
"   4;      
+    
:  #


'
 )

  + 
)  
    
   )
  
   

 
) ,. 


#  < #    

)    )
    
)


)   $  &   
    

  


  '   
#    

+     
  )
 


 #

  
    $
+  
  
 #

  

) 
  4# 
  46=> "


"
XVI Jornadas de Paralelismo, JP '2005 429

   
 



 
       


 


  
  

   
    
  
 
 
  
  !"  

#    
  $%  ! &  
  
  $%  !
  
  
  $%   ' 


   
( 
  # 

)  

 
 % 
* 

' 

' #  
)+ $

),' 
   
  - %   . /01+
2     
) 


'

 
    



3
'
 '   

4 
+ . 
 

- # 
)'  #
 #
 


- % 

5
3
 #     
 /61+ 2 


' 


 #
 
%  5' 
  % 
 7+ 

 

 5' 
  
 

  




 
3
 

 5




  
+
$ 
' 

 
 - % 

 
*  
  + 2   3)
 
 '   

4 



'  
  # 
 + #


 ' 
 
 - %   


     
 
'  
-  
 

' # (  
+  8  )- 



 %

 '  ' 

   
  
  
 
3  #
 '
+ .  
 


9:

 
  ' #  %
' 
' #


+ -  
 




3
' 9: 
  

3

  # 
  # 
' 
 

- 

'  # 

 

   % '5
 3

+

 

 

 

  
(    %
       ;
#   
 
+ .  
  %

 ' ) 9< #    

 
 -  #

' 
+  '


 # 

 

 

' # 
 
 =7<  
3

'>+ .)
  %
%  

'+ $
)-

3
' # &9< #    

 )
+ 3-  ' ) %

 #  )

 

+  
  
 #


   - 




# 


 ' )  )

 
+
.   

- % 3

  
    3 

 # 

+
#-  5' 
   3


 3  #  
 5' 



  =
 7> %


3
'
)

 
 #
  
 + 


 
   #  

%



#  
  +  % 5' 


 
 
 
 
 



# ) ) - %  3) )


  ) 
)+
$'    % 
3

 (" %  


+ 2 
 3

3


 ("  

 # 

 

')-
  '     


 #+ $ ;
-   
 (" #
7-?
'
  &- #
- 3  ' 
#  '   
 
')+ 

*  
,

% 
3
' ("
430 Tecnologías Grid, Clusters y Plataformas Distribuidas

  

 

 




 
   
 
  
    
 

 
 !   
"# 
 $  %&
 %& 
$' ( ) * 
 


 


 


 "  * 

"
+&  %   

+   
  #



 , * -.
#
$/( ! 
 

 

 
0
 1 -.
#
2
 3 

4 ! 

% #

5 
 6 3-.
#
% 

4 ! 

+ #

6

67# *++ #

5 3-
# 0
%3-
# 2
5 7  

# %+ #


 

  
 
 

  8
 
7
4   . 

 
  
 
 
 
  


-
  

-


#9
 :

 

 
 
 



05"  !; 

:
9 /
#  


<.   


 
 
4 -

 

 05"9 (
  # 

4 
 

    05"  4

 
 
 
9
    

0
   
. 






#-
  
 

9 /  

. =+ %% &> 
.4

 
 


 

:


  %++? 
 


   
9 6:    .

 7 
  .  

 
 
9
  @
A .  5% 


 7 
0
10
20
30
40
50
A
E
S
M
D
5
N
a
t
R
o
u
t
e
S
n
o
r
t
_
S
l
e
s
s
S
n
o
r
t
_
S
t
r
4
S
n
o
r
t
_
P
s
c
a
n
A
r
g
u
s
C
o
n
t
r
o
l
P
l
a
n
e
D
a
t
a
P
l
a
n
e
IPC
(~4200)

  







 

:
 #   )9  -
  .
  )  5% 


9 0
 
  

 .   
7
4

 

 
 

#9  

: 



-
  

-


 
 
 

:#  


 7  
 :
. 
  ) 


9  
 
 
 .4
   
   
4 



 

#  


 -
9 6:
 #



 

.4
 
 #    



  :# 
  7



 
#  9
(

 
 
 .  


  B
 

 
 0"
4 
9 2     .4
 
 


  7  
 . 

 
 1#   9 C.:

  )
 % 1#    

. 



 7  
  ? 

:
9 0






 
 
 
  
7  
   .

-
 02(

 
.



7  9 

# 


 
 
 
   7  
 


 
 
 
  

 .4



  :
 #  

 




 

.4
   

 


7
 . 
4   
7 <.9



#)  , 


 
-

 : # :  

  




 9 
  7

7



 
<    


  #  7

-
XVI Jornadas de Paralelismo, JP '2005 431
0
2
4
6
8
10
12
14
16
18
20
4K 16K 64K 256K 1M
Data
Miss
Rate
(%)
AES
MD5
Nat
Route
Snort_Sless
Snort_Str4
Snort_Pscan
Argus
N-A-D
Stateless
Stateful

  



 


0
1
2
3
4
5
1M 2M 4M 8M
Data
Miss
Rate
(%)
AES
MD5
Nat
Route
Snort_Sless
Snort_Str4
Snort_Pscan
Argus
N-A-D
Stateless
Stateful
  



 



 







  

 

    





   




 

 

     

 

  
  
 
   
 




  
      !
"
 #
 
#


 

#


  
    
 
#



 


  

 $%   $&% '    


  




    

  

 


  

   
 
 ($




 $))%  

   
(      #

 

*


  

 + 

,-   

 
   #
 '


    

  
 
#


       
*

#

  .$/0 
  



  #
+  1

   
  #

 

    
  
 2 
  
  #
      
2    

 
 3
+  4) - 
 $ 5-  #

 3     6
 7
 

 $&)5   

  
 +  
 
 3#

  89 ,- 
 $88 ,- 

  +   
   
 




  
 
'  
  

  
  


      

 
#




  

 

  
':;   
  6
 44 " #


  
 .$0 3 


 
     

 



 #
 .0      

   



 
  
 


       :

2    
 
 







   

 '


  


   
 
 //% 



   

#



 
  /<% 
    #
  


   

 


         

   


   





  

 



  

  



3  

1
 
 
  
 
  


   
 1

  
    


 

 #
    #
     
#
  
   




   
*


   #
  
   

 


#




   
432 Tecnologías Grid, Clusters y Plataformas Distribuidas

 
 

  

      

  

 

 
 

  

      


 
 
 
  
     
 !     


 "

  
 

#  


 
 


 

    
 

     

 # $





  
 
    
%&' # 






  


 "

  (%)  
*


 
 

    
  


 " 
   
%+) ," 
  " "

 


  

"



 
 


   %)
0
0,5
1
1,5
2
2,5
3
3,5
4
A
E
S
M
D
5
N
a
t
R
o
u
t
e
S
n
o
r
t
_
S
L
e
s
s
S
n
o
r
t
_
S
t
r
4
S
n
o
r
t
_
P
s
c
a
n
A
r
g
u
s
Baseline Perfect Branch
Perfect Mem Perfect Branch & Mem

  
  
$

 


  
-  




   
 




 
 ."   


 
 


 #  

 
 
  
/% 
 
  
 



 



 

 ." #
   
 

  


 +&      

 
  

 0 
   # 
   
 "  
    
-
" 

  
 



 

1 
  

 
  "

 
  


 

 (%)
 


* 

 " 

-

 

"
 


  *  -
 


  
"
 
"
 





 


  



 
 # 

 


  



  

   

  
 ." 


   

# 


   

 


 



  
 
  /%

 
  
 



 

 


 ." # 
 


  "
0     
  

 
 #
     


 

   
 




  
#
 "   
 
 2



  $
    #   $
 


 #%++(+33'+%+( #%++4
+&&3+%+(   
56$%++%%77+ 8
9:!
 ,
6; 6 <
" 
60   
    # 

 " 


  = 2


  


"  



 

 "
    
>(? 8 5 8  
 8    
5 "

 
 


$  

    %++
>%? @ 
-  "

 
 A


 $

 A
*

   $



 



8  %++4
>? ;  ;


 <
" ;







 
>4? $ 
9+ 3% 








  !
" 8  %++4
>'? # 
 6  = 
# 


>7? " 2 ;  

, ,

   B 1 
XVI Jornadas de Paralelismo, JP '2005 433

 


   
 


  
 

  


 
   
! "##"
$%& '  ( ) * + 
! ! ,
 

  -
  
.    
 
      



 
   

 
! 
"##"
$/& 0  1 * 2 * 
3  !

 
 
-

  -  
  
 !  
!   "!#
 
 
! 
0 !
"##"
$4& 5  )  )  ( 
  
  
 
 
   
  

    
! (
0 ! ,
 "##6
$#& ! 
  
7 ' 
( 87 3 
 8 
 
 !  
7 



    # $
%
  &   $'( 
0 ! 1 "##6
$& 2  9 8 -!
 
9 8 
   

 
     '

! ( 0 ! 
 "##
$"& 
     
 
)) % 
)*

$6& 3   * +  -
 -
 

 


7:
 

 
  
   
'


27  "##6
$;&  3 !
- 





  
  

  

+,  


 ! 
  '
  -.'((/ !

 9
 !

 444
$<& ) ! = ! 5  
0 1 0
:
 -
  
 
 

 -
  

   
0  
 '
 % !   1

 " 

  


 -1
22,/ 

-
  ! !
 "##6
$>&  !


   '
 =, - 
7
   
: 
7
    .
     . 



  %

 ( 44;
$%&   = !
  -
   
 


     % 


 

   



/4?/"/  44>
$/& ( *@ ( 2A  
7 
 * 7 
.

 

  
   
,# $
%   &   $'+2
 !  1 "##;
$4& ( *@ ( 2A  
7 
 * =  
 =. -

 
 7 
 
  
   

  # $
%   & 
 *'223 
 (--
1 !
 "##;
$"#& = 9    1 0-
 - 

 
 
     '
 
 =B !   "###
$"&  (:  0 ) 

  7  

 *   
 ! 

2-3/,0(4',(5 
 "##"
$""& !

1 0 5 -


 = 3 
= -6> 0-
C 9
 3 ) ( 446
434 Tecnologías Grid, Clusters y Plataformas Distribuidas
Analyzing LoadLeveler historical information for performance
prediction
Francesc Guim, Julita Corbalán, Jesús Labarta
CEPBA-IBM Research Institute
Computer Architecture Department
Universitat Politècnica de Catalunya
{fguim,juli,jesus}@ac.upc.edu
Abstract
Prediction of the applications performance can
improve schedulers' decisions allowing them to
adapt and adjust dynamically their scheduling
policies based on a possible future picture of the
system. Some schedulers allow to the user end to
provide estimations about the time that he/she
expect that application will take to finish, however
such estimations may be not accurate or does not
take into account dynamic factors such as the load
factor of the system. It's important to provide
prediction techniques to brokers and schedulers
that take into account factors as hardware avail-
able resources and system status, and that can
adapt automatically their predictions to their
changes. Good predictions can have a big impact
on broker decisions when working with topic as
grid economics, due to they can allow choosing
the appropriate resources for a given job and
reduce cost associated to it.
To reach the final goal of designing prediction
techniques for HPC application, we have done the
preliminary study (shown in this paper) of the
workload characteristics that we consider relevant
for designing and understanding the achieved
performance for future predictors.
Paper presents the analysis of the workload result-
ing from the execution of jobs submitted to our
system, which uses the IBM LoadLever queue
system, during three years.
1. Introduction
Performance prediction is an important research
area that can be applied on scheduling and broker-
ing topics. Schedulers can improve their decision
having an approximate picture of which will be
the behavior of applications that they are schedul-
ing, for instance, knowing the amount of resources
that they will use or knowing the amount of time
that they will require to finish they computation.
Some systems, for improve their scheduling algo-
rithms, allow to end user to specify the amount of
time or resources that her/his job will require,
however user is not always able to make such
estimation or to do it correctly, that can be caused
due to the job execution time will depend on the
state of the system, or to the number of processors
that the system will grant to the her/his job, or
because the system is compound by heterogene-
ous hardware and it's not possible to know a priori
which resources job will use and so on. Good
predictions, not only can allow to schedulers and
brokers to improve the overall performance of the
system, allowing them to adapt dynamically to the
submitted applications behavior, they also can be
applied on important topics as grid economics [5],
where accurate predictions may allow to help to
decrease the economic cost of executions, because
the broker would be able to ask for the appropriate
resources that will fit to the applications require-
ments.
The main goal of our current work is to provide a
set of prediction techniques that can be used by
local schedulers and by grid brokers in their deci-
sions. We are focused on applications that are
running on systems HPC centers: parallel applica-
tion and high computational sequential applica-
tions. We think that historical data related to
applications and users can provide us enough
information for modeling and predicting it future
behavior. Due to this, we started working with
techniques that were based on workload analysis,
similar as the work presented in [5][6][7][8], and
start our research studying the workload of our
computers and design and test prediction tech-
niques for the applications contained in the work-
load.
We decided to carry out a preliminary stage that
could guide us on the processes of designing such
techniques. Mainly, the objectives of this stage
were: understand which is the behavior and char-
acteristics of the jobs that users use to submit to
the system.
In this paper we have analyzed characteristics of a
workload resulting from the execution of jobs
submitted to our system during three years. This
information has been obtained using the historic
information gathered by the queuing system
(LoadLeveler) during this period. Something that
has to be taken into account is that this study is
not intended to provide an accurate description of
this workload neither to provide specific workload
models as can be found in other works [2], we
characterized issues that we considered useful for
our purposes. The workload analysis has shown
that we will have to link runtime information
about with the information that we obtain from
LoadLever, because the variability that we have
seen on the application execution time can not
only be explained with the application parameters,
such as number of used processors, it's also should
affected by parameters such as the uptime of the
system, however we hadn't such information. If
we want to achieve good predictions predictors
should be aware of the system state when the jobs
are executed. On the other hand we need to obtain
information about the job that is not provided by
LoadLeveler, such as all its input and output data.
Also, LoadLeveler does not provide information
that allows identifying precisely the application
that is executed by the job, we have stated that
such identification is something that we must be
included in the workload trace file.
The remainder is organized as follows: section
2 provides a description of the system; sections 3
and 4 show a analysis of the applications, users
and groups of our system. Section 5 shows the
conclusions of the paper. And finally, section 6
shows the related work.
2. The environment
The system where the workload trace file was
obtained was a IBM SP2 System, named
Kadesh.cepba.upc.edu, with two different con-
figurations: the IBM RS-6000 SP with 8*16
Nighthawk Power3 @375Mhz (192 Gflops/s)
with 64 Gb RAM and the IBM p630 9*4 p630
Power4 @1Ghz (144 Gflops/s) with 18 Gb RAM.
A total of 336Gflops and 1.8TB of Hard Disk are
available. All nodes are connected through a SP
Switch2 operating at 500MB/sec. The operating
system that they are running is an AIX 5.1 and are
running the queue system Load Leveler.
The workload was obtained from Load Leveler
history files that contained around three years of
job executions. It had 178.183 jobs, however,
when analyzing the times executions, we filtered
all those jobs that were submitted to the short
queue, that were around 137.253. Short queue is
running without load factor control, what means
that those jobs that are submitted to it are sharing
the resources without any control, and Load Lev-
eler does not care about how loaded is the system.
Through the Load Leveler API, we convert the
workload history files, that were in a binary for-
mat, to a trace file whose format is similar as the
format specified in the standard workload format
proposed Dr. Feitelson et. Al. [4] (presented in
table Table 1 ).
3. Global analysis
This section divides this analysis in three main
parts: the first one explains the general behavior
of sequential and parallel applications that run in
our system. The second one provides a general
analysis of which is the behavior of the users and
groups that are working in the system based on the
workload. And finally, is presented an analysis of
the application execution frequency against its
number of used tasks.
For all this characterizations we have defined a set
of variables based on the workload fields, and for
each of them we provide two kind of statistical
estimators: biased and non biased estimators.
They are provided due to we detected that some
values that, although they were not outliers, they
could affect our conclusions if we only would
have taken into account estimators such as the
mean or the standard deviation.
Something important to mention is that we are
currently working on the study of the normality
for each of these variables. This study will allows
us to have more accurate and more statistically
correct results. The presented work, as mentioned
before, is preliminary, and next paragraphs pro-
436 Tecnologías Grid, Clusters y Plataformas Distribuidas
vide some statistical values that would be more
significant with a normality test of the variables.
A deeper analysis will be done in our future work,
when the normality of the variables will have been
already analyzed.
3.1. Application behavior
This subsection provides information about the
application characteristics that we obtained from
the analysis of the workload.
Total time analysis
It is important to know with which orders of
magnitudes we were working when predicting
application execution time in terms of amount and
dispersion, due to this we did a brief study for
estimate such measures.
In median total time for parallel jobs is approxi-
mately and order of magnitude bigger than the
total time for sequential jobs, what means that in
median they are consuming around 10 times more
of CPU time. Furthermore, in general, as shown
on tables Table 3 and Table 1, variables measured
for parallel jobs are also one order of magnitude
bigger than the other one, that implies that they
require, in general more resources.
For both kind of jobs the dispersion of all the
variables is considerable big, however in parallel
jobs is also around an order of magnitude bigger.
We expected to decrease this variability carrying
out the prediction taking into account the number
of tasks used by the job execution, or splitting all
the jobs in a subset of jobs that are matching on
similar models where such dispersion would
decrease due to their similarity intra jobs.
Total time should be studied distinguishing user
time and system time. User time should depend
more on the nature of the job, for example on
factors as: the programming model used, for
instance OpenMP or MPI in the parallel ones, the
number of used tasks used in the execution, data
set used as an input of the program etc. By the
other hand system time should depend, not only in
the program model, moreover it should depend
also on factors as the input data, system state and
so on. Next paragraphs show some relations that
we have found in the workload between some
variables, for instance data access, and the system
and user time. Future work may include detailed
characterizations of the jobs that are running on
our system and perhaps specific prediction tech-
niques for each of them.
Data access
Load Leveler history files does not provide infor-
mation about important fields as the I/O opera-
tions, input data or the traffic network. We have
tried to estimate the data access ratio for the appli-
cations by combining other available information.
Variables that we extract that are providing sort of
this kind of information are the unshared data
memory and the unshared stack size. Parallel jobs
are using around 72 times more memory than the
sequential applications, also the IQR1
. This fact
could explain in part why the system time for
parallel applications is also 10 times bigger and
why the IQR of this variable is also 10 times
bigger. As they are using more data may be the
operating system is carrying out more actions, for
instance paging in or paging out.
In fact the number of involuntary context switches
is substantially bigger in parallel applications,
around 21 times.
By the other hand this usage of data can imply
collateral effects on the memory performance for
the parallel applications, for example from a given
amount of memory usage, the cache could ex-
periment a performance dropping, and this has
also effect in user and system time. What can be
concluded from this analysis is that is necessary
knowing the input data for a given application due
to seems that it is having an important impact not
only in the user time also in the system time of for
the job application.
Actually this information is not available for us,
so we must design mechanism for collect it or find
some way to derive it. Based on the non biased
estimator IRQ, of both parallel and sequential
jobs, we see that the dispersion of the system time
is substantially big.
1
IQR is the interquartile range, and it is a non biased
estimator about the dispersion of a set of observations. It
is defined IQR=Q3-Q1 as:where Q1 is a value such as
a the exactly only 25% of the observations are less than
it, and the Q3 is a value such as exactly on 25% of the
observations are greater than it.is bigger on these first
one.
XVI Jornadas de Paralelismo, JP '2005 437
Field Name Description
Job Name Name associated with the job.
Group Group identifier of the job.
Username Name of the user that has done the submit.
Memory Amount of consumed memory consumed by the job
User Time Amount of seconds consumed by the job in user time in user mode.
Comulative total.
Total Time User time plus amount of seconds consumed by the job in system mode.
Comulative total.
Task Number of taks instantiated in the job
Unshared memory data An integral value of the amount of unshared memory in the data segment
of a process (expressed in units of kilobytes*seconds-of-execution)
Unshared stack size Integral value of unshared stack size.
Involuntary context switches Number of involuntary context switches. Comulative total.
Voluntary context switches Number of context switches due to voluntary giving up processor. Comu-
lative total.
State State on which the job finished
Table 1. Workload Fields
Perhaps it could be predicted by using correlations
whit those variables that are having a also big
dispersion and that seem that have influence on
the system time: unshared data memory, involun-
tary switches, unshared stack size, reclaimed page
faults and page faults IO required (perhaps more
variables will be included on future work).
Relation among some of the discussed variables
can be seen with the correlation coefficient pre-
sented in table Table 2. Sequential jobs may have
some relation between the system time and the
unshared memory data and between the system
time and the reclaimed page faults. However, a
deeper study has to be done in order to find out
which is the numerical or statistical relation be-
tween these variables, and also important, how to
collect such information previously the execution
for a job.
Collateral effects in total time
The mentioned fact that sequential and parallel
jobs are having some relation between the system
time and the reclaimed page faults, together with
the fact the node usage mode when the execution
of the applications is shared in sequential jobs
around the 95% of the executions and for the
parallel jobs is the 60%, adds an important issue
to be treated: effects of the system state when the
job execution. We think that predictors should be
aware of the system state, taking into account
variables as load factor, number of jobs, disc
usage, network usage and so on, because page
faults not only depends on the job nature it also
depends on the state of the system. Although
seems that there is no relation between the system
time and the involuntary switches we think that
with more detailed tests we will be able to find
relations between them, normality test can guide
us to find them. Would be interesting to correlate
this kind of variables, with the system state in the
moment of the job execution, and also correlate
this information with the total time, we may find
some relations that would be really powerful in
the prediction techniques.
App.
type Var1 Var2 p-value
Seq. User Time
Unshared D.
memory 0.15
Par. User Time
Unshared D.
memory 0.05
Seq. System Time
Unshared D.
memory 0.47
Par. System Time
Unshared D.
memory 0.13
Seq. System Time
Involuntary
Switches 0.11
Par. System Time
Involuntary
Switches 0.13
Seq. System Time
Reclaimed
page faults 0.37
Par. System Time
Reclaimed
page faults 0.45
Table 2. Correlation between variables
438 Tecnologías Grid, Clusters y Plataformas Distribuidas
Parallelism level analysis
It was important to realize if it made sense to
take as an input field for the prediction techniques
the number of tasks used by the applications. In
this section we present the analysis that we carried
out for answer such question.
First column of the Table 5 shows the level of
parallelism of the jobs that are running on the
system, it presents 7 different intervals, each of
them has the percentage of jobs that run with the
given number of tasks. From this table we can
state that users are not submitting jobs with a
specific level of parallelism. Rather this, jobs are
spread among all the different number of tasks.
Table 3. Sequential applications variables
Table 4. Parallel applications variable
Variable Min Q1 Median Mean Q3 IQR Max Units
User time 1e+4 1.7e+5 4.5e+5 9.7e+7 3.76 e+7 3.7e+7 2.19 e+9 Secs
System time 1e+4 1.9e+5 3.6e+5 1.6e+7 2.4e+6 2.28e+6 2e+9 Secs
Reclaimed page
faults
231 770 1017 213800 4539 3769 3 e+8 -
Page faults IO
Required
0 0 2 2815 5 5 3458000 -
Unshared stack 56 6688 1.08e+5 3.1e+8 1.5e+6 1.5e+6 11.6e+11 Kb
Unshared D.
Memory
8 1.6e+4 1.6e+6 7e+12 3.4e+7 3.4e+7 9.33e+15 Kb
Inv. Switches 0 8 48 135400 453 445 17.8 e+7 -
Vol. switches 0 44 192 18420 46116 4572 5356000 -
Variable Min Q1 Median Mean Q3 IQR Max Units
User time 10000 6.3 e+6 6.14 e+7 3.36 e+8 4 e+8 4 e+8 2.14 e+9 Secs
System time 10000 3.5 e+5 2.63 e+6 6.11 e+7 8.07 e+6 7.72 e+6 2.14 e+9 Secs
Task instance
count
2 3 5 14.97 17 15 257
Node 1 1 1 1.41 1 0 8
Reclaimed page
faults
232 5134 19770 2.28 e+5 94330 89196 6.05 e+7 -
Page faults IO
Required
0 1 3 19250 25 24 3.6 e+7 -
Unshared stack 56 41690 6.98 e+5 3.5 e+9 3.56 e+9 8.7 e+6 2.75
e+12
Kb
Unshared D.
Memory
8 2.69 e+6 1.16 e+5 4.38
e+11
8.93 e+8 8.9 e+8 8.28
e+14
Kb
Inv. Switches 0 56 986 1.39 e+8 21480 21424 4.72
e+11
-
Vol. switches 0 92 1179 6.6 e+6 6001 5909 6.7e+9 -
XVI Jornadas de Paralelismo, JP '2005 439
Despite we are analyzing a parallel envi-
ronment there is an important amount of jobs
that are sequential (23%), what means that in
our system there are a lot of HPC applications
running in a sequential mode and we should
paid attention on prediction techniques that are
oriented to sequential applications.
Although, the first column of Table 5 pro-
vides a global view about the level parallelism
of all the submitted jobs, it does not show which
of these intervals are using more resources.
Knowing which of these intervals were consum-
ing more processor can be obtained pondering
each job execution for the amount of cumulative
time that it spent running on the machine (sec-
ond column contains such information).
Jobs that are consuming more computational
resources of our system, are split in three main
intervals, the most important is those jobs that
are using 5-15 processors (31%), then those that
are using 65-128 processors (29%) and finally
those jobs that are using 17-32 processors
(13%). We should have to pay special attention
on these intervals because a miss prediction on
one of these jobs can imply bad performance on
a given scheduling based on such prediction.
Last paragraphs are showing the global level
of parallelism of the submitted jobs to the sys-
tem. However, it is also interesting to know how
many tasks the applications use to instantiate.
Specifically we wanted to know how many jobs
steps that are supposed to be an instantiation of
a same application were executed in our system
with the same number of tasks.
Table 6 shows the mean, median and third
quartile of the number of jobs for the same
application that were executed with the given
number of tasks, for instance same applications
using two tasks where executed in mean ap-
proximately two three times. This table tries to
provide a whole picture of how the applications
are executed on our system in terms of task
usage. Specifically it presents the number of
times that applications use to be executed with
the same number of instance tasks.
In median all the applications used to be
executed once time with the same number of
tasks. However the third quartile for those jobs
that were executed more times, those that belong
to intervals 5-16 processors and 65-128 proces-
sors are executed in general more than 5 times
with the same number of tasks. What means that
there is a 25% of the applications that were
executed with such number of tasks more then 5
or 6 times. There is not enough or significant
amount observations for predictors that index
predictions based executions for an application
and for the same number of tasks than need a
minimum set of observations, such as those that
use techniques as statistical estimators.
Interval job %of jobs on the
workload
%of time
1 task 23% 8%
2 tasks 13,7% 4%/
3-4 tasks 6,8% 9%
5 -16 tasks 29,8% 31%
17 -32 tasks 12,9% 13%
33 -64 tasks 2,2% 6%
65 -128 tasks 11% 29%
129 -256 tasks 0,09% 0,09%
257 -512 0,01% 0,01%
Table 5. Interval job built from the workload
#Tasks 2 6 7 8 12 14 26 33 37 65
Median 1 1.5 1 1.5 2 2 1 1 1 2
Mean 3.26 4.31 2.45 4.31 5.16 4.97 3.71 2.69 4.20 22
Max 1472 31 36 30 47 33 5 76 5 1140
3rd Quartile 1 6 2 6.25 6.5 6.25 4.5 5 3.5 1
Table 6. Number of jobs of the same applications using same number of tasks
440 Tecnologías Grid, Clusters y Plataformas Distribuidas
Variable Min Q1 Median Mean Q3 IQR Max
# applications 1 3 9 82.19 38 35 1850
# executions 1 28 133 417 509 481 5998
# exec same app. 1 3 8 22 21 18 240
Table 7. Users summary table
Variable Min Q1 Median Mean Q3 IQR Max
# applications 1 6 22 336.1 134 128 1959
# executions 6 43 195 1779 1356 1313 14670
# exec same app. 1 3 7 17.720 28 25 99
Table 8. Groups summary table
3.2. Users and groups behavior
Analyzing how users are submitting their appli-
cations is also important and this information
should be taken into account when designing
predictors . This section tries to summarize such
analysis. However it does not intended to be an
accurate modeling neither characterization of
them.
Table 7 summarizes the user activity extracted
from the workload, it shows different statistical
data for the number of applications that the users
had submitted, for the number of executions that
they had submitted, and finally, for the number
of times that they has executed in mean same
applications.
In general users are not working with a big set
of applications. In median, users submitted 9
different applications, and, also in median, they
executed each application around 8 times. In this
case predictors based on historical information
that index their predictions by application and
user, and that require a minimum set of observa-
tions, perhaps they won't be able to carry out
fine predictions. However, from the 98 users 22
of them had submitted in mean same applica-
tions more than 30 times. Taking into account
only these users, the presented median increases
until 56.11 observations for user and applica-
tion.
Similar conclusions can be applied with user
groups (see table Table 8). Although same
groups in general are submitting in median 22
different applications, they are still submitting
few than 7 times the same application. However,
there are some groups that are submitting in
median more times same applications, from 22
groups, there are 6 groups that are submitting in
median more than 42.2 times same applications.
As concluded for users, for these 6 groups pre-
dictors could have enough data for carry out
more precise predictions than the rest.
For those groups and users that have few
observations in the workload we should try to
design predictors based on techniques that do
not require a lot of previous executions. But for
the rest jobs of the system more sophisticate
predictors can be applied. Other important issue
that we are currently considering is how to
decide dynamically which predictor apply for a
given user, group or application, depending on
the indexing criteria used in the prediction, that
allows to get more performance in global pre-
dictions.
4. Conclusions and future work
In this paper we have presented the preliminary
work that we have done about workload analy-
sis. We have presented how we analyzed infor-
mation, extracted from the workload of a
LoadLeveler queue system, that we consider
useful for understand applications behavior and
how user is submitting jobs to the system.
Workload analysis has shown that real work-
loads are really heterogeneous, and that vari-
ables of such workload, such as the total amount
of used memory for the job, have big variability.
It has also shown that exist some relation be-
tween some of the workload variables, for in-
stances between system time and the reclaimed
page faults for the parallel jobs, that could be
used on the predictor algorithms.
XVI Jornadas de Paralelismo, JP '2005 441
An important conclusion is that workload
trace files used for prediction should include for
each job which was the state of the system
before and during its execution, for instance
providing fields as load factor, memory used or
network bandwich available. We will have to
study how collect dynamically such information
from the runtime, together with other important
data that we currently don't have, as the I/O files
and executable names, and how to merge it with
the workload provided by Load Leveler. To-
gether with the mentioned runtime and missing
information we could include new fields from
the workload to the trace files, LoadLeveler
provides a huge set of other fields that could be
used, such as: number of sent and received
messages for MPI applications.
The presented work has also shown that
LoadLeveler does not provide any way to iden-
tify precisely the application that is executed in
a given job. The fields that it provides (job
name, step name or executable name) do not
identify what the user has submitted. Future
work must include how to find such identifica-
tions and how to add it into the trace files. Hav-
ing such information prediction would be more
accurate and results may improve.
We have realized that working with real
workloads is a tedious and difficult task due to
many factors has to be taken into account, and
not always is possible achieve clear conclusions.
5. Related work
An important issue, before start with prediction
was how to work with the workload of our
system and treat goals such: how to construct
the trace files, how analyze them, how model
them and so on. We defined an initial workload
trace format based on a subset of the standard
workload field proposed by Dror G. Feitelson et.
Al. at [SWF05]. We extended also this defini-
tion adding some extra fields that are not in-
cluded in such standard, and that we consider
necessary for our work, for instance the number
of voluntary switches. Related to the analysis of
workload trace files, a complete workload char-
acterization is presented in [calzarossa93],
however for this initial work we did no consid-
ered that we should have to describe and analyze
the workload at this detail.
6. Acknowledgements
This work has been supported by the HPC-
Europa European project under contract 506079
and by the Spanish Ministry of Science and
Education under contract TIN2004-07739-C02-
01.
References
[1] E. Smirni and D. A. Reed, "Workload Char-
acterization of Input/Output Intensive Paral-
lel Applications". In 9th Intl. Conf. Comput.
Performance Evaluation, Springer-Verlag,
Lect. Notes Comput. Sci. vol. 1245, pp. 169-
-180, Jun 1997.
[2] "Modeling of Workload in MPPs", Joefon
Jann, Pratap Pattnaik, and Hubertus Franke
(IBM Watson) Fang Wang (Yale Univer-
sity). JSSP03
[3] R. Buyya, H. Stockinger, J. Giddy, and D.
Abramson. Economic Models for Manage-
ment of Resources in Peer-to-Peer and Grid
Computing. In SPIEs Int. Symposium on the
Convergence of Information Technologies
and Communications (ITCom 2001), Den-
ver, CO, USA, August 2001.
[4] Stantard Wrokload Format.
http://www.cs.huji.ac.il/labs/parallel/worklo
ad/swf.html
[5] Warren Smith, Ian Foster, and Valerie Tay-
lor, "Predicting Application Run Times Us-
ing Historical Information". JSSP, Dror G.
Feitelson and Larry Rudolph, (ed.), Springer
Verlag, Lect. Notes Comput. Sci. vol. 1459,
pp. 122--142, 1998.
[6] "Predicting Application Run Times Using
Historical Information" Warren Smith and
Ian Foster (ANL) 4th JSSP
[7] Anat Batat and Dror G. Feitelson, "Gang
Scheduling with Memory Considerations".
In 14th Intl. Parallel & Distributed Process-
ing Symp. (IPDPS), pp. 109--114, May
2000.
[8] Murthy V. Devarakonda and Ravishankar K.
Iyer, "Predictability of Process Resource
Usage: A Measurement-Based Study on
UNIX". IEEE Trans. Softw. Eng. 15(12),
pp. 1579--1586, Dec 1.
442 Tecnologías Grid, Clusters y Plataformas Distribuidas
Balanceo de carga en sistemas distribuidos Master - Worker *
A. Moreno E. Cesar, J. Sorribes, T. Margalef, E. Luque
Escola Universitaria Salesiana de Sarrià Dept. de Informática
Passeig Sant Joan Bosco, 74 Universitat Autònoma de Barcelona
08017 Barcelona 08193 Bellaterra
amoreno@euss.es {eduardo.cesar, joan.sorribes, tomas.margalef, emilio.luque}@uab.es
Resumen
El balanceo de carga es uno de los aspectos a
tener en cuenta para optimizar el rendimien-
to de una aplicación que se ejecute en un sis-
tema distribuido. Tradicionalmente los algo-
ritmos se han desarrollado para planicación
de la carga en bucles paralelos. En este tra-
bajo se presenta una adaptación de uno de
los algoritmos más extendidos, Factoring, a
un patrón común en sistemas distribuidos, el
Master-Worker.
1. Introducción
La programación de sistemas distribuidos se
realiza habitualmente a muy bajo nivel. Las
consecuencias de este procedimiento son que
el programador necesita un profundo conoci-
miento de la máquina y del software que lo
controla. Esta situación muy amenudo resulta
en que las aplicaciones obtienen unos rendi-
mientos bajos al no aprovechar adecuadamen-
te el paralelismo. Para tratar de mejorar esta
situación sin implicar demasiado al programa-
dor, se han desarrollado métodos automáticos
de sintonización que ajustan dinámicamente
los parámetros del sistema para optimizar el
rendimiento en cada situación. El balanceo de
la carga es una de las estrategias para opti-
mizar el rendimiento de sistema. Su principio
de funcionamiento consiste distribuir la carga
adecuadamente para aprovechar al máximo la
*Este trabajo ha sido nanciado por el MCyT bajo
contrato TIN2004-03388
capacidad de cómputo de los diferentes proce-
sadores distribuidos.
En este sentido se han realizado trabajos
previos [13] en los que se ha presentado una
plataforma en la que es posible desarrollar
aplicaciones distribuidas basadas en varios pa-
trones, uno de ellos el Master-Worker [12]. Es-
ta plataforma permite implementar estrategias
de sintonización que estén totalmente desliga-
das de la aplicación, y por lo tanto, simplicar
y optimizar el desarrollo de software para siste-
mas distribuidos. Sobre esta base se han estu-
diado estrategias de sintonizado inspiradas en
obtener el número adecuado de procesadores
para la aplicación [4]. En esta línea, el presente
trabajo es una continuación abordando el as-
pecto del balanceo de carga. El patrón Master-
Worker [12] es una estructura muy conocida en
el mundo de la programación paralela. Consis-
te en un proceso Master que envía tareas a
un conjunto de procesos Workers, los cuales
las procesan, envían el resultado al Master y
quedan a la espera de recibir más trabajo.
En los siguientes apartados se presenta las
estrategias de balanceo de carga más destaca-
das. A continuación se incide con más detalle
en el Factoring, algoritmo del que se presen-
ta en este trabajo una adaptación al patrón
Master-Worker. Finalmente se verán resulta-
dos de diversas simulaciones y las conclusio-
nes.
2. Estrategias de Balanceo de Carga
El balanceo de carga es una de las estrate-
gias para mejorar el rendimiento de un sistema
distribuido. Consiste en distribuir el trabajo a
realizar por cada procesador del sistema de tal
forma que a la nalización se haya obtenido el
máximo rendimiento del sistema. Este objeti-
vo se maniesta en la minimización del tiempo
total de cómputo.
Son muchas las estrategias que se han desa-
rrollado para balancear la carga, la mayoría de
ellas han surgido del mundo de los bucles pa-
ralelos. En este entorno el trabajo a realizar se
divide en lotes (Batchs). Cada lote está com-
puesto por P (número de procesadores) con-
juntos (chunks) de tareas (tasks), en muchos
casos iguales. En los Cuadros 1 y 2 se exponen
las más destacadas. El criterio de clasicación
seguido se ha basado en distinguir entre la ca-
pacidad de adaptarse a la dinámica del siste-
ma en pleno funcionamiento (no adaptativo y
adaptativo) y al hecho de planicar tamaño de
chunks constantes o variables.
La estrategia Static Scheduling consiste sim-
plemente en distribuir todo el trabajo a reali-
zar entre los procesadores del sistema distri-
buido en el primer lote y esperar los resulta-
dos. Esta estrategia es la más simple pero a la
vez la más ineciente. El desequilibrio en los
tiempos de ejecución pude conducir al sistema
a un tiempo total de ejecución marcado por
el último procesador en terminar su trabajo,
mientras el resto que ya han terminado están
parados.
Self Scheduling adopta un postura total-
mente opuesta a la del Static Scheduling. En
este caso se reparte la mínima cantidad de tra-
bajo a cada procesador que termine el traba-
jo anterior. El proceso culmina cuando se ha
completado todo el trabajo. El balanceo teóri-
co en este caso es muy bueno, ya que los dese-
quilibrios en los tiempos de ejecución se com-
pensan con la ejecución de más trabajos por
los procesadores rápidos. Por el contrario se
paga el precio de una sobrecarga en gestionar
los datos y las respectivas comunicaciones.
Fixed Size Chungking es una generalización
cuyos casos extremos serían Static Scheduling
y Self Scheduling. El dimensionado del trabajo
asignado en cada chunk es constante durante
todo el proceso, y está limitado en un extremo
por la cantidad mínima y en el otro extremo
Chunks Estrategia Tamaño
Chunks
Constante Static Sche-
duling
N/P
Self Schedu-
ling
1
Fixed Size
Chungking
[10]
kopt
Decreciente Guided Self
Scheduling
[14]
R/P
Factoring [9] R/xP
Fractiling [1] Factoring
para N-
Body
Weighted Fac-
toring [8]
Pesos para
los procesa-
dores
Trapezoid
Self-
Scheduling
[15]
Decrece
linealmente
TAPER [11] Basado en
modelo pro-
babilístico
Bold [6] Evolución de
TAPER
Cuadro 1: Estrategias de Balance de Carga no
adaptativas
Chunks Estrategia Tamaño
Chunks
Dinámico Adaptive
Weighted
Factoring [2]
Adaptación
del peso de
los procesa-
dores
Adaptive Fac-
toring [3]
Estimación
estadística
del compor-
tamiento
Cuadro 2: Estrategias de Balance de Carga
Adaptativas
444 Tecnologías Grid, Clusters y Plataformas Distribuidas
por la cantidad necesaria para repartirlo todo
en un único lote. En [10] se desarrolla esta téc-
nica y plantea el número de tareas óptimo que
minimiza el tiempo total de ejecución.
Con Guided Self Scheduling [14] se introdu-
jo que el tamaño del chunk sea variable, con-
cretamente se propone que sea decreciente. Es
decir mayor en los primeros lotes y menor en
los siguientes. Con esta estrategia se minimiza
la probabilidad de que un tiempo de ejecución
pueda sobrepasar de forma no deseada el tiem-
po del resto, hecho que es más critico cuando
se aproxima el nal de proceso. La función con
la que se asigna el tamaño del chunk es la rela-
ción entre el total de tareas pendientes de ser
enviadas y el total de procesadores.
Factoring [9] es sin duda una de los algo-
ritmos de balanceo de carga más extendidos.
Se trata también de un sistema de tamaño de
chunk decreciente pero está inspirado en un
modelo probabilístico en el que se pretende
que la probabilidad de que un procesador aca-
be condicionando el tiempo total mediante una
ejecución demasiado larga sea la mínima.
Fractiling [1] es una adaptación del Facto-
ring para simulaciones N-Body que compensa
el desequilibrio de carga causado por la dis-
tribución irregular de Bodies. Este tipo simu-
laciones se utiliza frecuentemente en muchos
campos de la ciencia, des de la astrofísica has-
ta la biología molecular.
Weighted Factoring [8] aporta a Factoring el
soporte de sistemas distribuidos heterogéneos.
Básicamente consiste en añadir unos factores
de ponderación que en función del comporta-
miento histórico asignan más o memos tareas
a los diferentes procesadores. Teóricamente se
basa en considerar que los tiempos de ejecu-
ción de las iteraciones pueden modelarse como
variables aleatorias iguales con un cierto peso.
Trapezoid Self-Scheduling [15] es una estra-
tegia de balanceo que persiguen un buen com-
promiso entre la sobrecarga de planicación y
el desequilibrio en el balance de carga median-
te un tamaño de chunk linealmente decrecien-
te.
La estrategia TAPER [11] parte de un mo-
delo probabilístico en el que intenta que la pro-
babilidad de que un determinado procesador
supere el tiempo nal esperado esté por deba-
jo de un cierto umbral. La estrategia Bold [6]
es una evolución del TAPER a costa de añadir
complejidad.
Adaptive Weighted Factoring [2] es una evo-
lución del Weighted Factoring en el que los
pesos utilizados para ponderar se ajustan des-
pués de cada iteración. De esta forma se tiene
presente el comportamiento histórico del sis-
tema iteración a iteración.
Finalmente Adaptive Factoring [3] se plan-
tea como una generalización del Adaptive
Weighted Factoring en el que ya no se conside-
ran los mencionados pesos, sino que se parte
de la base que el tiempo de ejecución de ca-
da iteración en cada procesador son variables
aleatorias totalmente distintas (en el Weigh-
ted Factoring se considera que tienen al mista
mediana y varianza y nalmente se les aplica
un factor ponderador). Mediante un proceso
adaptativo el planicador va asignando más
o menos trabajo según el comportamiento del
sistema.
2.1. Factoring
En este artículo se va a presentar una adap-
tación del Factoring al patrón Master-Worker.
A continuación se va exponer el desarrollo de
Factoring [9] original para bucles paralelos. Se
utilizará la siguiente terminología:
• P = número de procesadores.
• N = número total de iteraciones.
• Las iteraciones de planican en lotes (bat-
ches) de P de trabajos (chunks) del mismo
tamaño.
• Fj = número de iteraciones de cada tra-
bajo (chunk) del lote j.
• El tiempo de ejecución de las iteraciones
de los bucles paralelos se modelan como
variables aleatorias idénticas e indepen-
dientes.
• El tiempo de ejecución de un chunk de Fj
iteraciones se modela como una variable
aleatoria surgida de la suma de Fj varia-
bles aleatorias idénticas e independientes.
XVI Jornadas de Paralelismo, JP '2005 445
Asumiendo que los procesadores inicialmen-
te no están trabajando, el tiempo de ejecución
de P chunks puede ser modelado como un es-
tadístico de orden P, es decir, el máximo de P
variables aleatorias con la misma distribución.
El valor esperado de un estadístico de orden
P para cualquier distribución con media µ y
varianza σ2
es [5, 7]
µ + σ
P − 1
√
2P − 1
(1)
que puede simplicarse con una cota ligera-
mente superior
µ + σ
P − 1
√
2P − 1
≤ µ + σ

P
2
(2)
Supongamos que el primer lote asigna
chunks de F0 iteraciones. Su tiempo de eje-
cución se modela como una variable aleato-
ria obtenida mediante la suma de F0 variables
aleatorias idénticas e independientes de media
µ y varianza σ. Resultando una media µF0 y
una varianza σ2
F0. El valor máximo esperado
para la ejecución de P chunks en paralelo(cada
uno con F0 iteraciones) en el primer lote es en-
tonces
µF0 + σ

F0P
2
(3)
El número de iteraciones por lote se determina
imponiendo que el tiempo máximo estimando
de ejecución de lote actual no supere el tiempo
total óptimo de todos los lotes restantes inclu-
yendo el actual y sin considerar sobrecarga de
planicación, µN/P (Ver Figura 1).
µN
x0P
+ σ

N
2x0
=
µN
P
(4)
donde también se ha substituido F0 por
N/(x0P). Despejando x0
x0 = 1 + b2
0 + b0

b2
0 + 2 (5)
donde b0 se dene como
b0 =
P
2
√
N
σ
µ
(6)
En los lotes siguientes, los chunks tienen
tiempo de ejecución µFj y varianza µ2
Fj, pero
W0
W1
W2
W3
W4
Tiempo
Esperado para Todos los Lotes
Figura 1: Tiempo de ejecución de los chunks en el
primer lote
al contrario del primer lote, el tiempo de ini-
cio no es habitualmente el mismo. Al no poder
hacer un planteamiento exactamente igual, se
adopta la postura de igualar el tiempo máximo
esperado con el tiempo total óptimo de todos
los lotes, pero sin contar el lote actual. Esta
opción más conservadora intenta compensar
el hecho que los chunks empiecen en instan-
tes distintos. De esta forma
µRj
xjP
+ σ

Rj
2xj
= µ(
Rj
P
− Fj) (7)
despejando xj
xj = 2 + b2
j + bj


b2
j + 4 (8)
donde bj se dene como
bj =
P
2

Rj
σ
µ
(9)
Experimentalmente se han vericado [9] que
la mayoría de los casos, jar un xj = 2 es una
buena opción.
446 Tecnologías Grid, Clusters y Plataformas Distribuidas
3. Sistema Distribuido Master -
Worker
El algoritmo de balanceo de carga Factoring
fue concebido para los bucles paralelos. En es-
te trabajo se presenta una adaptación del mis-
mo al patrón Master-Worker. En el siguiente
desarrollo se va a utilizar la terminología:
• Vd = volumen total de datos enviado des-
de el Master a los Workers (bytes).
• P = número de Workers.
• N = número total de tareas. Cada tarea
tiene Vd/N bytes.
• Fi = número de tareas asignadas a cada
uno de lo chunks del lote i. Vendrá deter-
minado por las expresiones del algoritmo.
• C = tiempo de procesado por tarea
(ms/tarea).
En bucles paralelos la variable aleatoria es
el tiempo de chunk, obtenida como la suma de
Fj variables idénticas, cada una representativa
del tiempo de iteración. En el patrón Master-
Worker consideraremos que la variable aleato-
ria es el tiempo de procesado por tarea (C),
por ser precisamente lo que se puede instru-
mentar directamente (realmente es el tiempo
de proceso de cada chunk, del que se obtiene
C mediante el número de tareas). Entonces el
tiempo de chunk es el producto de una mues-
tra de esta variable aleatoria por el número de
tareas asignadas. En el primer lote la ecuación
4 puede reescribirse como (el cambio se mani-
esta en la parte de la desviación estándar)
µC F0 + σC F0

P
2
= µC
N
P
(10)
F0 pude ser substituido
µC
N
x0P
+ σC
N
x0P

P
2
= µC
N
P
(11)
que es equivalente a
µC
1
x0
+ σC
1
x0

P
2
= µC (12)
despejando x0
x0 =
µC + σC

P
2
µC
(13)
F0 =
N
x0P
=
N
P
µC
µC + σC

P
2
(14)
Para los lotes siguientes se puede seguir el
mismo planteamiento
µC Fj + σC Fj

P
2
= µC (
Rj
P
− Fj) (15)
agrupando términos
2µC Fj + σC Fj

P
2
= µC
Rj
P
(16)
substituyendo Fj
2µC
Rj
xjP
+ σC
Rj
xjP

P
2
= µC
Rj
P
(17)
despejando xj
xj =
2µC + σC

P
2
µC
(18)
Fj =
Rj
xjP
=
Rj
P
µC
2µC + σC

P
2
(19)
Las ecuaciones obtenidas 13 y 18 son más
simples que las equivalentes en tradicional Fac-
toring en bucles paralelos. Esta simplicación
se deriva al cambio de variables aleatoria del
tiempo de iteración al tiempo de procesado por
tarea.
4. Simulaciones
Para vericar la idoneidad de utilizar la adap-
tación del Factoring en el patrón Master-
Worker se han realizado una serie de simu-
laciones. Se persigue comparar el comporta-
miento de Static Scheduling (SS), Fixed Size
Chungking (FSC) con factor 5 (5 lotes en to-
tal), Factoring con factor 2 (F2) y Factoring
(F) en el mismo sistema. Estos algoritmos de-
muestran su ecacia cuando el comportamien-
to del sistema es variable. Para simular una
XVI Jornadas de Paralelismo, JP '2005 447
situación lo más real posible, se han realizado
varias simulaciones, en cada caso con un siste-
ma con un comportamiento distinto. La varia-
bilidad entre los sistemas se ha controlado me-
diante parámetros probabilísticos. Finalmente
se ha obtenido el comportamiento medio de ca-
da algoritmo bajo ciertas condiciones que nos
ha permitido vericar la ecacia de cada algo-
ritmo respecto el resto.
Se parte de un sistema con 50 Workers y
2000 tareas a repartir. La tareas se reparten
por lotes de 50 chunks, cada uno con el mis-
mo número de tareas determinado por el al-
goritmo en cuestión. Para obtener el tiempo
que va a invertir un determinado Worker pa-
ra procesar su chunk, se debe multiplicar el
número de tareas del chunk asignado por el
tiempo por proceso de tarea de ese Worker C.
Esta última variable será en nuestro caso una
muestra de una variable aleatoria de media y
varianza conocida, y con una función de distri-
bución normal. Las muestras de C resultantes
se truncaran a un mínimo valor preestableci-
do para evitar valores excesivamente bajos o
incluso negativos.
Se han escogido pares de valores de media y
varianza. Para cada uno de ellos se han reali-
zado 200 simulaciones, en cada caso con una
muestra distinta de la variable aleatoria C. Así
se simula el mismo sistema pero con compor-
tamiento variable. Como resultado se obtiene
el tiempo total de ejecución. A continuación
se ha realizado un análisis estadístico de los
resultados mediante una estimación de la me-
dia y su correspondiente intervalo de conan-
za (intervalo en el que es más probable que
este el valor de media real). Para obtener el
intervalo de conanza no se ha podido utilizar
los métodos parámetros tradicionales como el
basado en la función t de Student, pues la po-
blación obtenida (los tiempos de ejecución de
las 200 simulaciones) no suelen presentar una
distribución normal. Esto último se ha veri-
cado con el test de normalidad de Anderson-
Darling. Finalmente ha sido necesario recurrir
a la estadística no paramétrica para obtener
los intervalos de conanza de la media estima-
da. Se ha utilizado la variante de Efron basado
en percentil de los métodos Bootstrap.
µC σC SS FSC
5 1 321.28∓2.22 260.02∓0.58
5 2 410.03∓4.04 258.64∓1.14
5 3 502.81∓7.13 251.79∓1.98
5 4 583.95∓8.74 254.82∓2.27
5 5 685.80∓9.93 262.69∓2.42
Cuadro 3: Resultado de la simulaciones (en
ms) de Static Scheduling (SS) y Fixed Size
Chungking (FSC)
En los Cuadros 3 y 4 se observan los resul-
tados para los respectivos valores de la media
de C (µC ) y una varianza creciente (σC ). En
todas la simulaciones se ha contemplado tam-
bién la sobrecarga de las comunicaciones. Los
resultados permite obtener las siguientes con-
clusiones:
• Static Scheduling (SS) es el que presenta
peores resultados para todos los valores de
varianza, pero empeora aun más cuando
esta aumenta.
• Fixed Size Chungking (FSC) con factor
5 presenta un comportamiento constante
y bueno cuando la varianza aumenta. Lo
cual supone que esta estrategia nos ga-
rantiza unos buenos resultados con una
complejidad mínima.
• Las dos opciones de Factoring (F y F2)
tienen un comportamiento muy similar
para valores bajos de varianza y es pa-
ra valores altos cuando realimente es ren-
table utilizar la versión completa (F) en
detrimento de la simplicada.
• Comparando el Factoring (F) con el resto
de estrategias observamos que el mucho
mejor que Static Scheduling (SS) y lige-
ramente mejor que Fixed Size Chungking
(FSC).
• Conrma que la adaptación del Factoring
(F) al patrón Master-Worker con las nue-
va expresiones ofrece un balance de carga
satisfactorio.
448 Tecnologías Grid, Clusters y Plataformas Distribuidas
µC σC F F2
5 1 241.08∓0.41 238.86∓0.38
5 2 237.43∓0.73 235.61∓1.41
5 3 226.99∓0.91 269.01∓3.45
5 4 220.39∓1.20 307.34∓4.10
5 5 222.23∓1.14 357.69∓5.00
Cuadro 4: Resultado de la simulaciones (en
ms) de Factoring (F) i Factoring con factor
2 (F2)
5. Conclusiones
En este trabajo se ha presentado una adapta-
ción del algoritmo de balanceo de carga Fac-
toring para el patrón Master - Worker. Se ha
planteado con un cambio de principio básico:
en lugar de utilizar como variable aleatoria el
tiempo de bucle en los bucles paralelos se ha
tomando el tiempo de procesador por tarea en
un Master - Worker. Este replanteamiento ha
supuesto unas nuevas expresiones, mucho más
simples que las originales. Se ha llevado a ca-
bo todo un proceso de simulación en el que
se ha comparado static Scheduling, Fixed Si-
ze Chungking con factor 5, Factoring con fac-
tor 2 y Factoring (F) en el mismo sistema. Se
ha introducido variabilidad en las simulaciones
para reproducir una situación lo más real po-
sible. Finalmente se ha observado que el nuevo
algoritmo presenta un comportamiento mejor
que el resto de sistemas bajo diferentes situa-
ciones.
Referencias
[1] I. Banicescu and S. F. Hummel. Balan-
cing processor loads and exploiting data
locality in n-body simulations. In Procee-
dings of the 1995 ACM/IEEE conference
on Supercomputing (CDROM), page 43.
ACM Press, 1995.
[2] I. Banicescu and V. Velusamy. Perfor-
mance of scheduling scientic applica-
tions with adaptive weighted factoring.
In Proceedings of the 15th International
Parallel & Distributed Processing Sympo-
sium, page 84. IEEE Computer Society,
2001.
[3] I. Banicescu and V. Velusamy. Load
balancing highly irregular computations
with the adaptive factoring. In Procee-
dings of the 16th International Parallel
and Distributed Processing Symposium,
page 195. IEEE Computer Society, 2002.
[4] E. Cesar, J. G. Mesa, J. Sorribes, and
E. Luque. Modeling master-worker appli-
cations in poetries. In Ninth Internatio-
nal Workshop on High-Level Parallel Pro-
gramming Models and Supportive Envi-
ronments (HIPS'04), pages 2230, 2004.
[5] E. Gumbel. The maxima of the mean of
she largest value of the range. Ann. Math.
Statist., 25:7684, 1954.
[6] T. Hagerup. Allocating independent
tasks to parallel processors: an experi-
mental study. J. Parallel Distrib. Com-
put., 47(2):185197, 1997.
[7] H. Hartley and H. Dahd. Universal
bounds for mean range and extrema ob-
servations. Ann. Math. Statist., 25:8599,
1954.
[8] S. F. Hummel, J. Schmidt, R.Ñ. Uma,
and J. Wein. Load-sharing in hetero-
geneous systems via weighted factoring.
In Proceedings of the eighth annual ACM
symposium on Parallel algorithms and ar-
chitectures, pages 318328. ACM Press,
1996.
[9] S. F. Hummel, E. Schonberg, and L. E.
Flynn. Factoring: a method for scheduling
parallel loops. Commun. ACM, 35(8):90
101, 1992.
[10] C. P. Kruskal and A. Weiss. Allo-
cating independent subtasks on parallel
processors. IEEE Trans. Softw. Eng.,
11(10):10011016, 1985.
[11] S. Lucco. A dynamic scheduling met-
hod for irregular parallel programs. In
Proceedings of the ACM SIGPLAN 1992
XVI Jornadas de Paralelismo, JP '2005 449
conference on Programming language de-
sign and implementation, pages 200211.
ACM Press, 1992.
[12] B. L. Massingill, T. G. Mattson, and B. A.
Sanders. A pattern language for para-
llel application programs. In Proceedings
from the 6th International Euro-Par Con-
ference on Parallel Processing, pages 678
681. Springer-Verlag, 2000.
[13] A. Morajko, E. Cesar, T. Margalef, J. So-
rribes, and E. Luque. Dynamic perfor-
mance tuning environment. In LNCS,
Vol 2150 (Euro-Par 2001), pages 3645.
Springer-Verlag, 1002.
[14] C. D. Polychronopoulos and D. J. Kuck.
Guided self-scheduling: A practical sche-
duling scheme for parallel supercompu-
ters. IEEE Trans. Comput., 36(12):1425
1439, 1987.
[15] T. H. Tzen and L. M. Ni. Trapezoid self-
scheduling: A practical scheduling scheme
for parallel compilers. IEEE Trans. Pa-
rallel Distrib. Syst., 4(1):8798, 1993.
450 Tecnologías Grid, Clusters y Plataformas Distribuidas
                    " $ &   $    )  *        . 0 &
2        5   7      &  . ;
< > ? A C E G H I J L M > P C R I S S U L W > P I C Z J L [ > ] A _ A ` U
J b c e f h i k e l m l n h o p h e n m r t u m e p x y h i c m c n { } n e h e r ~ n p r h k  i { e  } h ~ ‚ r ~ n p r h k
U b c e f h i k e l m l … ~ l † c { u m n h ‡ m i ‰ h p { c m r t u m e p x m c m r i e ‚ { p p } ~ m ‹ r h k  h u e p e { r p ~ Œ ~ h } r ~ m ‹ r h k
Ž   ‘ ’ “ ” ‘
– — ˜ — ™ ™ › ™ œ  Ÿ œ ¡ — £ £ ™ œ ¤ — ¥ œ ¦ ¡  ¥ ¨ — ¥ — ¤ ¥ ¦ ¡ —
 ¥ ˜ › — Ÿ ¦ ­ œ ¡ £ ® ¥ ¯ — ¥ — ¤ — ¡ ² › › ´ £ ™ ¦ œ ¥ › ¯ µ œ ¥ ¨
¥ µ ¦ ¯ œ ¶ › ˜ › ¡ ¥ — £ £ ˜ ¦ — ¤ ¨ ›  ¸  £ — ¥ œ — ™ — ¡ ¯ ¥ › Ÿ £ ¦ º
˜ — ™ ¼ ½ ¡ ¥ ¨ œ  £ — £ › ˜ µ › £ ˜ ¦ £ ¦  › — ¡ › µ ¥ —  ¾ Ÿ — £ º
£ œ ¡ À — ™ À ¦ ˜ œ ¥ ¨ Ÿ ¥ ¦ › ´ £ ™ ¦ œ ¥ ¥ › Ÿ £ ¦ ˜ — ™ £ — ˜ — ™ ™ › ™ œ  Ÿ
› Á ¤ œ › ¡ ¥ ™  µ ¨ › ¡ ¥ ¨ ›  ¥ ˜ › — Ÿ œ ¡ À — £ £ ™ œ ¤ — ¥ œ ¦ ¡ œ 
˜ ® ¡ ¡ œ ¡ À œ ¡ — £ œ £ › ™ œ ¡ › ­ —  ¨ œ ¦ ¡ ¼ Ç › ¤ ¦ Ÿ £ — ˜ ›
¥ ¨ › £ › ˜ ­ ¦ ˜ Ÿ — ¡ ¤ › ¦ ­ ² ¦ ¥ ¨ — £ £ ˜ ¦ — ¤ ¨ ›  ¸ œ ¡ ¥ › ˜ Ÿ 
¦ ­ ™ — ¥ › ¡ ¤  — ¡ ¯ ¥ ¨ ˜ ¦ ® À ¨ £ ® ¥ ­ ¦ ˜ — Ê œ ¯ › ¦ ¤ ¦ Ÿ º
£ ˜ ›   œ ¦ ¡ — £ £ ™ œ ¤ — ¥ œ ¦ ¡ ¼ Ë ¨ › ˜ ›  ® ™ ¥   ¨ ¦ µ ¥ ¨ — ¥
¥ ¨ › £ œ £ › ™ œ ¡ › › ´ › ¤ ® ¥ œ ¦ ¡ ¦ Ê › ˜ ¤ ¦ Ÿ ›   œ À ¡ œ Í ¤ — ¡ ¥ ™ Â
 £ — ¥ œ — ™ £ — ˜ — ™ ™ › ™ œ  Ÿ — ¡ ¯ £ ˜ ¦ Ê œ ¯ ›  ² › ¥ ¥ › ˜  ¤ — ™ — º
² œ ™ œ ¥  µ ¨ › ¡ ¥ ¨ › ¯ œ Ÿ › ¡  œ ¦ ¡ ¦ ­ ¥ ¨ › £ ˜ ¦ ² ™ › Ÿ œ 
— ® À Ÿ › ¡ ¥ › ¯ ¼
Ï Ð Ñ
‘ ’ Ò Ó Ô ” ‘ Õ Ò
Ñ
Ö
¦ Ÿ £ ™ › ´ — £ £ ™ œ ¤ — ¥ œ ¦ ¡  œ ¡ ¥ ¨ › Í › ™ ¯  ¦ ­ œ Ÿ — À ›
£ ˜ ¦ ¤ ›   œ ¡ À ¸ Ê œ ¯ › ¦ ¤ ¦ Ÿ £ ˜ ›   œ ¦ ¡ ¸  œ À ¡ — ™ £ ˜ ¦ ¤ ›   º
œ ¡ À — ¡ ¯  ¤ œ › ¡ ¥ œ Í ¤ ¤ ¦ Ÿ £ ® ¥ œ ¡ À — ˜ › ¦ ­ ¥ › ¡ ¤ ¦ Ÿ º
£ ¦  › ¯ ¦ ­ Ÿ ® ™ ¥ œ £ ™ › ¤ ¦ — ˜  › º À ˜ — œ ¡ ¥ —  ¾  ¥ ¨ — ¥ — ¤ ¥
¦ ¡ —  ¥ ˜ › — Ÿ ¦ ­ œ ¡ £ ® ¥ ¯ — ¥ — Ù Ú Û Ù Ü Û ¼ Ë ¨ œ  œ Ÿ º
£ ™ œ ›  — ¡ › ´ › ¤ ® ¥ œ ¦ ¡ µ ¨ › ˜ › › — ¤ ¨ ¥ —  ¾ ˜ › £ › — ¥ › ¯ ™ Â
˜ › ¤ › œ Ê ›  œ ¡ £ ® ¥ ­ ˜ ¦ Ÿ œ ¥  £ ˜ › ¯ › ¤ ›   ¦ ˜ ¥ —  ¾  ¸ £ › ˜ º
­ ¦ ˜ Ÿ  œ ¥  ¤ ¦ Ÿ £ ® ¥ — ¥ œ ¦ ¡ — ¡ ¯  › ¡ ¯  ¦ ® ¥ £ ® ¥ ¥ ¦ œ ¥ 
 ® ¤ ¤ ›   ¦ ˜ ¥ —  ¾  ¼
Ë ¨ › ˜ › — ˜ › ¥ µ ¦ ¯ œ  ¥ œ ¡ ¤ ¥ ¤ ˜ œ ¥ › ˜ œ — ¥ ¦ Ý ® ¯ À › ¥ ¨ ›
Þ
® — ™ œ ¥  ¦ ­ — ¡ › ´ › ¤ ® ¥ œ ¦ ¡ ­ ¦ ˜ ¥ ¨ ›  ›  ¥ ˜ › — Ÿ œ ¡ À
— £ £ ™ œ ¤ — ¥ œ ¦ ¡  à ™ — ¥ › ¡ ¤  — ¡ ¯ ¥ ¨ ˜ ¦ ® À ¨ £ ® ¥ ¼ á — º
¥ › ¡ ¤  œ  ¥ ¨ › ¥ œ Ÿ › ¥ — ¾ › ¡ ¥ ¦ £ ˜ ¦ ¤ ›   — ¡ œ ¡ ¯ œ º
Ê œ ¯ ® — ™ ¯ — ¥ — ¸ µ ¨ œ ™ › ¥ ¨ ˜ ¦ ® À ¨ £ ® ¥ œ  ¥ ¨ › — À À ˜ › º
À — ¥ › ˜ — ¥ › — ¥ µ ¨ œ ¤ ¨ ¥ ¨ › œ ¡  ¥ — ¡ ¤ ›  ¦ ­ ¥ ¨ › œ ¡ £ ® ¥
â ã ä å æ ç è é ê ç ë æ æ í î î è é ï ð ñ ò ó ï ä ð ô õ ó ã í ö ñ ð é
÷
è ö ï é ë
÷
ï ã ø ù ú û û ü ý û þ þ ÿ ÿ ë ö ñ î ë é ï å ë

ó æ î è ö æ è é ð ñ ò ó
ï ä ð  ð ö ð é ë
å ï ë ï ñ ð õ ë ï ë
í ö ó ë   é í î ñ ð  ð
÷
ð é
÷
ë õ è ö ý
æ è
å ñ ë ï ú û û
   ý û û ú
ÿ  
¯ — ¥ —  ¥ ˜ › — Ÿ — ˜ › £ ˜ ¦ ¤ ›   › ¯ ¼ Ë ¨ › ¥ ¨ ˜ ¦ ® À ¨ £ ® ¥
¤ — ¡ — ™  ¦ ² › Ÿ › —  ® ˜ › ¯ œ ¡ ¥ › ˜
Ÿ  ¦ ­ ¥ ¨ › œ ¥ › ˜ — º
¥ œ ¦ ¡ £ › ˜ œ ¦ ¯ ¸ µ ¨ œ ¤ ¨ ¤ ¦ ˜ ˜ ›  £ ¦ ¡ ¯  ¥ ¦ ¥ ¨ › œ ¡ ¥ › ˜ Ê — ™
¦ ­ ¥ œ Ÿ › › ´ œ  ¥ œ ¡ À ² › ¥ µ › › ¡ ¥ ¨ › › ´ › ¤ ® ¥ œ ¦ ¡ ¦ ­ ¥ µ ¦
¤ ¦ ¡  › ¤ ® ¥ œ Ê › ¯ — ¥ — ¼

 ¥ ˜ › — Ÿ œ ¡ À — £ £ ™ œ ¤ — ¥ œ ¦ ¡ œ  Ÿ ¦ ¯ › ™ ™ › ¯ —  —
 œ ˜ › ¤ ¥ › ¯

¤  ¤ ™ œ ¤  ˜ — £ ¨  

  ¥ ¨ — ¥ œ  ¤ ¦ Ÿ º
£ ¦  › ¯ ¦ ­ —  › ¥ ¦ ­ ¡ ¦ ¡ º ¨ ¦ Ÿ ¦ À › ¡ › ¦ ®  ¥ —  ¾  ¼  ¦ ¥ ›
¥ ¨ — ¥ ¥ ¨ › ¥ —  ¾ À ˜ — £ ¨ ¨ › ˜ › œ  ¡ ¦ ¥ ¥ ¨ › ¥ ˜ — ¯ œ ¥ œ ¦ ¡ — ™


 œ ¡ µ ¨ œ ¤ ¨ — ¡ — ˜ ¤ Ë œ  Ë Ý ˜ › £ ˜ ›  › ¡ ¥  ¥ ¨ ›
­ — ¤ ¥ ¥ ¨ — ¥ ¥ —  ¾ Ë Ý ¤ — ¡ ¡ ¦ ¥  ¥ — ˜ ¥ œ ¥  ¤ ¦ Ÿ £ ® ¥ — ¥ œ ¦ ¡
® ¡ ¥ œ ™ ¥ —  ¾ Ë œ ¨ — ¯ Í ¡ œ  ¨ › ¯ ¼ — ¥ ¨ › ˜ ¸ ¥ ¨ › ¥ —  ¾
À ˜ — £ ¨ ¨ › ˜ › Ÿ ¦ ¯ › ™  — ¯ — ¥ — £ ˜ ¦ ¤ ›   œ ¡ À £ œ £ › ™ œ ¡ ›
œ ¡ µ ¨ œ ¤ ¨ › — ¤ ¨ ¥ —  ¾ ˜ › ¤ › œ Ê ›  £ œ › ¤ ›  ¦ ­ ¯ — ¥ — ¸ £ ˜ ¦ º
¤ ›   ¥ ¨ › Ÿ — ¡ ¯ ¥ ¨ › ¡  › ¡ ¯  ¥ ¨ › £ ˜ ¦ ¤ ›   › ¯ ¯ — ¥ — ¼

µ › œ À ¨ ¥ ¦ ­ — ¡ ¦ ¯ › œ  ¥ ¨ › — Ÿ ¦ ® ¡ ¥ ¦ ­ ¤ ¦ Ÿ £ ® º
¥ — ¥ œ ¦ ¡ ¥ ¦ ² › £ › ˜ ­ ¦ ˜ Ÿ › ¯ ²  ¥ ¨ › ¥ —  ¾ £ › ˜  œ ¡ º
À ™ › ¯ — ¥ — — ¡ ¯ ¥ ¨ › µ › œ À ¨ ¥ ¦ ­ — ¡ — ˜ ¤ œ  ¥ ¨ › ¤ ¦ ˜ º
˜ ›  £ ¦ ¡ ¯ œ ¡ À — Ÿ ¦ ® ¡ ¥ ¦ ­ ¤ ¦ Ÿ Ÿ ® ¡ œ ¤ — ¥ œ ¦ ¡ ¥ ¦ ² ›
¥ ˜ — ¡  ­ › ˜ ˜ › ¯ ­ ¦ ˜ ¦ ¡ › ¯ — ¥ — ¼ Ç › —   ® Ÿ › ¥ ¨ — ¥
¥ ¨ › › ´ › ¤ ® ¥ œ ¦ ¡ ² › ¨ — Ê œ ¦ ® ˜ ¦ ­ — £ ˜ ¦ À ˜ — Ÿ œ  ¡ ¦ ¥
 ¥ ˜ ¦ ¡ À ™  ¯ › £ › ¡ ¯ › ¡ ¥ ¦ ¡ ¥ ¨ › Ê — ™ ® ›  ¦ ­ ¥ ¨ › œ ¡ £ ® ¥
¯ — ¥ —  ¥ ˜ › — Ÿ ¼
Ë ¨ › › ´ £ ™ ¦ œ ¥ — ¥ œ ¦ ¡ ¦ ­ £ — ˜ — ™ ™ › ™ œ  Ÿ œ ¡  ¥ ˜ › — Ÿ œ ¡ À
— £ £ ™ œ ¤ — ¥ œ ¦ ¡  ¤ — ¡ ² › ® ¡ ¯ › ˜ ¥ — ¾ › ¡ µ œ ¥ ¨ ¥ µ ¦ ¯ œ ­ º
­ › ˜ › ¡ ¥ — £ £ ˜ ¦ — ¤ ¨ ›  ¸  £ — ¥ œ — ™ — ¡ ¯ ¥ › Ÿ £ ¦ ˜ — ™ Ù ! Û ¼ ½ ¡
 £ — ¥ œ — ™ £ — ˜ — ™ ™ › ™ œ  Ÿ › — ¤ ¨ œ ¡ ¯ œ Ê œ ¯ ® — ™ ¯ — ¥ — œ  ¯ œ º
Ê œ ¯ › ¯ œ ¡ ¥ ¦  › Ê › ˜ — ™ £ — ˜ ¥  — ¡ ¯ › — ¤ ¨ £ — ˜ ¥ œ  ¤ ¦ Ÿ º
£ ™ › ¥ › ™  ¦ £ › ˜ — ¥ › ¯ œ ¡ — ¯ œ ¶ › ˜ › ¡ ¥ £ ˜ ¦ ¤ ›   ¦ ˜ ¼ ½ ¡
¥ › Ÿ £ ¦ ˜ — ™ £ — ˜ — ™ ™ › ™ œ  Ÿ ¥ ¨ › — £ £ ™ œ ¤ — ¥ œ ¦ ¡ ¤ — ¡ ² ›
¯ œ Ê œ ¯ › ¯ œ ¡  › Ê › ˜ — ™ ¥ —  ¾  ¥ ¨ — ¥ — ˜ › ¯ œ  ¥ ˜ œ ² ® ¥ › ¯
— Ÿ ¦ ¡ À £ ˜ ¦ ¤ ›   ¦ ˜  œ ¡  ® ¤ ¨ — µ —  ¥ ¨ — ¥ ¯ œ ¶ › ˜ › ¡ ¥
œ ¡  ¥ — ¡ ¤ ›  ¦ ­ ¥ ¨ › œ ¡ £ ® ¥ ¯ — ¥ —  ¥ ˜ › — Ÿ ¤ — ¡ ² › › ´ º
› ¤ ® ¥ › ¯ ¤ ¦ ¡ ¤ ® ˜ ˜ › ¡ ¥ ™  ¼
½ ¡ ¥ ¨ œ  £ — £ › ˜ µ › ­ ¦ ¤ ®  ¦ ¡ › ´ £ ™ ¦ œ ¥ œ ¡ À ¥ › Ÿ º
£ ¦ ˜ — ™ £ — ˜ — ™ ™ › ™ œ  Ÿ ²   ¦ ™ Ê œ ¡ À ¥ ¨ › Ÿ — £ £ œ ¡ À £ ˜ ¦ º
¤ ›   ­ ¦ ˜ £ œ £ › ™ œ ¡ › › ´ › ¤ ® ¥ œ ¦ ¡  ¼ Ç › £ ˜ ¦ £ ¦  › —
    

                 
 #
 %


    #
   
+   -   -     %  
    2          4     7     9  
2  <    ?
              # # &  '    (   +    -  ' /       2
      & 3    #  #  &    8   +  (  ; =  >    # #  
( 8    B   ( #  ( '    (    +         H   &     ' 3
L +  &       8 3         +  ( / + # /  ' (        
@
%    B   4       7
 #
 %   4   -   
 2  -     -     7  2   2       -     


     <       4      
2      2 -  M
        -   2   4 2      @ P    
 2 
   
 2 7  2     
 2     2      
<      4   9     +   -     

    
9  
  
 2        9     <     9 
 
 2  
 2        <       

     +  M
 -   -          

 
2  4    <   

 #
 %     2   @ %   2   -      9  
 

     +   -      <   2      <  
           2  -  
- 9          M
    7  
2  <      -       @ g       7
  h 
  
 2       +   -   
2         M
 <  
2  <        9  2   2   -    7      
    2  -  
- @
%   2              2   2    Q     7  M
   9  @ %  
2 
     

      2   7  2
 2      

      
2        R    
m @ R     S    9     +
 2       2   -  
  9  2   <     7  2  4      
2      
M

     2 -          -   2  7 9  2       @
T      h R     W  -               - M
    @
X Y
p Z Z q
r \
p ^
\
s u q w _ `
%    

      2     9 
2 
   
 

 2       
 #
 % 

   
#
   
+   -   -     %       2     @
g           z     -   2   7      @  @
 2  -
  7      h      7  2       2    - 
     9    4    2   
 2   h  
 <  
 7 2 -      4  2  

   

     7     
<     Q           7  2       4  -  
   @ T      h        7       -   2 9   < 
             
2       2 @ %    2    
9       9 -     4     +   -   9    4  
 2  -  
-       -        @
%    

      2    <        
 
    2   +
    <    9 h 9     2     -
-            +  
        2 
     
 7 T  - 2  ~ h   2  
 
      2 -  - 2   7
    
4      2
2        

     @ %  
  
-       7        c d e f g   + M

2                     @ %       -    M
       <  9               %    %  h
      i d e f j e k g h  2       +
2         @   
    2      -       i d e f j e k g l n o p i r s h
9   2  n o      2 -
  7  2        
2         h i    2    7  2    7    M
   <      s     -  <  2  7 <     < 
2       @ %    

      4   7  2   4  
 2   
 2    7 u v   @
w
€  ‚ ƒ „ x … y † ‡ {  ƒ † ˆ | ‰ Š ‹ „ Œ Š  † ˆ € ˆ „ Œ € Ž „ † ˆ ˆ Œ €  † }
 € Š Ž ‘
~
  #  € ‚ >     = '    (  ( 8  & & >  „      #   + 
   +  #  #  €
R  2   7 2     

         2 
 h   
   B  2  
    2     z   @ T  2    

  h     2 2  
     ‡ ˆ o ‰ Š o f ‹ Œ 4   -  
    -     h 9      2 2  
          -  - M
      
-           -        
7  2            
  @
‡ ˆ o ‰ Š o f ‹ Œ l 
Ž   ‘ ’ “ ”
c d e f g p 
Ž  • Ž –  ‘ ’ “ ”
i d e f j e k g
—
   
    2   2   2           M
 2       2   2  7 ‡ ˆ o ‰ Š o f ‹ Œ @ %  
2  2 Q  
 z     -   2   7              4  

             
’
-         Q    M
    @ T  2  +  
  h   z 2 
       
9   <  % ~ ™ % S ™ % W ™ % › ™ % u ™ % œ h
9  ‡ ˆ o ‰ Š o f ‹ Œ  ~ u v   @ #     2  -
   
   7     9    
  7       2   h < -
    2    9     4   -        2   2  4  
<      @
~
  # ž €   (  # (    3  ' +  (  ( /       €
g     
    
         2  M
    R 
~  2   +        2   2    M
 2               2     -        
452 Tecnologías Grid, Clusters y Plataformas Distribuidas
           
   
   
      
 "          (        . 0 0 1         (
   1      .       9 0    (   9    
    9         9    0       
B
 0
      E            (  H     I     
1      . 0 0 1  0          9 
   
   

   L   .      (    (        
(     !    L  H  1 0  R   .    (  E  
0   9     V      V     "       V
    \  9  0   ]     1         V    
"   E  0    (         1      H R  H $ 
       9 0    (   9        9   V & '
9      
B
 0       E           
 (  H     I H R   ( H $ . 0 0    
 0 (  ( 
   
  ) 
 H         9    V
     \  1      H ,  H -  H &  H .  0 1 9  
     0  0                  (  V
& ' 9  H       V    I     0 (  ( 
   
  2 
 ]    .        0     9  E  
0     0 0     9          V    0    (
"   0 0  ( E (             .        
    n
   
  ) 
4 5 H R  H L  H $  H ,  H 1 7   (
   
  2 
4 5 H -  H 0  H &  H . 7  ]      1 
    (     (     (         E  0    (     
    9    I    1  0      ( q       
          ]             I 1  0   
                .   0  .    (  \ 
s    V  0 0  .       0     9         
.     I H ,   (   I H 1        0 0    
   
   
  2 
 1  "   0 0      1  0   
 
   
  ) 

H  1 0  R n
t
 9       V         V       
8 9 : < = > ? @ A B C D F 9 H H I H K L N O P L R S U V
W
> Y Z > [ Z Y > Y @ \ ] \ ]
W
> Y _
> ` Z > b Z > [ @ b ] c ]
W
> Y Z > [ _
> c Z > d _ \ > ` @ Y ] Y ]
W
> ` _
> b @ [ ] ` ]
W
> ` Z > b _
> c @ \ e b e
W
> ` Z > b Z
> c _
> d @ Y ] f e
W
> ` Z > b Z
> c Z > d _
g
 h j k l o     q  q s t u v  w    w
z 
 k
H     (    "        I  V     9 
   
   
       1      (      0 
   V   I    (       
B
     1  9     (
        9        ]         0 0   
         (  !    R    \  9   (    (
      9   9          (    ( .     
{
v w x y
z
{ | y } { ~  } { x } ~ € }
~ ~ 
‚ ~ ~  w € } } y € ƒ v
{
} { x | y } {
€ „  ‚ € } y ƒ x „ ~ … ~ € „  ‚ € } y ƒ x „ ~ … ‡ ‚ ~
y
z z
‚
z
v ˆ | … } ~ Š ‹ Œ Ž 
‚  ~ € …
z z
x € € v w } y € ƒ v
{
‚ ~ ~  } { x | y } {
† { ~ } x  v } x  ‡ v
{
| y } {
† { ~ } x „ y
z z
‚
z
v ˆ | … } ‘ Š ‹ Œ ’   “ ~ } x w y } ~ v  | x w ~ v ‡
y  ‡ ‚  ”
•
‰ – — —
~
{
„ ‚  ˜ € „  ‚ € } y ƒ x „ ƒ … y  ‡ ƒ š ~ } { x 
€ „  ‚ € } y ƒ x „ ƒ … ~ € „  ‚ € } y ƒ x „ ƒ … Š › ‚  
€ „  ‚ € } y ƒ x „ ~ … ~ € „  ‚ € } y ƒ x „ ~ … ‡ ‚ 
y
z z
‚
z
v ˆ | … } ~ y
z z
‚
z
v ˆ | … } ‘ Š ‹ Œ ’ 
‚  ~ € …
z z
x € € v w v
{
‚  ~  } { x | y } {
x  ‡ ‚ † { ~ } x
~ ~ ~ ‘ 
y
z z
‚
z
v ˆ | … } ~ ‹
x  ‡ ‚ † { ~ } x
x  ‡ ‚
{
v w
Ÿ
Œ  Ž   ¡ ‘ ’ “  ”  Œ • ¢ – ˜ ”  Œ ™  š • Œ ˜ ¤ Œ š  › ¤ š œ ¢  ” š ” Ž ›
› •    › ¦ •  ž ¡  Ÿ
     (  0          E        
H     0  
t
   V             
 0    I    0    V   I 
]  9                        
 (         0  V  9    L 1     
           ©      V  9  0  
 (                   (      
              \       H   
      "    (    V            
    .       E     
   $   .      (    (       0 E 
!    $  H   (  E  0   9     V      V    
"       V          .   H  1 0  L  ] 
   1         V           I H R   ( H $
   V  9   0    ( 
   
  ) 
.    
      9   E  0   V & ' 9    (   I H -  H &
  ( H .    V  9   0    ( 
   
  2 

          9   E  0   V - 1 9  0 
                (  V & ' 9 
«
V    E  0 
     0 0         .   1       V  0 0  .  
 0   n ] 
   
  ) 
.    E   H R  H $    (
 H L  H ,  H 1    ( 
   
  2 
.    E   H 0 
  (  H -  H &  H .      ,   .     .    
         (    "  (  !    L  V     0 
    9   (     0    V   I         
 1     (  V      0      !    $ 
g
 h  k l o     q  q s t u v  w    w z 
 k
]   (    
B
0 1         9      
 9                 (    "    I
 0          1    9    ( 1   .      
XVI Jornadas de Paralelismo, JP '2005 453
  


 
  

  
       

             
  


  

  

        

          
  

     
  

     
 

 



   

     
           %    
 
   

      

  

         %   
 
  
 



         "      
   

     

     $ %  

 



  
 



    %   
   
 

  '   

  ' $

    
 %   -
. 

      %  

 



       
    
    
        


     -
. 
 

  '   

  ' $

    

  

     
  

     
    
    
    
2
. 0 1 2 3 # 4 6 8 0 9 2 . : 3 ; = 9 2 % @ A . @ 0 C 8 1 D : 3 2 D 9 = : H D 4 D
. @ D . A 3 D 5 @ C 3 2 9 @ 9 1 D D : H 0 3 D 6 ' : 3 L # ) M
2
. 0 1 2 3 * 4 ' 5 @ C 3 2 9 @ 9 1 D D : H 0 3 D H @ A C 8 1 D : 3 2 D 9 = : H D 4 D
9 O : H . @ 3 A . @ 3 H C 3 D : H 0 3 M
R S T V W Y Z
[
\ ] _ \ a b d b \ e \ f h V i a d W k a b e a m e o
h p k \ e \ i a a d S q W a r
7 9 : < , . = , . > ? 9 @ @ A @ / 0 1 : 2 4 5 9 6 6 A
C
D E F D G F D E ? H I 7 H I D E
D K F D L F D G ? L I M I D E F D G
C
D E F D G O
D M F D P O D K ? E I E I D K
C
D E F D G O
C
D K O
D L ? G I 7 G I D L
C
D E F D G O
C
D K O
C
D L O
D M ? H Q Q Q D L F D M
C
D E F D G O
C
D K O
C
D L F D M O
D P ? E I L Q D L F D M F
C
D E F D G O
D P
C
D K O
C
D L F D M F
D P O
h p k \ e \ i a a d S q W a b e d p W a S ] W _ S d p r
R
V V d p W
_ S d p a \ T d S b e W v b e d p W _ k W y b \ i a a d W _ S k W W y S o
V i S d W v f k \ ] d p W b e b d b S V d \ d p W W e v h V i a d W k r S \ k
W S h p h V i a d W k
[
} b b e d p W V b a d \ f _ S d p a  € W h \ ] o
_ i d W d p W a i h h W a a \ k h V i a d W k a f \ k € p b h p d p W S h h i o
] i V S d W v h \ ] _ i d S d b \ e d b ] W b a V W a a d p S e \ k W
„
i S V
d \ U V W 9 X V U ; = Y Z W 9 U ; > r … e d p b a h S a W  d p W h V i a d W k a
€ b V V T W q k \ i _ W v b e d \ S e W € \ e W r S b q i k W \ a p \ € a
d p W S V q \ k b d p ] _ a W i v \ h \ v W a \ V y b e q ^ d W _ ` r
= 9 2 3 H C 3 L H : 3 . @ : 3 3 8 . D :
1 L A H : 3 L H : 3 @ . : 3 @ 3 @ C 8 1 D : 3 2 D A 3 % @ . : . 9 @ D
A
ˆ . C . @ . : . H 8 L H : 3 C 8 1 D : 3 2
@ 3 . 8 3
A
ˆ . E
F
% @ H 8 L H : 3 C 8 1 D : 3 2
H C C G C 9 ; L 1 : C H
C 8 1 D : 3 2 C I
@ 3 . 8 3 6 H C C G C 9 ; L 1 : J K 6
A
ˆ . ) M . : 3 2 H : . 9 @ L 3 2 . 9 A
H @ A
A
ˆ . 3 H D D 1 C C 3 D D 9 2 D
H C G C 9 ; L 1 : C H C G C 9 ; L 1 : J K 6
A
ˆ . )
C 8 1 D : 3 2 C C 8 1 D : 3 2 N
A
ˆ .
A
ˆ . C D 1 C C 3 D D 9 2 9 =
A
ˆ .
3 @ A G @ 3 . 8 3
; H L L . @ 0 C ; H L L . @ 0 N C 8 1 D : 3 2
3 @ A G @ 3 . 8 3
3 @ A G = 9 2
2
. 0 1 2 3 R 4 6 8 0 9 2 . : 3 ; = 9 2 A 3 % @ . @ 0 C 8 1 D : 3 2 D 9 = : H D 4 D
O 3 : @ 3 3 @ D : H 0 3 D 6 ' : 3 L * ) M
R S T V W c a p \ € a d p W W y S V i S d b \ e \ f d p W ‹ k a d d € \
_ S d p a r … d h S e T W a W W e d p S d d p W e W € h V i a d W k
d R Y  R `  R \  R e f T W d € W W e a m e h p k \ e \ i a a d S q W a 
S e v Y b a b v W e d b ‹ W v T W h S i a W d p W S h h Y h \ ] _ i d
h \ k k W a _ \ e v b e q d \ d p W h V i a d W k a d R Y  R `  R \ f S e v
d R e f p S a S y S V i W \ f h i ] a r d p S d b a W
„
i S V d \ d p W
k W
„
i b k W v b d W k S d b \ e _ W k b \ v r S b q i k W l a p \ € a d p W
d S a “ q k S _ p \ f d p W W • S ] _ V W € b d p d p W h V i a d W k a
\ T d S b e W v S f d W k S _ _ V m b e q d p W _ k \ _ \ a W v e W € S V o
q \ k b d p ] S e v d p W k W a i V d b e q ] S _ _ b e q \ f d S a “ a d \
_ k \ h W a a \ k a r ˜ p W e W • W h i d b e q d p b a d S a “ S a a b q e o
] W e d b e S h V i a d W k \ f € \ k “ a d S d b \ e a f \ k S e b e _ i d
v S d S a d k W S ] \ f  i i b e a d S e h W a  € W \ T d S b e W v S e
S y W k S q W V S d W e h m f \ k \ e W v S d S \ f  l \ ] a r S e v
S e b d W k S d b \ e _ W k b \ v \ f e c r e ] a r
T
œ  ž Ÿ V Ÿ   ¡ ¢ W £
¤ Y
£ ¢ V ¥  ¥ n p ¦ V Ÿ Ÿ £ ¥
¤
… e d p b a a W h d b \ e € W h \ e v i h d W v S e W • _ W k b ] W e d S o
d b \ e _ k \ h W a a b e \ k v W k d \ a p \ € d p W S _ _ V b h S T b o
V b d m S e v d p W T W e W ‹ d a _ k \ y b v W v T m d p W _ k \ _ \ a W v
454 Tecnologías Grid, Clusters y Plataformas Distribuidas
   

                       # 
%  &     &      / &  1

    

  
          

    

     " # " #

    

 %   '   ) 

 *   "   + 

 %   '  * # * #

 %   ' 
 )   ) 

 *   "  * )  % )

 *   " 
 +   + 

    

     " # " #

    

 %   '   ) 

 %   '  * # * #

 %   ' 

 -   )   ) 

 *   "   + 

 -  % # " #

 %   ' 
 )   - 

 *   "  * )  ' )
 + 

 *   "  * ) * )

 *   " 
 +   + 
/
2 4 5 7 8 9

: 5 ; < 8 7 8 = < @ ; 1 4 7 @ B 3 @ D < 8 7 @ B B : 4 2 E 4 G  6

G  8 @ : 4 I 7 2 < 3 K @ E = < 3 8 7 8 ; 5 : < 2 E 4 K @ B B 2 E 4 N
    /  P   P   /   #   /  / & S &  U    V  W S   
&      /  P  S   /   U /      / W   /   /   W  S &   
  /        1 \    U     U  / U   W      & _
& /       / W   /   a   &  U       /   S  W  /   &
     d 9 : _ e  S   _    /   / U   W      & & /  
  P   /   1
 &        / U        & /   d 9 : / &   _
W  U  U /  & / U  :   S  &   d / W  S   & < :  d = 1 9  W
      &  U  W  U /  P  /   &          /     
  P /   /  P   /  & W     &    U /  P :  d 1      
U  %   U       U   &           W  U /  P
o a d
  U  1 o      &      W  U  U /  U     U     q  
         & /    & 
s
S   W  a # /   d   U 
     &      W  U  U  & U / t     W  &         
 #     /  S & <   & S  & 
s
S    =        W       & 1
 &  U / t     W  &        /   U /     /    &  / _
   /     U W      & & /     W  /
s
S  & w  x 1  & 
       W  U /  P U     U   W /  &  S   /    U   
U     U   W /  &         W  U   1
   /  &    &               U / 
 d 9 : _ e      W /   P                 # _
/  P w ? x

€ 1  9 <    /   9 &  /    /   = a #    /  / &

  S  U   U / &    W          W S     
           /  S
&    S  S          W 
     1 / & / & /  U / W    U /      /    W _
   1
e 1 
ˆ
<    /  
ˆ
     &    U = 1 / & / & 
   U / W  /   &    /  # / W      /    W _
   / & S &  U     W   &   S W       U / W   U
     1     U / W   U      / &    W   _
    U # /      / P /           U     _
 /        U / W  /        1

1 
ˆ
<  / & W    
ˆ
 & /      &     = 1 
   U / W  /        / & W      & &  U 1
 1    ‹
ˆ
<  S    / D   /       /     ‹   P 
ˆ
 U  & = 1     /    W    &    W   _
 /   U # /    
ˆ
/        /   a   q
       &      U    S P
s
S    / D   /     U
%     q   q    W  U / %  U S & /  P    /    
‹   P 
ˆ
 U  & 1
o   / & #   Ž a #     %   U    V  W S  /    
  & 
s
S    /     P   /      d 9 : _ e   W  U   1
F    / &  V  W S  /   #  S &  U  W    S    # / 
 d    / S  o     W  & &    S   /  P   € H I I  % D
# /  ? € e   q   &   L
M
 1 / &  V  W S  /   q /   U
    S P  S    I 1 O ?      &    W  & &  U    &  _
W   U a   U       P       W q             
€ 1  ? &  W   U & 1
  S P      %   /        /   #    _
  /   U   W    S    /    /   & W     &    U /  P
    &  &    &        #  U S &     U    
  & Ž P    W     &    U /  P    / U   W      & _
& /       / W   /   1      &  # &    V  W S  /  
 /   a /  &  W   U & a    #  &    & S   U     
U / t      &    &    d 9 : _ e   q /  P   & / D   
       &        W  & &  U 1 9  W & / D  W   _
  &    U &      S        / V   &    # /    
 & /  P           /   P       #   /  / & U / _
/ U  U /  )     & 1  & / D        / P /    /   P 
/ & < O e I V ? O T =  / V   & 1
\ /    &     & S   U W    S    /    /  
  S  & a #    U     U       / W   /   /    U  
     V  W S   U # /     #       # /  P     &
          / & 

U V W
X
Y V [ \ V ^ Y V _ V ^ ^ a ^ \ b c e
9  W      / & &    /    q U / / U  U /  )     &
         W  & &  U /          S  U    
  &    _ #   Ž       U / P   & /  / & /   S &      U / 
XVI Jornadas de Paralelismo, JP '2005 455
   
                        #    & 
 #
(   * , #  /           4       6
7 8  
9 :   ; :  = >  > ?  ? @   ?
A B
D  A F F D  A
D  D   D  D   D  D  B
G  F D   G G D  D F D  D D
D  D A A D  D D 

 A D  
D  D B D  D D B D  D D F D  D D

F  D   A D  D A D  D D A D  D D
D  D D 

G   B
D  D  D  D D A D  D D B D  D D 
A G B D  A G D  D  D  D D  D  D D A D  D D 
  4  /      6 I   I            L  N   
   I      /    /    &  /          I          
 #
(   T       & /       X  Y X  Y X  Y 6   /
   I # /      I       /    ^  T        
&  /        T  /     I &  /     L  / ^  /    ^
L I  &  / #  /    I         &        L   I
 I 
 

e
  
e
#         6 I     I 
L  / ^  /  /    /   I   / & /       &  /     I 
     /  L I    / /        I     n
e
   &  
   &      I  /      6

  I  T    # /    
 #  I    &     /    I  T      & /        
 I   /  / /  T    /  /   4   I   ^    # &  /        
   N     L    &  /          I            #  I 
 w  /     T        #     4   # /    6
{ | } ~ €   ! ‚ ! # ‚ ƒ … € ~ # % † ~ % € ~ ƒ … ~ } ‡ … } ~ € ˆ ! ‰ ! ( ‚ ƒ %
‚ ƒ ƒ { | Š ‹ € Š … ˆ
* ( , ) . 0 2 3 4 6 7 6 9 ; < 2 6 = ? 6 7 2 6 4 6 7 7 . 7 ? < 0
* 2 ? 2 . 7 ? 9 . ,
I   & &             /     /     T     &  L   I
/  &             I                  / /     N
   &  &      #   I           I  L      4  / 
F    #  / #   /      6
{ | } ~ € *  ! ‚ ! ( ‚ ƒ % | ~ ‚  I ƒ … ~ } ‡ … } ~ €  † ~  {  € ‘ { Š € ˆ
! ‰ ! ( ‚ ƒ % ‚ ƒ ƒ { | Š ‹ € Š … ˆ
’   I   /      &  I     4  # /      & /  *
            &       N  T           6
I       I     & /          w  /    &  /   #
 I     4  L   I  I   I /      ^ 
 

e
 

e
6       N   I  & /          4   T      
 /  ”        I         & L I  /        / /  
    I     n
e
#        6 –   I  I   &  &     
  /     /      &  /   &  /                & &   
   w  /       4    /          & /      
     / /     N 6    / / N     I      4       #
   ^    & /       /  L      I   N (  P   *
4  /   I  & /  &       I   &  &  / 6 ’     I    
 I  / 
˜
  /       #  I /   4 I &    I   L    & *
&       I    & &   4 & /        / /   &     
 I     /      &  /   4  T    N  I     &       
     #    ^
   I      I      I   T        6
  4  /  F     I  L   I    / /   &     4   & &   4
L I    I   & &         I   #   /      6
–   I  I   L  & /  T           #  I  T   
   & /        & &         L    / /          *
&  /              /  /    T        I  &  / #  / *
     &  /      /   #       N    I /   4 I &  
 I    /  & /  T    N    I    6 I    &  
  /        & /       I 
R R T    # /    
     I     6 I            L  /    / /     
   I            # /    L  / ^ &


( X F Y  L I   I
          I            #      4  * &      4  & *
&               /       N      6 I     / *
 N   4  N     L          N      4    
 # I    4           L   I  I       I  /   *
456 Tecnologías Grid, Clusters y Plataformas Distribuidas
    
                 

     !  $  %

    (
      
   
  / 0  2  
/ 4 
         (

       ! ! 0 8       %   /  

  ;  >   

    ;   @   ;  ( >    4 4 !   
           !
E
F  % 
    !   I       ;  !  %
   4  
   ( N     
        >    ;  !   
   $ 
    /    R       
    
!      
>   T       (
  I   
   >  8   !  I     ; 

 !  8  
    I  4    >    /      >     $ 
 %
  I    4 4 ! 
    >   /   4    ! !  ! ;    ! 
R   0   I     ; /       R          
    ; 
     ;  $  ;  ;     I  4   
  !  / 
     
 ! ! 0 
   R  / !  (

_ ` a c d  e  c f a `  g a h i


  /   /    R   8 4  4  !     $ 
     
 / !     I   m
  ! 0  R  
 ;     4    ! 4   %
 ! !  !  $ 
    ( p             
 
4  4  !     $ 
     $ 4 !     ; 4    ! 4    ! %
!  !   ;  ! !  >   I  
 
      $ 
     
  R    !  ;  I        ;   ;  ( p     !  
4   R      I    
 !  /  !  0   4  4  !     $ 
 %
    8           I  4     
      I    
  ; /        ;    R           !   I   >   I  4 (

       ! ! 0 8    /          I  4       
4  4  !     $ 
       ! !  >     ;      
0
     ;  $  ;  ; 
   R  / !  (   >  R   8  
  y    
 >     ;  $  ;  ;     I  4  /  %

 ;  I      >        ; /       R        
 
      I 8 / 
       4 4 ! 
        m   
I     !    0       R        
 ; ;   
 %
        0   ; ;    I  ;      ;       %
 
      $ 
    (
N        4  4  !    8      $ 
    >  
 4    ! 4    ! !  !   ;       I  4      
   
     >    ;          R         
    ( p   ;    
  T     ;    I  ;   

 ; ;   
     >     >   T          

    /  4      ;        ;      >  

>   T   
 ; 4      
     4      I  ;  I 
4   (

 
   

  
 8 >   T   
    / 
4  
     I  !  I       4    ! !  ! (

       ! ! 0 8 >   R  !        $ 
    !  %
 
0        I !     ;         >      %
I    2  ( F  4  !     $ 
     !   4   R     /  %
  !   
0 R  !        4    ! 4    ! !  !   ;  
 ! !  
    ( p      / 
      T
 ; ;   
 %
       !         4  4  !           4     
  
  / 
       
 
     ! 0 ( N     
    8      4    ! 4    ! !  !  $ 
      

 ; ;   
       
    !         ;    
  T 8  y 
  I   I   R  ! 0     m   ! !   
0
       / 
 ;    / !     2 @  ;  I    %
R       (

_ ` a c d   e } ~ h d  €  i

    ; ;   0      $ 4    ;        
> 
        8 >       4  4  !     $  %

    
  /    I  /     I   m
   ; 4   R  %
;    8 >      4 
  4    ! 4    ! !  !  $ 
 %
      !   
0        I  4  >        %
  
        4      ;      4      (   %
!        $ 
       4  4  !           8  
4   4     ;  4 4   I  ! I     ;   F   p   
/       >   /   I        I 0       
 
   R   0 
        $ 
      4  4  !   
  4    0   !       ; 4   R  ;        4   %
   ;  
 4    ;     (
XVI Jornadas de Paralelismo, JP '2005 457




  




              "     &    )      - )  0     
    -  5     -  7  8 -       8 8  8   <        <   &
   8  5    -   @       8   )   <  -   8 D F    - G
 -   )     <      & <  5      < 5  8 8  )   G
J   L  - N     8   )     <  -   8     8 8  8   <
          8  5    -     U     &        8   
V     -  D   J   L 5       - U     <      &
       & -  8 - V  5    "   &  &  "      - U &   U 
  ) <    <     &    8     5 ^ D
L    0  5   "      - V     8     7  5 U   -      
      b     &  <    - V   J   L    5 - < G
    )              8     8 8  8  7  5 U   -   V - 
 "  )  - 5 - <       -     8  5    -  D L    7  5 U G
  -       5      ) - U  N ^   < U 8    -  "   ^   &
    U < N   - V )  "    -   - V     <  &  V   <  
          - 5     )       8 8  8 D L      U 8  
  )   -          8 8    5         8     7  G
5 U   -   ^   8 )   &   k 5    8 ^ N      "  8 U   - V 8  G
   5 ^   )    - U &   U  l N  5  U      ^     N 8 
 -   - 5    5 -  5 U      8 ^ )  0       <  &  V   <   D
L      b     &  <    - V   J   L V  5  8      )
    ^  5   -  - U   7  5 U   -  - V    b    )  0     
   &       5 -     N U   )  -     5    "  <    - V
        U 8       <  -   8     8 8  8   < D

   q 


  
r s t

D
u
 - U )    ^ l F D
D w   - l  D F      l J D
       ^ l  D w   )   <     ) D w   )   G
<   @
       " $    ' ) '  -  )  0  2 ) $ 4 ) 6
'  -  - 8  ) : ) $ $  $   "  $    0
>
   -   ) : ) $ $  $
A - " 4 '  :  C
J  - 5 D s y  
  D J    8 8  8 J  - G
5      & D ^ <  -   U < D E 8 -   )  D J  D y y F G y y G D

   8 s I I J D
r y t D    & l L D K   )   l  D
   U   l w D
u
-   -  l  D
u
 <     )  D 5
u
  ) G
8    @ !
 ) $ 6    $ &  ' ) Q $    '  Q '  - 
>
T  ' 
8 - : (   V 6
>
"   0 A  2  $  : )   " - : '
>
4 "  :  -   Q
  : Q : ) 8 '
l J  - 5 D
   [   + 8

  -  5 -     )
 8  5   -   5 
u
-  V   
 5  D  5  D y F F F D
r \ t
D D      )  D  D   8  @

>
" ) '  ) $ 6
  " - : ) $  ) : ) $ $  $  " " : - ) Q V 8 - :
!
 ) $ 6   
.
  0 2  0  - A - " :     - 
l J  - 5 D

u
J J G
s I I b D  - 8 D y D J  @ s F F G s F c D s I I b D
r d t  D 2    b       )
D
-          )   @
 6
)   )  0 4  0  - A - " :     - 
>
' )  0 ) : 0  6  $ 6
 - :  ' V  )  0  : Q V  '  Q ' 4 :  
l
8 U   

5  ) G
)  <  5 J U N D i   5 -  )  ) D j s I I c D
r G t
D

 <  ) l  D 9    ) D w D w  - U @
4  0  -
A - " :     -  k  ' V  ) : ) $ $  $  : - Q      
l J   G
 8 8  8
u
- <  U    & D  - 8 D y J J  @ s F \ I G s F c J D
y F F y D
r b t D D 2 -  < b  l D D  D J D F      l  D w D w  &   )  ~ b
  )  D 2   < -  ) @
 ) : ) $ $  $  $  - :  ' V  8 - :
.
  0 4  0  - A - " :     -  k  ' V  4
. l
  D
u
-  V D 9 J
u
[ 5   8 8   &       8  5 - <    )
  8  5 - < @ J    8 8  8 D  < U 8    -  - V
u
- <  8  7
D ^    <  D s I I b D
r c t  D
      )
D  8 U b -  U  @
 n " $ -  '   
A - ) :   6 0 : )    ) : ) $ $  $     ' V 
.
  0 6 p
 $  - :  ' V
l D    ) V -  F   " D
u
- <  U    D ^  G
  <  w  N -    -  ^ D L  5  D    D
u
D w G L  G I J G
c c s D D   D s I I J D
r J t E D K U    ) - l

D    - 8 8 l
u
D  -  &   )  D
w U
€
U  @
  : 8 - : )  Q   :  0  Q '  -  H     ) 
 " " $  Q ) '  -  $ :    '  0
.
) " "     - - $
l
  
J  - 5 D  U  - <  5  -
u
-  V D -  J    8 8  8 l    G
   N U   )   ) [    -  b G N    )   - 5      & D
J  @ s J d G s I s D E  N D y F F d D
458 Tecnologías Grid, Clusters y Plataformas Distribuidas
   
    
      
 "      $  
       * ,

. 
      $ 
0 1 2 4 1 7 9 ; 4 2 ? A B C D 9 F H I D 7 C D M H 9 O A 4 C A I C R H T U ? A
W Y Z [ ] _ [ ` Y a _ c d Y e a g c ] ` k _ l n [ o W Y Z [ ] _ [ ` Y a _ c d Y e a g c ] ` k _ l n [ W Y Z [ ] _ [ ` Y a _ c d Y e a g c ] ` k _ l n [
t u _ [ d v u _ l n [ x y Y z Y ` k _ l n [ t u _ [ d v u _ l n [ x y Y z Y ` k _ l n [ t u _ [ d v u _ l n [ x y Y z Y ` k _ l n [
{ a l } Y ] u l d [ d  Y x €  [ a ƒ [ ] z c u { a l } Y ] u l d [ d  Y x €  [ a ƒ [ ] z c u { a l } Y ] u l d [ d  Y x €  [ a ƒ [ ] z c u
` [ ] _ [ ‡ ˆ Y z _ ] [ a Š  ] Œ n ‡ Y u Œ c u Y z  l u ‡ ˆ c u Ž  Y Š  ] Œ n ‡ Y u [ a _ c a l c ‡    ` [ a Š  ] Œ n ‡ Y u
‘ ’ ” • – ’ ˜
™ š œ  ž œ ž Ÿ   ¡   ¢ £  œ ¥ Ÿ £ ¥ £ š œ § š   ¨ © ž Ÿ ª ¬   ¥   Ÿ  
œ ­   ® §   Ÿ œ ® Ÿ œ š ¯ ª ¨ ª œ š ž £ ¯ œ ®    ¯ ª ± œ Ÿ œ š ž œ  ¥ £ ® ² ž ª ³
¬    ¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š µ § œ  œ ¥ § œ ¯ œ š § ž ª ® ª ·   Ÿ œ š
§ š   ® ¹ £ Ÿ ª ž ¨ £ ¯ œ œ µ § ª ® ª ¡ Ÿ ª £ ¯ œ ¬   Ÿ ¹   » ®   œ ½ ¬   ³
¬ ª   ¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š » ¯ œ ¨   š œ Ÿ   µ § œ  œ ¥ § œ ¯   š
œ ¾ ž Ÿ   œ Ÿ ¬ £ š ¬ ® §  ª £ š œ    ¬ œ Ÿ ¬   ¯ œ ¬ § ¿ ® œ  ®   ¨ œ ³
¢ £ Ÿ £ ¥ ¬ ª ´ š ¥   Ÿ   ¬ ® §  ž œ Ÿ  À œ ž œ Ÿ £ ¹ © š œ £  Á ™  ž   
¬ £ š ¬ ® §  ª £ š œ   œ œ ¾ ž Ÿ   œ š ¯ œ § š œ ¾ À   §  ž ª ­ £ œ  ³
ž § ¯ ª £   š   ® ² ž ª ¬ £  œ ¾ ¥ œ Ÿ ª ¨ œ š ž   ® ¯ œ ®    ¯ ª ± œ Ÿ œ š ³
ž œ    ® ž œ Ÿ š   ž ª ­    ¡      ¯ £ œ š œ  ž   š § œ ­   ¨ © ž Ÿ ª ¬   Á
Ä ® ® œ ­   š   Ÿ œ ¬ £ ¨ œ š ¯   Ÿ ®   § ž ª ® ª ·   ¬ ª ´ š ¯ œ ¥ £ ® ² ³
ž ª ¬    ¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š ¥ £ Ÿ œ ­ œ š ž £  »    µ § œ  £ š
®    µ § œ £ ¡ ž ª œ š œ š § š ¨ œ ¢ £ Ÿ ¬ £ ¨ ¥ Ÿ £ ¨ ª  £ œ š ž Ÿ œ
œ  ¬   ®   ¡ ª ® ª ¯   ¯ »   ¬ ž §   ® ª ·   ¬ ª ´ š ¯ œ ®   ª š ± £ Ÿ ¨   ¬ ª ´ š
 § ž ª ® ª ·   ¬ ª ´ š œ ½ ¬ ª œ š ž œ ¯ œ ®   Ÿ œ ¯ Á
Æ Ç É
˜ Ê Ë Ì Í • Î Î Ï Ð ˜
Ñ   Ÿ œ ¹ ®   ¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š ¯ œ § š   ® ¹ £ Ÿ ª ž ¨ £ ¯ œ
œ µ § ª ® ª ¡ Ÿ ª £ ¯ œ ¬   Ÿ ¹   œ  ¥ œ ¬ ª ½ ¬   ¬ ´ ¨ £  œ ¯ œ ¡ œ ¯ ª ³
± § š ¯ ª Ÿ  ¨   š ž œ š œ Ÿ ®   ª š ± £ Ÿ ¨   ¬ ª ´ š ¯ œ œ  ž   ¯ £ œ š
® £  š £ ¯ £  ¯ œ ®  ª  ž œ ¨   ¥   Ÿ   ¥ £ ¯ œ Ÿ ž £ ¨   Ÿ ®   
¯ œ ¬ ª  ª £ š œ  ¯ œ œ µ § ª ® ª ¡ Ÿ ª £ Ó Ô Õ Ö × Á ™ š ®    ª ž §   ¬ ª ´ š
ª ¯ œ   ® » ¬   ¯   š £ ¯ £ ¯ œ ¡ œ ž œ š œ Ÿ œ š ž £ ¯ £ ¨ £ ¨ œ š ³
ž £ ª š ± £ Ÿ ¨   ¬ ª ´ š   ¬ ž §   ® ª ·   ¯    £ ¡ Ÿ œ œ ® œ  ž   ¯ £ ¯ œ ®
Ÿ œ  ž £ ¯ œ ® £  š £ ¯ £  µ § œ ¬ £ ¨ ¥ £ š œ š œ ®  ª  ž œ ¨   Á
Ø œ Ÿ £ œ  ž £ š £ œ  ¥ £  ª ¡ ® œ »    µ § œ ª ¨ ¥ ® ª ¬   Ÿ ²   § š  
¹ Ÿ   š ¬   š ž ª ¯   ¯ ¯ œ ¨ œ š    ¢ œ  œ š ®   Ÿ œ ¯ ¯ œ ª š ž œ Ÿ ³
¬ £ š œ ¾ ª ´ š ¯ œ ® ¬ ® §  ž œ Ÿ Á
Ø £ Ÿ œ ® ® £ » § š   ¡ § œ š   Ÿ œ ¹ ®   ¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š ¯ œ ³
¡ œ ¨   š ž œ š œ Ÿ ®   ª š ± £ Ÿ ¨   ¬ ª ´ š ¯ œ ® œ  ž   ¯ £ ¯ œ ® £ 
š £ ¯ £  ® £  § ½ ¬ ª œ š ž œ ¨ œ š ž œ   ¬ ž §   ® ª ·   ¯    ª š µ § œ
œ  ž £  § ¥ £ š ¹   § š   ¹ Ÿ   š  £ ¡ Ÿ œ ¬   Ÿ ¹   œ š ®   Ÿ œ ¯ Á
Ù
¯ œ ¨ ¿  » ¯ œ ¡ œ ž œ š œ Ÿ  œ œ š ¬ § œ š ž   µ § œ ®   Ÿ œ ¯ ¯ œ
ª š ž œ Ÿ ¬ £ š œ ¾ ª ´ š ¥ § œ ¯ œ ª š ž Ÿ £ ¯ § ¬ ª Ÿ § š ¬ ª œ Ÿ ž £ Ÿ œ ž   Ÿ ³
¯ £ œ š ®    ¬ £ ¨ § š ª ¬   ¬ ª £ š œ  » ¥ £ Ÿ ® £ µ § œ ®   Ÿ œ ¹ ®  
¯ œ ª š ± £ Ÿ ¨   ¬ ª ´ š ¯ œ ¡ œ Ÿ  œ Ÿ ž £ ® œ Ÿ   š ž œ   œ  ž £  Ÿ œ ³
ž   Ÿ ¯ £  » µ § œ ¥ § œ ¯ œ š ª ¨ ¥ ® ª ¬   Ÿ µ § œ ®    ¯ œ ¬ ª  ª £ š œ 
¯ œ œ µ § ª ® ª ¡ Ÿ ª £  œ ž £ ¨ œ š § ž ª ® ª ·   š ¯ £ ¥   Ÿ   œ ® ® £ ª š ³
± £ Ÿ ¨   ¬ ª ´ š £ ¡  £ ® œ ž   Ó Ô Ú Ö » Ô Û Ö × Á
™ ® ¬ £ ¨ ¥ Ÿ £ ¨ ª  £ œ š ž Ÿ œ ®   ¥ Ÿ œ ¬ ª  ª ´ š ¯ œ ®   ª š ³
± £ Ÿ ¨   ¬ ª ´ š ¯ œ œ  ž   ¯ £ ¯ œ ® £  š £ ¯ £   § š   ¡   ¢  
 £ ¡ Ÿ œ ¬   Ÿ ¹   œ š œ ® Ÿ œ ¯  œ À   ¬ £ š  œ ¹ § ª ¯ £ ž Ÿ   ¯ ª ³
¬ ª £ š   ® ¨ œ š ž œ Ó  œ   š ¥ £ ® ² ž ª ¬    ® £ ¬   ® œ  » ¹ ® £ ¡   ® œ  £
¢ œ Ÿ ¿ Ÿ µ § ª ¬    × ¬ £ š ž Ÿ œ  ž ª ¥ £  ¯ œ Ÿ œ ¹ ®    ¯ œ ª š ± £ Ÿ ³
¨   ¬ ª ´ š ¯ ª  ž Ÿ ª ¡ § ª ¯    Þ
ß à á â ã ä å ã æ ç
Þ è   ¯   š £ ¯ £ ª š ± £ Ÿ ¨   ¥ œ Ÿ ª ´ ¯ ª ¬   ³
¨ œ š ž œ   ® £  ¯ œ ¨ ¿  ¯ œ  § œ  ž   ¯ £   ¬ ž §   ®
Ó Ô é Ö × Á
ß ê ç ë ì å á í ç î å ç
Þ è §   š ¯ £ § š š £ ¯ £ ¯ œ ¡ œ ž £ ³
¨   Ÿ § š   ¯ œ ¬ ª  ª ´ š ¯ œ œ µ § ª ® ª ¡ Ÿ ª £ »  £ ® ª ¬ ª ž  
  ® £  ¯ œ ¨ ¿  ª š ± £ Ÿ ¨   ¬ ª ´ š  £ ¡ Ÿ œ  § œ  ž   ¯ £
Ó Ô ï Ö × Á
ß à ì â á ð á î ñ ì ò
Þ è   ¯   š £ ¯ £ ª š ± £ Ÿ ¨     ® £  ¯ œ ³
¨ ¿  ¯ œ  § œ  ž   ¯ £ ¬ §   š ¯ £  œ ¥ Ÿ £ ¯ § ¬ œ § š
œ ­ œ š ž £ ¯ œ ž œ Ÿ ¨ ª š   ¯ £ Ó Ô ó Ö » Ô ô Ö × Á
™ š   ® ¹ § š £  ž Ÿ   ¡   ¢ £   œ À   š ¥ Ÿ £ ¥ § œ  ž £  £ ³
® § ¬ ª £ š œ  ¨ ª ¾ ž    » š £ Ÿ ¨   ® ¨ œ š ž œ œ š ž Ÿ œ ¥ £ ® ² ž ª ¬   
¥ œ Ÿ ª ´ ¯ ª ¬    £ ¥ £ Ÿ œ ­ œ š ž £  Ó ¯ œ š £ ¨ ª š   ¯    ­ £ ® § š ³
ž   Ÿ ª       µ § œ ¬   ¯   š £ ¯ £ œ š ­ ²    § ª š ± £ Ÿ ¨   ¬ ª ´ š  
® £  ¯ œ ¨ ¿  ¬ §   š ¯ £  œ ¬ § ¨ ¥ ® œ § š   ¬ ª œ Ÿ ž   ¬ £ š ¯ ª ³
¬ ª ´ š ® £ ¬   ® × Â ¥ £ ® ² ž ª ¬    ¡   ¢ £ ¯ œ ¨   š ¯   Ó ª š ­ £ ® § š ³
ž   Ÿ ª    »    µ § œ ¬   ¯   š £ ¯ £ œ š ­ ²    § ª š ± £ Ÿ ¨   ¬ ª ´ š
¬ §   š ¯ £  œ ® £ ¥ ª ¯ œ £ ž Ÿ £ × Á Ø £ Ÿ œ ¢ œ ¨ ¥ ® £ » œ š Ô õ Ö » Ô ö Ö
Â Ô Õ ÷ Ö » ¬   ¯   š £ ¯ £ ª š ± £ Ÿ ¨    £ ¡ Ÿ œ  § œ  ž   ¯ £ ® £ ³
¬   ® ¬ §   š ¯ £  œ ¬ § ¨ ¥ ® œ š ¬ ª œ Ÿ ž    ¬ £ š ¯ ª ¬ ª £ š œ  ¥ œ ³
Ÿ £ ž   ¨ ¡ ª © š  £ ® ª ¬ ª ž   ª š ± £ Ÿ ¨   ¬ ª ´ š  £ ¡ Ÿ œ œ ® œ  ž   ¯ £
¹ ® £ ¡   ® ¬ §   š ¯ £  œ ¬ § ¨ ¥ ® œ š £ ž Ÿ    Á
                              " $
%      '            +             1  3  $
  6  9       3 +    3          <    3    
 >     @       <  +          %     < E    
                      G H   +     '      
    3             +           %    N    
      '  3 E     Q  
R
T U T V U X R V Y  Z [ \ U T V _ Y
Q
>       3  9       @    6          @  b  G
                        <         $
      G         6  i     N      N     
    1  3    6  Q   3 E     >   +  3    l    
  <            6   '           3          
  1               '   +       @       3 +  $
       9    <                 @       $
'         9   @     "                    6 
6 +   3  +      <       1  3    6         $
<    3      >     @   G                  
                 6  o Q b           +  +    $
       @  b  1     G
 q  
r
r s
u w s y z { |
r s } y
H      <                 @    l      3  $
b  +            1  3    6  +       <    3 
   >     @       <            %     < E $
             N b    3 E          >    
+       3 +         3                   
 +                 G
      '  3 E     Q     3       N       
  1  3    6    € Q   @                  3 $
+  3    >      <       1  3    6   @     
               6        9    >     @   >  
       <            3   >        b  l  
  <    3          3  b           6      
      9 +         Q      3  9  <       
             <    3     >     @       <  € G
H         Q    " +    6  <             N $
       l „
       … €
            N                 6     
  9       3          <         @   $
                 <    3     >     @    
  <           3  G
‡
          6          
                          1        
   >     +        N           +         
  1  3    6  „
ˆ 
T U T V U X R " ‰ V # V % U T V _ Y X R # U [ R X (
  * ,  $
  +  l 3      @        N        
   
     3     b   >   <       +         
  1  3    6  G      Q     @  3     
         6   @             Q >   '    
          3     +     . 3     3   $
  b    0 € <                      
        3  +      '     @     <    
  1  3    6  Q     >     @           
     3     b                       $
    9                         3  G 1  2
     . 3     3     b   <        + 
            3         5    . 3       
               3  € 9 +   +     6   
 >     @               +      6 7 9 ; = € Q  
  N      N                 6       
  3  „
   @
2

5  6
7 9 ; =
0
 i €
    >          „
2 
0
5  6
7 9 ; =
 ‹ €
Π        N     6     N               $
  6                         <     $
  1   6 3    „    +             1  3    6 
+      <       3   3   . 3     3   $
  b       3   3      '         3 +  Q +  $
                l            +  $
          >     @   3       >      
      +  >       >          E      $
      +  >        E    %         
>              € Q     .    3    @  +    $
              '  3 E     >        l
  N       G      .    3      Q       $
       +  '   %           Q <       
 l N                   G
‡
  3 l    3 $
@  E    @     1            +          
  1  3    6  >   <        3   3   . 3  $
   3     b          3        1     
 . 3          Q 9  >     +        >  
     E                       3  9 
  3  F    l 3 l   N       G H         Q
   N                     6         
  N     3      '        . 3     3   $
  b   <        +   +     6     >     $
@      +     9 +      „        3    
460 Tecnologías Grid, Clusters y Plataformas Distribuidas
   
                    !   ! 
  % & ! ' ! (  ! )    '       &   1  '   (    
%   4  ' 6 & !    !  :    ! )  =
>
@ A @ A B C @ B F A @
H C C  @ B C I A K M @  F N C H O F
K M M 
C C  N C F K M B @ N  @ 
  S   '     
  &  4   1  &    4    %   & !    '       W
!   X &   !     '  % & ! ' ! (  ! )    '  '    ! & W
    \ % ! ' ! X  !   ^ !  &  %     !    W
4 ' !    &  % & ! ' ! (       4 &      '  4   W
 % 4  X &   !   % & ! ' ! (      '  '    ! &   
 \ % ! ' ! X  !     4  &    '   ! & %  ! )    ' 
\ %      % & ! ' ! (       !     g


 
   
  


 

   
  

h i j
    

 
   
  

   ' & !  4       W
4 %   &    '   4 ' !  ! )  %            W
' ! (   \ % ! ' ! X  !        

 

   
  

 
 ' & !  4       4 %   &  %       % & ! ' ! ( 
%   '    ! &  4     \ % ! ' ! X    '      =
m    4      &  X '     4    !       &  
'    !  & !  &    ' &     & ! p   4    '   4  ' 6 & ! W
    !  :    ! )     
    :   !    & 
 4    % 4  '  4    % 4 1 ^ !  \ %    4  W
  6   X &        '    !    '    ' \ %   
 X & % p !     '  \ % ! ' ! X  !  4   :  &     '  !  &  W
 = S '  4    % 4 \ %     X &     6      & 
   ) 4 & !    g

 



 
   
  


 

h s j
    

 

   ' & !  4       4 %   &   
'   4 ' !  ! )  %        X & !     '  \ % ! ' ! W
X  !           '  !  &        !    '
& !  4       4 %   &  6  !  \ %    4 %   
     % !  4      &   4 ' !  ! )  =
       \ %   '  4    % 4   '  & ! p   X &  W
 !    '  4 ' !    '  '    ! &     \ % ! ' ! X  ! 
\ %    g
 
 



 



 


 

   
  

h v j
w   &      &   '   ^ 4    ! )  \ %  4   ! &   X W
&     '     !    %   4  ' 6 & !    !  :    ! ) 
  '   !  % !   &  g
      
     
!


 


 

   
  

h x j
z "
{ | } ~  € ‚ € ƒ " # … # |  # € ~ † % # { ~  { '
|  ˆ | # { " € % ) |  ‚ # { ~ †  ˆ & € … ƒ # ‚  ‰ ˆ
* , - , 0 2 4 5 6 8 9 ; = ; ? @ 4 8 B 9
Š      ! ! )    '     !    !  :    ! )     W
' ! (      '    ! )    &   !   4   ! &     ' ! (  
%    & %  !     ' 6 & !    '     ! !   &    '   &   
4  ' 6 & !   &    ! !    '   =    4 % ‹    ' '      %  
 ^ 4    ! )        ' 4    '     !    !  :    W
! )   '  4    %  &  \ %    4 '   &     '   !  % !   W
&  g C % 1 '    ' p  '   1 ^ !       !   ' \ % 
4 %     ' '     '   &    4  ' 6 & !     !  :    ! ) 
   ' ! (     D =
m     4     '      !    X &   !     
'   &    4  ' 6 & !            !    & %  !    '  (  W
       
  \ %           %      ' '   =
S   '   & %  !  \ %    Π     & !  %  ! )     % W
4    \ %    % & ! ' ! (    % & !       %  !  ! ) 
4 %  &   4 %  &      '  & ! p   g
> F M  @ I M N C I K C B @
 S  %   !  &           
            1  &     '     1   %
  &     & %  '      4   !      !  :    W
! )  =     &            !  &   p  '   
  p 6     J  L
) M
   
  = m   '  &   &  
  %  !  &   p  '    & !  4  O \ %    &   W
  Q 4   !       !  :    ! )    '  (   
     
          4   %   4  ' 6 & !   
  &  & ! 4    g
! R  Q    J  L
) M
h  j
> F M  @  @ ‘ F K M O @ A K @
 S    &        
p  ( \ %  %        X  &    %     !  ! ) 
   \ % ! ' ! X  !     p 6  %     
  '    &   
       ' ! ! & 1    '    % !  :    ! )      W
&    = ’  '    &    '          &   &   1 
  p !      %   &     & %  ' = m   '  &   &  
  %  !  &   p  '    & !  4  O    ' \ %   
&    Y   !  !        \ % ! ' ! X  !    '  ( W
        
            g
! Z [  \  Y  J  L
) M
h “ j
XVI Jornadas de Paralelismo, JP '2005 461

            

          !  $ & (  +
,   .   ! +  ! + 0 + $  0  & $ 5 . + 8 $  & $ ( + : & +
  0  (   ( 0 &  @ ( ! 8 + $ 0   ! 8   & 8 $ & 5 & $   H
  &  $   &   0 & & 5 & $   ( K 8 & ( & ,   0 8 ! & $
& $ 8 $ 0 &  &    $ + 0   $  &  5 +   0 &   &  ,  
& (   &  $   &   0 &  & $ ( + : & ( K 8 & ( & Q & $ & R
 + $ & $ & (  &  $  &  5 +   & ( T




 

U V W X
      + $    + ( & Z ,  & (   $ & ( 0 &  + & \ ! + !  +
0 &  $ ^    + !  ` $ K 8 & ( &  b   & $ & $ , +  +  + (   & (
,   .   ! + ( (  $ T

      f h i f j 


 

   




 


 

    
  

U V V X

     k  i  l   i 



 

    


 


 

    
  

U V m X

            







   



 


 

    
  

U V o X
p $   0  (   ( ! + (  ( ( & r + ( 8 , 8 & (   K 8 & &  !  R
!  & $  &    

( & , 8 & 0 & + ,   Z   +  + V H p ( R
 + ( 8 ,  (  !  ` $ & ( 5 @   0 + (  &  $   &   0 & $  0  (
K 8 & !   ,  $ & $ &  !  8 (  &  & (   ( 8 \ !  & $  &  & $  &
Q  + $ 0 &  ( 8 ,  (  !  ` $ b + (  + $  &  + s  $ + b  & , +  +   (
!  8 (  &  ( + !  8 +  & ( H
t  $  + ( & Z ,  & (   $ & ( 0 &  + & \ ! + !  + 0 &  $ ^   R
 + !  ` $  b  & $  0 + ( , +  +  + (   & ( ,   .   ! + ( ( &  b R
( &  5 + K 8 &  + & \ ! + !  + 0 &  +  & Q  + , &   ` 0  ! + & (
 $ 5 &  ( +  & $  & ,   ,   !   $ +  +  $   &   0 & $  0  (
0 &  (  (  &  +    & $   + ( K 8 &  + ( 0 &  + (  & Q  + ( b + : 
0 &  + $ 0 + w ,   & 5 & $   (  (  $  $ 0 & , & $ 0  & $  & ( 0 &
& (  & , +  @  &    H
p (     ,   ! + K 8 &  +  & Q  + 0 &  $ ^    + !  ` $ , & R
  ` 0  ! + $  & ( & ( ! +  + b  &  w K 8 & +  + 8  & $  +  & 
$   &   0 & $  0  ( 0 &  (  (  &  +  + & \ ! + !  + 0 &  $ R
^    + !  ` $ K 8 & ( &  b  & $ 0  @ !  $ & (  &   ,  0 & ,  R
 .   ! + ( & 0 & Q  + 0 +  @ !  $ (  0 &  + b  &  & $  & H p (   & (
 ` Q  !   w + K 8 & !  $ & (  + ,   .   ! + 0 &  $ ^    + !  ` $
  0  (   ( $  0  (  $ ^    + $ , &   ` 0  ! +  & $  & 0 & ( 8
& (  + 0  +   0  (   ( 0 &  @ ( H p $ 8 $ !  8 (  &  , & K 8 & R
  & (   $    & $ & ,   K 8 & ( 8 ,  $ &  8 $ ,   b  &  + H
 &   +  + 8  & $  +  &   +  +   0 &  !  8 (  &   (  $
K 8 & & (     ,   K 8 & & $ + b (   8   K 8 & ( & 5 + w + +
+ 8  & $  +  &  $   &   0 &  , &  + !   $ & ( 0 & & K 8    R
b    K 8 & ( &  & +   s + $  &  + 8  & $   0 &    @ \ !  K 8 &
( & Q & $ &  + r + ! & K 8 &  + & \ ! + !  + !  $  + K 8 & ( & & (  @
8     s + $ 0   +  & 0 0  (   $ 8 w + !  $ (  0 &  + b  &  & $ R
 & H
t  $  + ( & Z ,  & (   $ & ( 0 &  + & \ ! + !  +  ( & , 8 & R
0 & & (  8 0  +  ! 8 @  & ( &  5 +     @ Z    +  K 8 &
( & , 8 & 0 &   & Q +  !  $ ! + 0 + ,   .   ! + 0 &  $ ^    + R
!  ` $ H p $   0  (   ( ! + (  ( ( &  b  & $ 0  @  + & \ ! + R
!  +  @ Z   + ! 8 + $ 0  &  +  Q       0 & & K 8    b   
!  $ (  Q + K 8 & &    &  ,  0 & & : & ! 8 !  ` $ 0 &  + + ,   R
! + !  ` $ ( & + &  ` ,      ,     K 8 & &  !  !  & $  &

 



 

    
  

5 +  & V H
p $ ! 8 + $   +   ( 5 +    & ( 0 &   & (   0 & , +  @  & R
   (  & $ &   & :   0 &   ( ! + (  (  &  !  8 (  &  U  &  0  R
  $   0 & & K 8    b    X  & $ 0  @ 0  ( $  0  ( U  X H
 , +  +   ( , +  @  &    ( & ( , & ! . \ !  ( 0 & ! + 0 + ,   . R
  ! +  ( `    & $ 0  @ ( & $   0  & (  8 0  +   + & \ ! + !  + 0 &
 +  & Q  + 0 &  $ ^    + !  ` $ & $ (   8 + !   $ & ( & $  + (
K 8 & &  +  Q       & (  € ^ 8 $ !   $ + $ 0  w ( & & (  €  $ R
^    + $ 0  0 &  & (  + 0  0 &   ( $  0  (  0 &  + $ &  +
K 8 & !     . $    ( &  & $ 0  @

 !

w


H
‚
( .    ( 5 +    & (  @ Z    ( 0 & & \ ! + !  + K 8 & ( &
,  0  @ $ +  ! + $ s +  !  $ & (  + (   & ( ,   .   ! + ( (  $ T

      f h i f j 




 



   
U V ƒ X

     k  i  l   i 




 
 


   
U V „ X

            




 



   
U V … X
p (   ( 5 +    & ( $  ( & , 8 & 0 & $ !   , +  +  0   & ! R
 +  & $  &  w + K 8 & 8     s + $ 0  0  (   $  + ( ,   .   ! + (
0 &  $ ^    + !  ` $ , 8 & 0 & $  & +   s +  ( & 0  (   $   $  R
 &   0 &  , &  + !   $ & ( 0 & & K 8    b    H  &   & $ 8 $
! + (  & $ &  K 8 &   (   & (   ,  ( 0 &  & Q  +   & 5 +  + $
+  +  & +   s + !  ` $ 0 &    (   $   &   0 &  , &  + R
!   $ & ( w ,      + $    +  +   (  + (   8 + !  ` $ 0 &
& K 8    b      + K 8 & ,  0  . + r + ! &    !  $ 8 $ +  + R
w   & \ ! + !  + ( &  . +  +  & Q  + ,   & 5 & $   ( H
462 Tecnologías Grid, Clusters y Plataformas Distribuidas



              
   
             
       ! # %  !

%      
     +
  
!  /
%
 

#  

 !

 3

# +     %
#  !
      # ! 6  
 %    9
: #  
       % 
%
 = 

@    3

 6 !

#  !    #     B  
6 %
 %  !
 D !           
% #
  !
    
     #  E
F
  G    !     # %      ! 9

% #   #         
  #   #   @ #  %    
 # N
  G        %  D       


!
 #  !    # 9
   E
  # % #  ! #   B         #   
!  /
% #    Q

   

% # %  :           
  #      !     
Q     # T U   # =   Q
     #   :    # 
     #
 
! T #     # %   G   !  +   # % 
 T
E W
 
 

G     
      
! T #     #  #    =     ! !
 N
  #   #         @ #         # G    
!  /
  !
  # %   #  
!
 %  % #  @   #    E !
! T #     #
%   G   !  +   # % 
 T
   B

      !    9
 #    # % #  ! #   B         #  

 
!  /
 !

#  

 #       T 
! %
% %  #  %   #    N   9
! #   Q
 % # @
 
 % # !
  T !
%    : #  
   E
      # !
   !     
   %    
      # 9
! 6  
 %    : #  
   Q
= G   Q
 
! T  


!

 #    `
a  b  c  b d e g h e i c

  Q
%  
% # #  #    #

 D     # %  !
  T !
!
%  
   %  !   9
  # % # %    : #  
   

 # %    
!  /

    +
 #  %  :            # % #  E
a  b  c  c m n h b o c p h c

  Q
   !     
% #
%  
  
G   Q
T
 
   !  /
    3 9
     %  !
  % E t #    # N
  G       # 9
 6
 #    6
   
  #
   
    T   
9
 D     # N   Q
    # %   % #        # % 
    
     %     #    %   G   !  +   #
!

  T !
%    : #  
   E    
 D     # N %  9
 #   
% # 



N %  + 
   
   %  
  9

    !

!     # % # %    : #  
   %  !

  T !
     % 
N @
! #      =   G    #    9
 #     
T 

   %
% %    D 3 #   !

  % N    # @
! #    %  
 
% # !
 T #  %  T 
9
%
  !    %       # T ! # +
! %  !
! T #     # E
a  b  c  n d b v b p w n y

    
 # Q
= G  
%  3    ! #   @    #  G     # @ #
  !      9

 +  # %    : #  
        ! #   # % #  G  
#   #     !      
E  !
   !     
9
     # T  %


 
!  /
 !
   %  %
  
Q
   !  /
% #        
%        
% #   
 ! G  
%
 # % #    %         #  N    9
  # #      #  N   T    ! @
! #  %    6  %  
% 

T
E W #   # % #      #     # 
G   9
! ! #  G      D   # +  
 T
% #  =  #    %  

  
    @
 
 
 z @
! #    +
 #  %  !
6  %   | E t #   ! #   
  # N ! #   # % #      9
 #     #  ! #  G      D    =  # #
 T
9
% #  =    %  
  
 
 
 
  # ! #
!  
#  #    # 
 z @
! #   
!  #  %  ! 6  %   | E
t #   !    # N ! #   # % #       #   #  ! #  G  
   D     
   
          % 
=    9
%  
  
 
 
 ! #
!      #  #    # 9

 E   
 % #  !     # %  !   
% #      #  
 ! @
! #  %  ! 6  %   } E ~  N  !    # 
 D     #
G   Q
= G  
   
    !
 Q # %  !   
9
% #      # E € #  #  ! 6  %   % 
 T
   % 
 # 
 @
! #         } =  N  !
 Q # %     
  
% #    %  @
!        } z  # Q
=   
% #
     # | = } E  z  # Q
=   
% #     #  | E
  Q
  
!  /
% #  B         #             9

 %  :        `   # 
%  
  #  # % #  N  U  9
  T # %   ‚ =   %  
%  ƒ ~ E   !  B        9
 # G          
#  #      ! # N %   #   
% #
 B         # 

    % 
Q # 
N       
 

 ! 
   #      
       #  %  
 
 N
 # %
  ! !
  T 
!         6 E
F
!
  
% %  ! # 
 # % #  %  ! !      !  ! !  T
 
   @

 
% 
  

 ! 
  
%
„  E t

 ! !        # 9

   # 
!       
 „ } 
 
 N  #  ! # G  
! !  T
 ~ } 
 

!  # % #  ~ = #  
 ~ }
!  # 9
% #  ƒ E  
  #
! !       U    T # N    # 
!
         ‚ } 
 
 N %  
  
G   ! !  T
 ~ }

 


%
 # % #    ! 
 T #  † 9    E ‡ 


  %  
N ! !  T
 ~ } 
 

! #   # % #  %  ! 
 T #
  ‚ 9  ƒ  z   ƒ ~ } | E
 !
 
+ !
  N ~ = ƒ        
 ! #      ! 9

% #  # +     % #  

!
      # ! 6  
 %    : #  9

   #   !  B         #  E   # %
 !
 
9
+ !
        
 !
 #   
 #    %   G   !  +   #
 
!  /
%
 z 
  
| N !
T

 
# +     %
#   !

! T #     # z  | = !
 3

%    : #  
   z  | E
t


!  !
   
 3

  Q
   %  % #  !   9
   # %      # % #    !
  T !
     % 
z | N  !
     # %   # !     %   %    : #  
     !
  9
T !
+
 # %  
 %
z ! | =  !      # %   @    # 
   ! !
  T !
 #   @    #  z  | E
W #      ! 
% #  

! #   B         #   
!  9
/
% #  #  !
 # ! 6  
%    : #  
        % 



%  :            # % #  %    : #  
   z  |  
XVI Jornadas de Paralelismo, JP '2005 463
                
  " $
 % % & ( % ) ( * + + ( * ( & %
  " $
 . . / & ( ( * + + ( * ( 0 /
  " $
 % ( % % % 1 ( * + 2 ( * & . .
  " $
 & ( / % 1 ( * + 2 ( * 2 & )
  " $
 . ( 2 & % ( * + 2 ( * 0 ( 1
  " $
 / ( . & % ( * + . ( * 1 & )
  " $
 % & ( % & % ( * 2 0 & * 2 / )
  " $
 % ) ( % & ( ( * 2 + & * & + (
  " $
 . ( ( % & % ( * 2 & & * & ( +
  " $
 / ( ( % & % ( * 2 ( & * % ( (
3 5
  6
"
% % / 0 ( % ( / ( * 2 1 ( * ( ( &
3 5
  6
"
. / . ) % ( . ( * + 2 ( * ( ( +
3 5
  6
"
% ( & % & % ( ( ( * + / ( * ( % /
3 5
  6
"
& ( % ) 0 1 ) ( * 2 & ( * ( % 2
3 5
  6
"
. ( % % ( 1 + ( * . 2 ( * ( % 1
3 5
  6
"
/ ( / ) 1 2 ( * . % ( * ( & /
3 5
  6
"
% & ( . . ) % ( * & ( ( * ( . %
3 5
  6
"
% ) ( % ) / 2 ( * % % ( * ( & +
3 5
  6
"
. ( ( % / + 1 ( * ( 0 ( * ( % 0
3 5
  6
"
/ ( ( % / 2 0 ( * ( / ( * ( % %
7
 8

  % . 0 / ( & % ) ( * . + ( * ( ( %
7
 8

  . % + 0 % & % + ( * . ) ( * ( ( &
7
 8

  % ( + + & & ( / ( * 2 ( ( * ( ( +
7
 8

  & ( 2 ( % & ( + ( * 2 2 ( * ( ( 0
7
 8

  . ( & 1 ) & ( & ( * . 1 ( * ( ( )
7
 8

  / ( % . / & ( ( ( * . / ( * ( % /
7
 8

  % & ( 1 % % 1 + ( * & & ( * ( % +
7
 8

  % ) ( 0 2 % ) % ( * % + ( * ( % %
7
 8

  . ( ( / . % / + ( * % % ( * ( ( 1
7
 8

  / ( ( + & % 2 & ( * ( + ( * ( ( 2
9
 
            


  & 
'    )   -

/  0      0 '  /

     ;
 < 
   > 
   
 
  " $
 ( % ) % ) ( * 2 . ( * & % +
3 5
  6
"
( / ( 0 + % ( / ( * / ( ( * ( ( +
3 5
  6
"
% % ( + % ( + ( * + 1 ( * & 1 /
3 5
  6
"
& % ( . % ( . ( * + 2 ( * & / )
3 5
  6
"
+ % % & % ( & ( * 2 / ( * & ( 1
3 5
  6
"
0 % ( ( 1 0 ( * . 1 ( * % ) )
3 5
  6
"
% ( 1 . ) % ( * . / ( * % + 0
3 5
  6
"
& ( ) ( 0 2 ( * . & ( * % 2 1
3 5
  6
"
. ( 0 / / ( ( * . % ( * % & (
7
 8

  ( / + ( ( & & + ( * + & ( * ( % (
7
 8

  % & . / & & % ( * + + ( * & + )
7
 8

  & & . % & & ( ( * + 2 ( * & + /
7
 8

  + & & / & % / ( * + ( ( * & . 1
7
 8

  0 & % 1 & % & ( * 2 0 ( * & & 0
7
 8

  % ( & ( ) & ( 0 ( * 2 + ( * & & +
7
 8

  & ( % 1 % % 1 % ( * 2 . ( * & % /
7
 8

  . ( % 0 . % 0 & ( * 2 ( ( * & ( %
9
 
4            


  & 
'    )   -

/  0  
5  '  
 '

 9    
   

 
 ;
    /
  '   /  9      9   
@ '   0   / 9
  
  '   @        E
F 9 

9    
        ' 
     ? A B C
"
A 


" 

   
 
  " $
 ( * ( ( & / . ) ( * 2 2 ( * / 2
  " $
 ( * % ( + & & ) ( * 2 0 ( * & +
  " $
 ( * & ( + 2 & / ( * 2 / ( * & &
  " $
 ( * & + 2 ) & 2 ( * 2 ) ( * & 2
  " $
 ( * . ( + ( % 1 ( * 2 . ( * % /
  " $
 ( * 2 ( 2 2 1 ( * . 0 ( * ( )
3 5
  6
"
( * ( ( & 1 % ( / ( * + 1 & * % /
3 5
  6
"
( * % ( 2 . ) ( ( * / & % * % +
3 5
  6
"
( * & ( 2 % 0 + ( * / ( % * ( 1
3 5
  6
"
( * & + 2 ) / 1 ( * / / ( * 1 +
3 5
  6
"
( * . ( . 1 / 2 ( * + ) ( * 1 /
3 5
  6
"
( * 2 ( . ) / ( ( * + 0 ( * 1 (
7
 8

  ( * ( ( ) ) & % 0 ( * 2 0 % * % 0
7
 8

  ( * % ( ) 0 & % / ( * + 2 % * . +
7
 8

  ( * & ( ) ( & % & ( * + + % * 2 +
7
 8

  ( * & + + % & ( / ( * / ( & * 2 &
7
 8

  ( * . ( 1 . % 1 ) ( * + 2 % * % +
7
 8

  ( * 2 ( % ( ( % / . ( * + . ( * ) /
9
 
I            


  & 
'    )   -

/  0      E     
'    )   
/  0  '      9 M  
&

 / 
      -
'
/    
 &       ;        0 &  /  @ M
F 9  
 
  /      
 '         '  '    )   
/  0  /
'

E  S    

5
/     )   
/  0   T 
   & 9
  -
       
'  '       '   M         '   F 9  -
   
 
/
 &
'  

  
 T 
'  / 9
'
@
  F 9 
/

     / 9     '         '      -
        '  /    
 &       ; 1     
 &  @   
E
     '  
 ] /
/ 
'    )   
/  0    '     -
'    0   '    
&

 / 
; E
M F 9        
/ 9   
     )
/      @ F 9  `
/   F 9    
 ] -
/
/ 

9     
   /      
          '  ' 
  )   
/  0  `
 
   &

9   T    ;    
 
'      
 @ M
F 9 

9    
        ' 
'    )   
/  0      ' 9 /    &   ] /
  E
      
 -     '     
5   &    
'      
  & 
' 
  )   
/  0       F 9    `
/  9 
9     S
/  0 
 9 / `   T   ] /
S '  
  ' ; e
    E

 F 9 
5 9                E                    -
5     E
     '  
 ] /
/ 
'    )   
/  0  
-

              F 9               5    
       '   5  / 9 /  0       9  /
       


M   &

 / 
@         5   /            -
     
&

 / 
M 
9     S
/  0  F 9    `
/ 
'  
  ' 

   E

/
  
  & 
'    )   -

/  0  ; g

        '        
 @ '   h M I 4
  '   @ 
 E
 
/      '  
&

 / 
M 
 ] -
/
/ 
'    )   
/  0  /     E
   '        ' 
'    )   
/  0      9 M     
   ;
464 Tecnologías Grid, Clusters y Plataformas Distribuidas

  
  
                  
  "  $        (         "  $  
   ,    $ 

  /       (    
 "  $     $       7
8  $     
    $ 
       (   <   $ $  =
(  $     ?    
      (   


   "   A    

   ?  $     C  "  $  C
   F    G  ( A   
   =

        $   $ 

7  "   $
       

K  
    $ 
 < M N    $ 
 O Q    ,    $ 

    /        R     $ 
   
$         =
   "   

 Q 7 K U  V 7 V O < N  V 7 V < M 7
X           "   A    
   ?  $     C  (  =
] 
   
    (  $ ,        (   Q F     
    $     ,    " $      " $  (    
      =
(   

 N  F   "  
     `   $ ,    $     =
  $ 
  /     
   ?  $     C  "  $     $ 
        
 $ 
 7 X        
 < M N
O Q  
        $      $ 
   $       " 

 "  $     $        

   ?  $     C  d

e
"  $     `  $       f  $   ,    $    R   

   /     
   ?  $     C  7 X     G  
   =
   $            $
 K  
  "  $   F    
    
     N  $     $ 
  
 N  

   $    
   $          "  
  R    $   
  N  $
 /     
"  $  $     f  $     "  $    C 

  F     ( $   7
8  ,  $     C 
    /           $       $  =
      " 
  "  $         F    
  
 /     
   $  `   "  $  C
            $  
"  $  

   ?  $     C  7 k  $    " $ 
    
  R   
     /      "  $    ,    $      $ =
 
 
      " 
  "  $         
   
 R "  $            $    < 7
  F         $     
 
     $ 
   ` $   ,     ] 
   $  `  
   ?  $     C 
(  ] 
   
 ? $        "  $  C
          =
(   

    (  o    (  $ ,  F   "  $      

 "     
     /     
   ?  $     C  F  
 "  
  (     $      "   A     "  $  C
   
< V ,      N  $ F      (    
      "   A   =
  (  ] 
   
 7 C F  o 
 (     (  ] 
 /     
   $  `   (  ] 
   
 D 7 8   R "   =
    C         $    $
 F     "    
   =
 $    f    C  F   $  F    $       " 
 "   A    
   $ 
       $     f    C 
    "  $      

  F     ( $   7   
 $     f  $     "  $    C 

  F     ( $      " $  G  N F    "  $  $  F  
   `          ]         

  $   

 

       7   G      
 F     $    $ =

 F       "  $     $ 
       $     f    C 

  
  "
 $    C        $  V 7 V V < N V 7 V r
"  $     R "  $       $     f 
 7
k  $         R      
   $     
  ( =
   
      "   A     "  $  ,     d   (   O e 
  (  $ ,  F      "   A       C       =
  (       F           N  $        $ 

 

         N  $     /     
   =
?  $     C  F   "  
    `  $   (     $     
  ]  $
      t   (       `           =
  $           N  $           $      $

     ]  7 k  $     "   A       (        
  ]  $  ,    $ 
 `       
    `  $         =
`  
   ( $  "   $ V 7 M V     `       7 X

   $     $   
     G    F         $   =
  ,    
 
        $   $ 

   F     ( $  
C "    
       7 X     $        G 
 (    
     ]  $ ,    $
    `        "  $ 
     G 
    
     $    V 7 Q r 7
X      
      
   N  $       
 
         , 
 $            ,    $   =
R   
    /     
   ?  $     C  7 X      

        X  $  "  N  o $   `      /     
  R      (      "  $       G 
      $ 
  V  
   $     
   G  N   
     $ 
N  
    
       $   $    "   $  N
   "  $    
  F     ( $            7 X  
   / `  $    C 
    `  $    
 (     $      =

 "  $      
       "  F       
 
"  $  $     
    
  R  `     "  $      

   ` $       $ 
  
      
  
"  $              /         N  $     =

 A F    R        
     $  7
v

w x y $ { | } w x  |
9     
             
      A     $     f  =

  N  "    $   $ ,   
   C        R G     , 
  
   R "  $             `      `      
          t

8  $  `  
   ?  $     C  (  ] 
   
 
     (   "  $  " $        " $  (    
  
"    
    $    f    C    " $    
 (  
   
  
  "  $    C 
  F     ( $   7 X =
  $    $
  
 N  
     $    N   =
`    ,      ,    $   (    
 "  $     / =
    
   ?  $     C   "  $   F   
 =
  $         f    C        F    $   " 

     7
XVI Jornadas de Paralelismo, JP '2005 465

                              #   %
&    +  #    .     #    #     .       1 2  %
   5       #       #  # 5 5 &    :          %
#  #  5 =       &  # >  5     #  #   &    :   
          5    # 5                 %
    =   #  # &                        
 # & I     5  # &     5  
      L 5   
      # 1


                     L 5   5  %
            #                  .  %
   # 5     #     .       =    # +      #
   U      L 5   . &      #      W &      
 +   &  # 1 X      #         W &     L 5 W  # %
& 5      > #   W      #     U Z          
    5         [       5 &      #  # &   
  &   #  # &    #  #      ^   &   ` = ` 1 a b  
 5          c        &  =    &        
#  # &    d 1 2     &   #    W &    #     +   &  # >
  .   W   # & 5     #        #          
   5        # 5 #    I   &   #     # +      #
     U                    . &      # 1
   # &  &   .  Z  # 5      #  W    #   &   .  %
Z   5 =   &    #   &  # >    5      +           %
 5      L 5  &     W     #    5          #      %
&  +  #     #   # 5  &    #  . &      # > =     &   >
 # & 5         Z             U      #  +   &  #
    #    W &    #                         # 1
i k  k l k m n o
p
q r s t [   : [  
5          # t 1  1
 5 1

u v w y v  v z { | z
| z ~ v  v   €   u    ‚ €  „

 
€ u  v z w ~  v { ‚ | { €
1   5  
†
      
2 5 .   # [   # > r ‡ ‡ ˆ 1
q a s  1
†
1  &     +   1
†
        &      .  =  %
#        #    & [    = &       &     :      %
&      Z  . #  [   5    1 
  

 v z „ v { ‚ | u z „
u z  u    ‚ €  „
> ‰ Š ^ a d Œ r r ˆ  r ‰ ` > r ‡  b 1
q ‰ s  1     [       =   1 9  #   =     1
†
1
 &     +   1
†
   = #  #   & [      & #     %
  = #       # [     1 
  

 v z „ v { ‚ | u z „
u z  u    ‚ €  „
> ‰  ^ r r d Œ r b r ‰  r b a b > r ‡  ‡ 1
q Š s t 1  1
5     1 t 1  1
 5 1      &     :  
            &  %             5 &  &    #
 & [ & [
        :        #     c  [   
  & [   1 " 
~  u { € € w | z
„ u  ‚

€ $ { v  v   €
%
|


~ €   u   v z { €  u    ‚ | z
 u z  €  € z (
{ €
>    # Š r Š  Š a r > r ‡ ‡ Š 1
q b s 9 1  1    &    1 * 1    [       1  1
2  5 [ # 1     &    % .  #   .      #  [    #
    =          .            # &   . 5 &  
     # #   # = # &   # 1 " 
~  u { € € w | z
„ u  ‚

€
-
‚
 /
| „ ‚  |   ‚ € w 1 €  u   u    ‚ | z
 u z (
 €  € z { €
>    # r a ‡  r ‰  > r ‡ ‡ r 1
q  s  1 * 1  [      ‘ 1 t 1 t [   1
   # [  %
       # &   . 5 &       % &    # = # &   #  & [
# &  &  %  [    .       # & # 1 
  

 v z „ v { (
‚ | u z „ u z  u    ‚ €  „
>    # r r a Š  r r Š a >
r ‡  ‡ 1
q ˆ s 9 1 9 #  [ 8     1
:       < 1       1    %
+   & [  &   +     #    #       .     & [
   # &   . 5 &   .     [ %    % .  5        & %
[     r ` a Š      # #     &    1 " 
~  u (
{ € € w | z
„ u  ‚

€ A ‚
 
z ‚ €  z v ‚ | u z v  ~ v  v   € 
~  u { € „ „ | z
$   u „ |  
> r ‡ ‡ b 1
q  s  1        & [     1
†
1  &     +     
 1  [   1   # &   . 5 &   #  [   5     
&  #  #  & [         #      #  5      L 5  %
     & # 1 
  

 v z „ v { ‚ | u z „ u z  u    (
‚ €  „
> ‰  ^  d Œ r r r `  r r a ‰ > r ‡  ‡ 1
q ‡ s  1    5 #    ‘ 1 ‘         t 1 H       5 1
                  & [  #        .     %
       # &   . 5 &       5 &   # = # &   # 1 " 
~  u { € € w | z
„ u  ‚

€ L ‚
 
z ‚ €  z v ‚ | u z v   u z (
 €  € z { € u z
/
| „ ‚  |   ‚ € w  u    ‚ | z
$ „ (
‚ €  „
>    # Š ‡ r  Š ‡ ‡ > r ‡   1
q r ` s *   % D   
  1 " # # 5  #   & [  # &  &       %
  &           &              &        %
   #     # &   . 5 &       .             & %
[  1 " 
~  u { € € w | z
„ u  ‚

€ R S ‚

 T U 1

(
 U  u z  €  € z { €
>    #  ˆ  ˆ ` > r ‡ ‡ ‡ 1
466 Tecnologías Grid, Clusters y Plataformas Distribuidas
EXPLORACIÓN EVOLUTIVA DEL EQUILIBRADO DE
CARGA DINÁMICO Y DISTRIBUIDO
Mohammed
Aldasht
Universidad Politécnica
de Palestina
Hebrón, Palestina
Julio Ortega, Carlos G. Puntonet,
Antonio F.Díaz
Departamento de Arquitectura y Tecnología de
Computadores
ETS Ingeniería Informática
Universidad de Granada
18071 Granada
Juan Manuel Górriz
Departamento de Teoría de la Señal,
Telemática y Comunicaciones
ETS Ingeniería Informática
Universidad de Granada
18071 Granada
Resumen
Los algoritmos evolutivos proporcionan
mecanismos para la exploración eficiente de los
espacios de diseño. Así, constituyen una
herramienta eficaz a la hora de identificar las
mejores alternativas para implementar la solución
a un problema determinado. En este trabajo
aplicamos los algoritmos genéticos al ámbito del
equilibrado distribuido de carga en el
procesamiento paralelo. Se han clasificado y
codificado las distintas estrategias de equilibrado
distribuido y dinámico de carga, y se ha aplicado
una metodología, basada en la computación
evolutiva, capaz de analizar las características de
las alternativas de equilibrado cuando se
consideran distintos tipos de problemas y
plataformas. Como ejemplo de aplicación de la
metodología propuesta se presentan los resultados
correspondientes al equilibrado dinámico de carga
en un cluster de computadores para de un
algoritmo paralelo de ramificación y poda.
1. Introducción
En la décimocuarta edición (año 2000) del IPDPS
(International Parallel and Distributed
Processing Symposium) se celebró una mesa
redonda con el siguiente título: ¿Cuáles son los
diez conceptos más influyentes del último milenio
en el ámbito del procesamiento paralelo y
distribuido? [1]. Uno de esos diez conceptos, entre
los que están la ley de Amdahl, la segmentación
de cauce, el procesamiento multihebra, la
sincronización, y el procesamiento en clusters de
computadores, es el equilibrado o distribución de
carga (load balancing). El equilibrado de la carga
tiene como objetivo repartir el trabajo a realizar
entre los distintos nodos de procesamiento de la
plataforma paralela y/o distribuida que se utiliza,
de forma que se maximice la utilización de los
recursos para optimizar el rendimiento de la
plataforma. Los procedimientos de equilibrado de
carga deben encontrar un compromiso entre la
utilización de los procesadores que constituyen la
plataforma y los costes asociados a la
comunicación y sincronización entre esos
procesadores, de manera que se minimice el
tiempo de ejecución de la aplicación considerada.
El equilibrado dinámico aprovecha los
recursos de comunicación de la plataforma
paralela para intercambiar información de estado
y tareas entre los procesadores. Por tanto, los
procesadores utilizan la información local de que
disponen acerca del estado global del sistema,
para tomar las decisiones que permitan alcanzar
los objetivos de tiempo mínimo de respuesta y
rendimiento máximo. La eficiencia del
procedimiento de equilibrado de carga depende
del coste de comunicación entre procesadores, de
la complejidad asociada al procedimiento de toma
de decisiones en cada procesador, y del coste de
mantener información relativa al estado global del
sistema en cada uno de los nodos. Las estrategias
de equilibrado de carga dinámico pueden
implementarse según un modelo centralizado o
distribuido. En el caso centralizado, un procesador
se encarga de mantener información del estado
global del sistema y, a partir de ella, lleva a cabo
la asignación de tareas a procesadores. En el caso
de sistemas con un número elevado de
procesadores distribuidos geográficamente, esta
estrategia resulta inviable, por lo que las
estrategias distribuidas son las más adecuadas. En
estas estrategias distribuidas, los nodos del
sistema disponen de información local (más o
menos actualizada) acerca del estado global del
sistema y toman las decisiones de forma autónoma
a partir de ese estado local y de la información
que intercambian con otros procesadores. Dado
que los procesadores utilizan una información
parcial del estado del sistema, las decisiones que
se toman no suelen corresponder a la decisión
óptima.
En la literatura se describen numerosos
ejemplos de este tipo de procedimientos, que
conforman un espacio de diseño bastante
complejo. Consiguientemente, la toma de
decisiones sobre el tipo de procedimiento a elegir,
según el problema y la plataforma, resulta
bastante complicada. En este artículo ilustramos
las posibilidades de la computación evolutiva de
los algoritmos genéticos, en el ámbito del
equilibrado de carga dinámico y distribuido. Así,
en la Sección 2 se describen las características de
los procedimientos de equilibrado de carga
distribuidos y dinámicos. La Sección 3 presenta
un procedimiento genérico de equilibrado de
carga al que puede aplicarse un procedimiento de
optimización basado en los algoritmos genéticos.
Finalmente, los resultados experimentales se
muestran en la Sección 4 y las conclusiones del
artículo en la Sección 5.
2. Clasificación de los procedimientos de
equilibrado de carga
En los últimos años se han propuesto bastantes
procedimientos de equilibrado de carga [2-6]
buscando mejoras en la escalabilidad y la
portabilidad. En general, se trata de nuevas
propuestas para seleccionar y distribuir tareas
entre procesadores que minimicen el volumen de
trabajo a transferir entre procesadores, y que
mantengan o mejoren la localidad en las
comunicaciones del programa paralelo. Todo ello
minimizando la sobrecarga asociada a la
actualización y el mantenimiento de la
información de carga, o bien asegurando que se
encuentre dentro de límites razonables [7].
En un procedimiento completamente distribuido,
una vez se reparten las tareas entre los
procesadores, éstos se encargan tanto del
procesamiento de las tareas que se les asignan,
como de la redistribución de las tareas para dar
respuesta a los cambios que pueden producirse en
el estado de carga de los procesadores, debido a la
propia dinámica de la plataforma (modificaciones
del estado de carga de los distintos nodos por la
presencia de otras aplicaciones), a las
características de las aplicaciones (aplicaciones
irregulares), o por fallos en algún procesador u
otro elemento del hardware de la plataforma. En
un procedimiento distribuido, todos los
procesadores deben implementar, de un modo u
otro los procedimientos correspondientes a las
etapas de evaluación de la carga, iniciación de la
distribución [5,8], cálculo del volumen de trabajo
a transferir [5,6,9], selección de tareas, y
migración. Esas etapas se implementan utilizando
una serie de políticas:
- La política de información determina las
características del intercambio de información que
debe producirse entre los procesadores para que
éstos puedan tener una imagen lo más actualizada
posible del estado de carga de toda la plataforma.
El conjunto de información local y remota que
tiene un procesador es la que le permite
determinar si debe iniciar una redistribución de
carga, el volumen de trabajo que debe transferir, si
debe actuar como emisor o receptor, etc. Las
dimensiones más importantes para caracterizar
una política de información están relacionadas con
el marco espacial y con el marco temporal. Así,
una política de información debe fijar la topología
que definen los procesadores con información de
estado mutua. Un procesador puede tener
información de todos los procesadores de la
plataforma, de aquellos con los que tiene
relaciones de vecindad según la red de
interconexión, o de grupos de procesadores que
puedan establecerse con arreglo a otros criterios
(por ejemplo, un grupo de procesadores
seleccionados aleatoriamente) que pueden
cambiar temporalmente. Además, la política de
información debe establecer los instantes en los
que los procesadores deben intercambiar
información: política de información periódica o
a demanda. En la política de información
periódica, los procesadores intercambian
información de su carga con una frecuencia que
denominaremos frecuencia de equilibrado de
carga (LBF, de load balancing frequency). En el
caso de la política de información a demanda la
información de estado se intercambia cada vez
que se tiene que realizar una redistribución de la
carga, ya que se supone que es el momento en que
se van a producir cambios en las cargas de los
468 Tecnologías Grid, Clusters y Plataformas Distribuidas
procesadores que no se pueden determinar
localmente.
- La política de transferencia establece las
condiciones bajo las que debe producirse la
migración de las tareas entre los procesadores.
Para esto, cada procesador utilizaría la
información de carga (local y remota) y establece
si debe transferir tareas o solicitar que se le
envíen. Así, según quién inicie las operaciones de
equilibrado de carga, la política de transferencia
puede ser iniciada por el emisor, iniciada por el
receptor, o simétrica. En el caso de la
transferencia iniciada por el emisor, es el
procesador que está sobrecargado y tiene que
enviar tareas a otros procesadores el que comienza
las operaciones de distribución de carga. Si la
transferencia es iniciada por el receptor, el
procesador que necesita trabajo es el que inicia las
operaciones de distribución de carga. Finalmente,
en la política de transferencia simétrica, el
procesador que está sobrecargado y va a enviar
trabajo a otro procesador y el que solicita trabajo
deben sincronizarse para realizar la transferencia
de uno a otro.
- La política de localización determina los
procesadores que intervienen en las transferencias
de tareas que tienen lugar en el momento de
redistribuir la carga. Esta política está relacionada
con la de transferencia, ya que la decisión acerca
de si un procesador tiene un nivel de carga que le
hace emisor o receptor corresponde, precisamente,
a la política de localización. Se pueden distinguir
cuatro tipos de políticas de localización: las
políticas de un umbral, las de dos umbrales, las de
nivel mínimo/máximo de carga, y las aleatorias.
En las políticas de un umbral un nodo es emisor o
receptor según su carga esté por encima o por
debajo, respectivamente de un determinado nivel
que se toma como umbral. En las políticas de
localización de dos umbrales existen dos
umbrales, uno de ellos (el umbral superior)
establece el valor por encima del cual el
procesador se considera sobrecargado, y el otro (el
umbral inferior) representa el valor por debajo del
cual es procesador tiene un nivel de carga bajo.
Un procesador será emisor si su nivel de carga
está por encima del umbral superior, y receptor si
está por debajo del umbral inferior. A la hora de
establecer los umbrales hay que tener en cuenta
que la carga de la aplicación puede variar con el
tiempo, por lo tanto, es conveniente utilizar
umbrales que cambien dinámicamente,
adaptándose al nivel de carga del sistema.
- La política de selección es la que determina qué
tareas pueden elegirse para ser transferidas desde
un procesador que ha sido designado emisor a
partir de la política de localización (y en algunos
casos también a través de la política de
distribución, como veremos). Existen dos
alternativas para esta política. Por un lado está la
política de selección con corte forzado
(preemptive), en la que, entre las tareas que se
pueden elegir se incluye la tarea que se está
procesando. En cambio, en la selección de tareas
sin corte forzado (no preemptive) sólo se pueden
seleccionar las tareas que están pendientes de ser
procesadas. Las políticas de selección sólo
necesitan información que permita estimar la
carga de trabajo de cada una de ellas.
- La política de distribución es la que determina la
forma de equilibrar el trabajo entre los
procesadores que la política de localización ha
seleccionado como emisores o receptores. Esta
política está relacionada con las etapas de
evaluación la carga de trabajo, selección de tareas,
y de migración. En la política de distribución, las
tareas que pueden elegirse para constituir el
trabajo a intercambiar son las que permite la
política de selección de tareas.
Los parámetros que deben fijarse para
especificar completamente las alternativas de las
distintas políticas son:
- La granularidad, GRN, que indica el número de
tareas en que se divide el problema. Puede
variar entre 1 y N, donde N es el número
máximo de tareas que pueden considerarse en el
problema. Un valor bajo de GRN indica una
granularidad gruesa dado que se crean pocas
tareas. Se utiliza un parámetro entre 0 y 1 que
relaciona el valor de N y el de GRN.
- Los umbrales, TSD1 y TSD2, son los valores
utilizados como umbrales en el caso de una
política de localización con un umbral (TSD1) o
con dos umbrales (TSD1 es el umbral inferior y
TSD2 el umbral superior). Los valores de los
umbrales están entre 1 y GRN. Se utilizan los
parámetros TSDP1 y TSDP2, con valores entre
0 y 1, para establecer la relación entre TSD1 y
TSD2, respectivamente, con GRN.
- La frecuencia de equilibrado de carga, LBF, es
un parámetro que puede variar entre 1 y GRN
(el parámetro LBP es un parámetro entre 0 y 1
XVI Jornadas de Paralelismo, JP '2005 469
que relaciona LBF y la granularidad). Indica que
durante la ejecución del programa paralelo, un
procesador puede iniciar operaciones de
equilibrado de carga cada LBF intervalos de
tiempo.
while (not final) do
{
if (LBC==LBF) then
{
distribucion_de_carga();
LBC=0;
}
if (cola_trabajos no vacía) then
{
procesar_tarea();
LBC=LBC+1;
IC=IC-1;
}
}
Figura 1. Llamada a la función de equilibrado
Tabla 1. Parámetros del procedimiento descrito
Param. Defin/Rango Significado
N -
Tamaño del
problema. Estimación
del número máximo
de tareas del
problema.
P - Procesadores
GRN
ªGRANPuNº
(0<GRANP<=1)
Granularidad. El
problema se divide
inicialmente en GRN
tareas
TSD1
ªTSDP1uGRNº
(0<TSDP1<1)
Umbral inferior.
TSD2
ªTSDP2uGRNº
(0<TSDP2<1)
Umbral superior.
LBF
ªLBPuGRNº
(0<LBP<1)
Frecuencia de
distribución de
carga.
IC
Índice de carga.
Número de tareas que
residen en la cola de
trabajos del
procesador
LBC
Contador de
equilibrio de carga.
p Procesador actual
La clasificación de los procedimientos
distribuidos de equilibrado dinámico de carga
según las distintas políticas nos permite
parametrizar dichos procedimientos y transformar
un procedimiento genérico de equilibrado
dinámico distribuido que hemos desarrollado (se
describe en la siguiente sección) en el
procedimiento que se desee al fijar los parámetros
a los valores correspondientes a ese
procedimiento. La aproximación que seguimos es
similar en muchos aspectos a la que plantea la
programación genética [10], cuyo objetivo es
generar programas óptimos.
3. Procedimiento general de equilibrado
de carga dinámico y distribuido
En esta sección se describe un procedimiento
general de equilibrado dinámico y distribuido
[12]. Las definiciones, el rango y el significado de
los parámetros y variables que se utilizan en los
procedimientos se proporcionan en las Tablas 1 y
2.
Tabla 2. Parámetros del procedimiento descrito (cont.)
Parámetro Significado
E Número de procesadores
seleccionados como emisores por
la política de localización
R Número de procesadores
seleccionados como receptores por
la política de localización
CE Suma de los índices de carga (IC)
de todos los procesadores
emisores
CR Suma de los índices de carga (IC)
de todos los procesadores
receptores
IC Índice de carga. Número de tareas
que residen en la cola de trabajos
del procesador
SC Sobrecarga.
R
E
CR
CE
IC
SC



W(Ti) Carga de trabajo asociada a la
tarea Ti
En la Figura 1 se muestra la llamada al
procedimiento de equilibrado. Como se puede ver,
cada LBF intervalos de tiempo de procesamiento
se realiza una llamada a la función de equilibrado,
distribución_de_carga(). Esto no quiere decir que
se tengan que iniciar forzosamente operaciones
para redistribuir la carga. Cada intervalo de
tiempo es igual al tiempo de procesamiento de una
tarea. Por eso, cada vez que se termina una tarea
se reduce el índice de carga del procesador, IC, en
una unidad. Obviamente, el tamaño de la tarea, y
470 Tecnologías Grid, Clusters y Plataformas Distribuidas
por tanto, la duración del intervalo de tiempo
dependerá de la granularidad, GRN. Como se
muestra en la Tabla 1, existe una relación entre
LBF y GRN que se puede controlar con el
parámetro LBP, que toma valores entre 0 y 1.
La Figura 2 describe las llamadas que realiza
el procedimiento de distribución de carga a las
funciones que implementan las distintas políticas.
Las llamadas que finalmente se realizan dependen
del parámetro utilizado en la ejecución del
programa según las políticas que intervienen en la
distribución de carga. Así, en la función
distribucion_de_carga() aparecen en primer lugar
tres sentencias condicionales, cada una de las
cuales corresponde a una de las tres alternativas
que se consideran para la política de transferencia.
distribucion_de_carga()
{
if (politica_transferencia=iniciada_por_emisor)
{
if (IC>TSD) then
{
solicita_localizar_receptor(p);
intercambiar_información_carga
(proc_receptor);
seleccionar_tareas();
enviar_tareas(proc_receptor);
}
}
if (politica_transferencia=iniciada_por_receptor)
{
if (IC<TSD) then
{
solicita_localizar_emisor(p);
intercambiar_información_carga
(proc_emisor);
solicitar_tareas (proc_emisor);
recibir_tareas(proc_emisor);
}
}
if (politica_transferencia=iniciada_simétricamente)
{
intercambiar_información_carga ();
localizar_emisor_receptor();
if (p=proc_emisor)
{
seleccionar_tareas();
enviar_tareas(proc_receptor);
}
if (p=proc_receptor)
{
solicitar_tareas(proc_emisor);
recibir_tareas(proc_emisor);
}
}
}
Figura 2. Procedimiento distribución de carga
Si la transferencia es iniciada por el emisor, el
procesador comprueba si su índice de carga, IC, es
mayor que el umbral de carga superior, TSD. Si se
utiliza una política de localización con un umbral,
TSD será igual a TSD1, y si se utiliza una política
de localización con dos umbrales, TSD se habrá
fijado igual a TSD2. Si, efectivamente, es mayor
que el umbral que indica que el procesador está
sobrecargado, se convierte en emisor. En este caso
llama a la función solicita_localizar_receptor()
para que le proporcione el receptor o el conjunto
de receptores a los que debe enviar tareas, que se
determinan posteriormente utilizando las
funciones intercambiar_informacion_carga(),
seleccionar_tareas(), y enviar_tareas(). Con
respecto a la información intercambiada, aparte
del índice de la carga, IC, al iniciar el sistema los
nodos intercambian entre si informaciones como
la velocidad del CPU, la memoria disponible,
tamaño de caché, etc. Estas informaciones
permiten disponer de un mejor conocimiento del
estado de los procesadores, y pueden utilizarse en
la localización de los procesadores adecuados para
transferir carga. Además se pueden realizar los
cálculos de mínimos, máximos de carga, etc. que,
como veremos, se van a necesitar en algunas
políticas.
En el caso de que la transferencia sea iniciada
por el receptor, en primer lugar se llama a la
función solicita_localizar_emisor(), para
identificar el posible emisor del que pueda recibir
las tareas que necesita el procesador. A
continuación se intercambia información de carga
con el emisor o emisores posibles a través de la
función intercambiar_informacion_carga(), y se
solicita el envío de tareas mediante la función
solicitar_tareas(). Después, el procesador espera
recibir estas tareas antes de proseguir con su
procesamiento.
Si la transferencia se inicia simétricamente,
tras intercambiar información de carga, se llama a
la función localizar_emisor_receptor(). Esta
función determina si el procesador que hace la
llamada es emisor o receptor y, en cada caso,
devuelve uno o varios receptores o emisores,
respectivamente. Si la función
localizar_emisor_receptor() indica que el
procesador no es ni emisor ni receptor, el
procesador no interviene en la redistribución de
carga. Si el procesador es seleccionado como
emisor llama a la función de seleccionar_tareas()
XVI Jornadas de Paralelismo, JP '2005 471
y a la de enviar_tareas(), y si es designado como
receptor llama a las funciones solicitar_tareas() y
después espera recibirlas al llamar a
recibir_tareas().
La función seleccionar_tareas() permite
determinar el conjunto de tareas que pueden
considerarse a la hora de elegir aquellas que deben
emitirse. De esta forma, en la función aparecen
dos opciones que corresponden a las dos
alternativas consideradas para la política de
selección de tareas: con corte forzado
(preemptive) o sin corte forzado (no_preemptive).
Además, en la función seleccionar_tareas() se
llama a la función elegir(). Esta función es la que
implementa la política de distribución, por lo que
su forma depende de las características concretas
del tipo de procedimiento que se considere
(difusión, intercambio dimensional, etc.). La
función elegir() se llama con un parámetro que se
refiere al conjunto de tareas que pueden ser
elegidas según la política de selección (con o sin
corte forzado) y, en la implementación que hemos
realizado, además tengan asociado un volumen de
trabajo superior a un índice de carga SC, cuya
definición aparece en la Tabla 1. En el cálculo de
SC intervienen aspectos relacionados con la
topología de conexión que se considere entre los
procesadores (todos, los vecinos, los
pertenecientes a un grupo, etc.).
La forma de esas funciones de localización es
depende del tipo de política de transferencia que
se utilice, poniéndose de manifiesto la
interrelación entre las dos políticas. La función
localizar_emisor_receptor(), se llama cuando la
política de transferencia es simétrica. En ella
aparecen las opciones correspondientes a las
cuatro alternativas para la política de localización.
Así según el índice de carga IC esté por debajo o
por encima de TSD1 el procesador actuará como
receptor o emisor, respectivamente, en el caso de
que la política de localización de un umbral. En el
caso de una política de localización de dos
umbrales se hace lo mismo pero se utilizan los
umbrales TSD1 como umbral de carga baja y
TSD2 como umbral de sobrecarga. Si la política
de localización se basa en la mínima/máxima
carga hay que comparar el índice de carga con los
valores de carga máxima y mínima del conjunto
de procesadores con los que un procesador puede
intercambiar carga. Estos cálculos se hacen
cuando se realizan las llamadas a la función
intercambiar_información_carga() en el caso de
que se utilice esta política de localización. El
conjunto de procesadores que intervienen a la hora
de hacer este cálculo viene determinado por la
alternativa de topología de la política de
información. La forma de determinar el emisor y
receptor en el caso de una política de localización
aleatoria también precisa información de la carga
máxima y mínima del correspondiente conjunto
de procesadores.
Para determinar el índice (los índices) del
emisor (posibles emisores) o receptor (posibles
receptores), respectivamente, para el procesador
designado como receptor o emisor se utilizan las
funciones emisión() y recepción(). Estas funciones
dan lugar a comunicación entre aquellos
procesadores que pueden transferirse tareas según
las alternativas topológicas de la política de
distribución. Desde estas funciones, además,
también se puede llamar a las funciones
localizar_emisor() (en el caso de emisión()) y
localizar_receptor() (en el caso de recepción()),
que se describen a continuación.
La función localizar_receptor() permite
determinar un procesador receptor en la política
de transferencia iniciada por el emisor. Además de
desde la función recepción(), la función
localizar_receptor() se llama desde la función
solicitar_localizar_emisor(), que genera las
llamadas a localizar_emisor(procesador) desde
procesador en todos aquellos procesadores que la
política de distribución indique que pueden
intercambiar trabajo con procesador. La función
ejecutada en el procesador p envía a
solicitar_localizar_emisor() en procesador el
índice del procesador, p, si verifica de las
condiciones para ser receptor que establece la
política de localización que se utiliza.
La función localizar_emisor() es análoga a la
función localizar_receptor() pero en este caso
para el procesador o procesadores a los que se les
puede solicitar tareas. Esta función se llama desde
solicitar_localizar_emisor() en el caso de que la
política de transferencia sea iniciada por el
receptor (además se puede llamar desde emisión(),
como se ha indicado).
Para explorar el espacio de diseño de los
procedimientos distribuidos de equilibrado
dinámico de carga se ha utilizado un algoritmo
genético (Figura 3) que trabaja en el espacio
definido por las distintas alternativas de las
políticas de información, transferencia,
localización, y selección, más los valores que
472 Tecnologías Grid, Clusters y Plataformas Distribuidas
pueden tomar los parámetros LBF, GRN, y los
umbrales TSD1 y TSD2 (valores reales). Su
objetivo es encontrar las configuraciones de las
políticas y los valores de los parámetros para
dichas políticas que proporcionen una mejor
distribución de carga para una aplicación paralela.
En la población de soluciones que evoluciona
generación a generación se aplica una estrategia
elitista dado que se mantiene la solución más
idónea que se ha encontrado en la generación
anterior. Precisamente, la capacidad para recordar
información útil relativa a generaciones pasadas
es una de las estrategias que se ha venido
considerando en la aplicación de los algoritmos
evolutivos a problemas de optimización dinámica,
en los que las soluciones obtenidas deben tener en
cuenta la naturaleza cambiante del problema [11].
1. Inicializar parámetros: Tamaño de la Población,
Probabilidades de Cruce y Mutación.
2. Generar una población inicial aleatoriamente.
3. Evaluar la idoneidad de los individuos de la
población. La idoneidad de un individuo es la
ganancia de velocidad que consigue el
procedimiento de distribución de carga que
representa.
4. Seleccionar una nueva población. La selección
utiliza el método de la ruleta, pero tomando
siempre el mejor individuo para la siguiente
iteración.
5. Aplicar operadores. Se realiza cruce en un punto
y mutación [REN96]
6. Ir a 3 si no se ha alcanzado la condición de
final.
Figura 3. Pseudocódigo del algoritmo genético
desarrollado
4. Resultados experimentales
Los resultados que se muestran aquí corresponden
a un algoritmo paralelo de ramificación y poda
para el problema del viajante de comercio. En este
caso el volumen de cómputo de programa no se
conoce de antemano, y depende del propio
proceso de búsqueda implícita que implementa el
algoritmo. Así, es imprescindible utilizar un
procedimiento de equilibrado de carga dinámico.
Se proporcionan (Tabla 3 y Figuras 4-6) los
resultados obtenidos para un tamaño de problema
correspondiente a 8 ciudades, en un cluster con 8
nodos biprocesadores a 2.4 GHz, 2 GB de
memoria cada uno y Gigabit Ethernet.
Figura 4 : Idoneidad (1/Tiempo paralelo) para las
alternativas con transferencia iniciada por el emisor
Figura 5. Idoneidad (1/Tiempo paralelo) para las
alternativas con transferencia iniciada por el receptor
La Tabla 3 presenta, para los procedimientos
alternativos de la política de transferencia
simétrica (la que proporciona mejores valores de
ganancia de velocidad), los valores de los
parámetros a los que se converge el algoritmo
genético y los valores de la idoneidad y de la
utilización media obtenidos (entre paréntesis se
indican las desviaciones típicas). Como valor de
idoneidad se utiliza la inversa del tiempo de
ejecución paralela (se evita evaluar el tiempo de
ejecución secuencial del algoritmo, que puede
llegar a ser extremadamente elevado). Las Figuras
4, 5, y 6 representan la evolución de la idoneidad
a través de las sucesivas generaciones del
algoritmo genético en los procedimientos
alternativos de cada política de transferencia.
Los resultados obtenidos para el algoritmo de
ramificación y poda muestran que la política de
XVI Jornadas de Paralelismo, JP '2005 473
transferencia simétrica proporcionan mejores
valores para la ganancia de velocidad. Los
procedimientos con política de transferencia
iniciada por el emisor son mejores que los de
transferencia iniciada por el receptor. Aquí, las
utilizaciones de los procedimientos simétricos son
similares en algunos casos a las de los
procedimientos iniciados por el receptor, y son los
procedimientos con transferencia iniciada por el
emisor los que tienen utilizaciones más bajas.
En cuanto a las distintas alternativas para cada
política de transferencia tenemos que en el caso
de los procedimientos con transferencia iniciada
por el emisor (Figura 4) y por el receptor (Figura
5) todas las alternativas convergen hacia valores
bastante próximos: puede considerarse que son
casi equivalentes en cuanto a la ganancia de
velocidad que permiten alcanzar. En cuanto a los
procedimientos con transferencia simétrica, la
Figura 6 pone de manifiesto comportamientos
relativamente diferentes para distintas políticas de
localización y selección. En este caso, los
procedimientos basados en un umbral (con o sin
corte forzado) y el procedimiento basado en dos
umbrales sin corte forzado son los que
proporcionan mejores prestaciones.
Tabla 3 Convergencia de los parámetros para las
alternativas con política de transferencia simétrica
Procedimiento LBF GRN TSD1 TSD2
1/(T
Par)
Util.
Máx.
Umbral
(Preemption)
107
(12)
1 (1)
101
(7)
279
(18)
1.87
(0.03)
0.09
Umbral
(No-
Preemption)
103
(8)
2 (1)
106
(8)
279
(16)
1.88
(0.02)
0.11
Dos Umbrales
(Preemption)
111
(11)
2 (1)
109
(12)
280
(12)
1.58
(0.02)
0.17
Dos Umbrales
(No
Preemption)
116
(14)
2 (1)
94
(6)
297
(8)
1.80
(0.03)
0.13
Mín/máx
(Preemption)
105
(7)
2 (1) - -
1.00
(0.01)
0.05
Mín/máx
(No
Preemption)
119
(14)
5 (3) - -
1.24
(0.03)
0.03
Figura 6: Idoneidad (1/Tiempo paralelo) para las
alternativas con política de transferencia simétrica
La convergencia a los parámetros GRN, LBF,
TSD1, y TSD2 muestra mayores desviaciones que
en otros programas de prueba que se han
analizado [12]. Además existe una mayor
variación entre los parámetros a los que se
converge según los procedimientos. Por ejemplo
GRN está entre 1 y 2, aunque en algunos casos es
igual a 5. Los valores de LBF a los que se
converge están entre 103 y 121 para los
procedimientos con transferencia iniciada por el
emisor y los simétricos, pero en el caso de la
transferencia iniciada por el receptor son 85 y 75,
respectivamente, para las dos alternativas
consideradas. Los valores de TSD1 están entre 90
y 117, y los valores de TSD2 están entre 273 y
297, aunque en un caso llega a 328 (transferencia
iniciada por el emisor con localización basada en
el máximo/mínimo nivel de carga sin corte
forzoso). Así, el mejor procedimiento para el
algoritmo de ramificación y poda aplicada al
problema del viajante de comercio con 8 ciudades
utiliza política de transferencia simétrica, política
de localización de un umbral, y política de
selección sin corte forzoso con GRN=2,
LBF=103, y TSD1=106.
5. Conclusiones
A partir de las alternativas que se distinguen en las
políticas de información, transferencia,
localización, distribución, y selección, que definen
un procedimiento de distribución de carga se han
parametrizado los diferentes procedimientos y se
ha aplicado la búsqueda genética en el espacio de
diseño definido. Así, se puede llevar a cabo una
474 Tecnologías Grid, Clusters y Plataformas Distribuidas
optimización de los parámetros que definen el
comportamiento del procedimiento de equilibrado
de carga, que así se aborda mediante una
aproximación análoga a la que plantea la
programación genética.
Los resultados experimentales obtenidos
ponen de manifiesto que en todos los casos
analizados la política de transferencia simétrica
con política de información periódica es mejor
que la iniciada por el emisor y el receptor ambas
con la política de información en demanda. Estos
resultados coinciden con las conclusiones
obtenidas en otros trabajos [2]. En cuanto a las
políticas de localización, las más eficientes suelen
ser las basadas en uno o dos umbrales, y en cuanto
a las políticas de selección, en algunos casos las
mejores son las de corte forzoso (preemption) y en
otros las que no utilizan corte forzoso (no-
preemption). Los procedimientos con política de
localización aleatoria son los que proporcionan las
peores prestaciones.
6. Referencias
[1] Theys, M.D., et al.:”What are the Top Ten most
Influential Parallel and Distributed Processing
concepts of the past millenium?”. Journal of
Parallel and Distributed Computing, Vol.61,
pp.1827-1841, 2001.
[2] Antonis, K.; Garofalakis, J.; Mourtos, I. ;
Spirakis, P. : “A hierarchical adaptive distributed
algorithm for load balancing”. J. Parallel Distrib.
Comput., 64, pp.151-162, 2004.
[3] Barker, K.; Chernikov, A.; Christoides, N.;
Pingali, K.:”A Load Balancing Framework for
Adaptive and Asynchronous Applications”. IEEE
Trans. on Parallel and Distributed Systems,
Vol.15, No. 2, pp.183-192. Febrero, 2004.
[4] Watts, J; Taylor, S. “A Practical Approach to
Dynamic Load Balancing”. IEEE Trans. on
Parallel and Distributed Systems, Vol. 9, No.
3,pp. 235-247 March 1998
[5] Xu, C.; Lau, F.:”Load Balancing in Parallel
Computers”. Kluwer Academic Publishers, 1997.
[6] Willebeek-LeMair, M; Reeves, A.: “Strategies for
Dynamic Load Balancing on Highly Parallel
Computers”, IEEE Transactions on Parallel and
Distributed Systems, 4:979-993, 1993.
[7] Dandamudi, S., Piotrowski, A. ,“A Comparative
Study of Load Sharing on Networks of
Workstations”, Proceedings of the International
Conference on Parallel and Distributed
Computing Systems, New Orleans.
[8] Muniz, F.; Zaluska, E.:”Parallel Load-Balancing:
An extension to the Gradient Model”. Parallel
Computing, Vol. 21, pp.287-301, 1995.
[9] Horton, G.:”A Multi-Level Difussion Method for
Dynamic Load Balancing”. Parallel Computing,
Vol.19, pp.209-218, 1993.
[10] Koza, J.R.:”Genetic Programming: On the
Programming of Computers by Means of Natural
Selection”. MIT Press. Cambridge, Mass., 1992.
[11] Branke, J.:”Evolutionary Optimization in Dinamic
Environments”. Kluwer, 2001.
[12] Aldasht, M.; Ortega, J.; Puntonet, C.G.; Díaz,
A.F.:”A Genetic Exploration of Dynamic Load
Balancing Algorithms”. IEEE Conference on
Evolutionary Computation, Portland, Oregon,
2004.
XVI Jornadas de Paralelismo, JP '2005 475
'LVWULEXWHG6\VWHPIRU5HPRWH3URJUDPPLQJRI0XOWLSOH
1HWZRUN5RERWV6\VWHP3HUIRUPDQFH 3DUDOOL]DWLRQ,VVXHV

5DXO:LU]
'HSWRI&RPSXWHU6FLHQFH 
(QJLQHHULQJ
-DXPH,8QLYHUVLW\
&DVWHOORQ6SDLQ
ZLU]#JXHVWXMLHV
5DXO0DULQ
'HSWRI&RPSXWHU6FLHQFH 
(QJLQHHULQJ
-DXPH,8QLYHUVLW\
&DVWHOORQ6SDLQ
UPDULQ#LFFXMLHV
(QULTXH64XLQWDQD2UWt
'HSWRI&RPSXWHU6FLHQFH 
(QJLQHHULQJ
-DXPH,8QLYHUVLW\
&DVWHOORQ6SDLQ
TXLQWDQD#LFFXMLHV
  
$EVWUDFW
6LQFHZHKDYHEHHQXVLQJWKH8-,7HOH/DE
DV D WRRO WR DOORZ VWXGHQWV DQG VFLHQWLVW RI RXU
8QLYHUVLW\ WR SURJUDP UHPRWHO\ VHYHUDO YLVLRQ
EDVHG QHWZRUN URERWV 'XULQJ WKLV SHULRG ZH
KDYH OHDUQHG WKDW PXOWLWKUHDG UHPRWH
SURJUDPPLQJ FRPELQHG ZLWK D GLVWULEXWHG
PXOWLURERW DUFKLWHFWXUH DV ZHOO DV DGYDQFHG
PXOWLPHGLDXVHULQWHUIDFHVDUHYHU\FRQYHQLHQW
IOH[LEOHDQGSURILWDEOHIRUWKHGHVLJQRID7HOH
/DERUDWRU\ 7KH GLVWULEXWHG V\VWHP DUFKLWHFWXUH
SHUPLWVDQ\H[WHUQDODOJRULWKPWRKDYHDFFHVVWR
DOPRVW HYHU\ IHDWXUH RI VHYHUDO QHWZRUN URERWV
HJ URERWV FRQWURO QHWZRUN FDPHUDV REMHFW
UHFRJQLWLRQ HWF ,Q WKLV SDSHU ZH SUHVHQW WKH
PXOWLURERW V\VWHP DUFKLWHFWXUH DQG LWV
SHUIRUPDQFH E\ SURJUDPPLQJ WZR FORVHG ORRS
H[SHULPHQWVXVLQJWKH,QWHUQHWDVFRPPXQLFDWLRQ
PHGLDEHWZHHQWKHXVHUDOJRULWKPDQGWKHUHPRWH
URERWVUHPRWHYLVXDOVHUYRLQJ7KHH[SHULPHQWV
VKRZZKLFKFRQGLWLRQVRI,QWHUQHWODWHQFLHVDQG
EDQGZLGWK DUH DSSURSULDWH IRU WKH YLVXDO
VHUYRLQJ ORRS 0RUHRYHU UHVXOWV VKRZ WKDW
SHUIRUPDQFHFRXOGEHLPSURYHGE\SDUDOOHOL]LQJ
WKH FRPSXWHU YLVLRQ PRGXOH ELQDUL]DWLRQ DQG
VHJPHQWDWLRQ ZKLFK LV ODXQFKHG IRU HYHU\
LWHUDWLRQ RI WKH FRQWURO ORRS 3DUDOOHOL]DWLRQ
LVVXHV DUH RXWOLQHG LQ RUGHU WR REWDLQ VXFK DQ
LPSURYHPHQWLQWKHV\VWHPSHUIRUPDQFH
.H\ZRUGV 'LVWULEXWHG 6\VWHPV ,QWHUQHW
1HWZRUN5RERWV
 ,QWURGXFWLRQ
(QDEOLQJUHPRWHSURJUDPPLQJRIURERWLFV\VWHPV
SHUPLWVXVWRGHYHORSH[WHUQDOSURJUDPVWKDWWDNH
FRQWURO RYHU D ODUJH VHW RI URERWLF IXQFWLRQV
>@>@ 7KXV IRU H[DPSOH ZH FRXOG GHVLJQ DQ
H[SHULPHQWLQ-DYDIRUSHUIRUPLQJDFORVHGORRS
PDQLSXODWLRQLHUHPRWHYLVXDOVHUYRLQJRUZH
FRXOG HYHQ XVH WKLV LQWHUIDFH IRU GHVLJQLQJ D
YRLFHRSHUDWHGURERW
 0RUHRYHU ZH DUH YHU\ LQWHUHVWHG LQ WKH
GHVLJQRIGLVWULEXWHGDUFKLWHFWXUHVIRUWKHUHPRWH
FRQWURO RI PXOWLURERW V\VWHPV $ YHU\ JRRG
H[DPSOHRIUHPRWHURERWSURJUDPPLQJLQRUGHUWR
YDOLGDWH WKHVH DUFKLWHFWXUHV LV LQ IDFW WKH UHPRWH
YLVXDO VHUYRLQJ FRQWURO>@>@,W XVHVVHTXHQFHV
RI FDPHUD LQSXWV LQ RUGHUWREULQJWKHURERWVWR
WKH GHVLUHG SRVLWLRQ LQ DQ LWHUDWLYH ZD\ ,Q WKLV
SDSHU ZH HQDEOHG WKH VWXGHQWV DQG VFLHQWLVWV LQ
RXU XQLYHUVLW\ WR H[SHULPHQW ZLWK WKHLU UHPRWH
YLVXDOVHUYRLQJDOJRULWKPVWKURXJKDUHPRWHUHDO
HQYLURQPHQWLQVWHDGRIXVLQJVLPXODWLRQWRROV
 ,QWHUHVWLQJ UHVXOWV DERXW WKH HIIHFW RI WKH
,QWHUQHW ODWHQFLHV RYHU WKH FRQWURO ORRS DUH
SUHVHQWHG ZKLFK DUH D FRQVHTXHQFH RI WKH
VHOHFWHG V\VWHP DUFKLWHFWXUH %HVLGHV WKLV WKH
SDSHUGHVFULEHVVHYHUDOSDUDOOHOL]DWLRQWHFKQLTXHV
WKDWFDQEHDSSOLHGWRWKLVV\VWHPDUFKLWHFWXUHLQ
RUGHU WR HQKDQFH WKH V\VWHP SHUIRUPDQFH $IWHU
VWXG\LQJ WKH WLPH ODWHQF\ UHVXOWV ZH KDYH
DSSUHFLDWHG WKDW E\ SDUDOOHOL]LQJ WKH FRPSXWHU
YLVLRQ PRGXOH LH ELQDUL]DWLRQ VHJPHQWDWLRQ
HWFZHFDQJUHDWO\LPSURYHWKHHIILFLHQF\RIWKH
UHPRWHYLVXDOVHUYRLQJFRQWURO
 7KH JRDO RI WKLV SDSHU LV WR RIIHU D
GLVWULEXWHG DUFKLWHFWXUH WKDW HQDEOHV WKH UHPRWH
FRQWURO RI DFWLYLWLHV WKDW FDQQRW EH FRQWUROOHG
PDQXDOO\RUORFDOO\DQGDQVZHURSHQLVVXHVVXFK
DVWKHIROORZLQJ+RZWKHGLVWULEXWHGDUFKLWHFWXUH
DQG WKH QHWZRUN LQIOXHQFH WKH V\VWHP
SHUIRUPDQFH"&DQZHLPSURYHWKHWHOHRSHUDWLRQ"
&DQZHLPSURYHWKHUHPRWHSURJUDPPLQJ":KDW
SDUDOOHOL]DWLRQWHFKQLTXHVDUHGXHWRLPSURYHWKH
V\VWHPSHUIRUPDQFH"
1HWZRUNURERW
7KHFRQFHSWRI1HWZRUNURERWUHFHQWO\FDPHXSDW
WKH:RUNVKRS³1HWZRUN5RERWV´ZLWKLQWKH,(((
,&5$  :RUOG &RQJUHVV
 ,Q WKLV HYHQW ZH
UHDOL]HG WKDW PDQ\ LQWHUHVWLQJ LVVXHV UHODWHG WR
QHWZRUNLQJDQGGLVWULEXWHGV\VWHPVDUHVWLOORSHQ
DQG XQUHVROYHG WKDW LV ZKHQ WKH GHYLFH WKDW
FRPPXQLFDWHV LV DEOHWRVHQVHPRYH FRRSHUDWH
OHDUQDQGUHDFWLHQHWZRUNURERW>@>@
$ QHWZRUN URERW LV D URERWLF GHYLFH
FRQQHFWHG WR D FRPPXQLFDWLRQV QHWZRUN VXFK DV
WKH,QWHUQHWRU/$17KHQHWZRUNFRXOGEHZLUHG
RU ZLUHOHVV DQG EDVHG RQ D QXPEHU RI GLIIHUHQW
SURWRFROV VXFK DV 7&3 8'3 RU  0DQ\
QHZ DSSOLFDWLRQV DUH QRZ EHLQJ GHYHORSHG
UDQJLQJIURPDXWRPDWLRQWRH[SORUDWLRQ7KHUHDUH
WZRVXEFODVVHVRI1HWZRUNHG5RERWV
  7HOHRSHUDWHG ZKHUH KXPDQ
VXSHUYLVRUVVHQGFRPPDQGVDQGUHFHLYHIHHGEDFN
YLD WKH QHWZRUN 6XFK V\VWHPV VXSSRUW UHVHDUFK
HGXFDWLRQ DQG SXEOLF DZDUHQHVV E\ PDNLQJ
YDOXDEOHUHVRXUFHVDFFHVVLEOHWREURDGDXGLHQFHV
  $XWRQRPRXVZKHUHURERWVDQGVHQVRUV
H[FKDQJH GDWD YLD WKH QHWZRUN ,QVXFKV\VWHPV
WKH VHQVRU QHWZRUN H[WHQGV WKH HIIHFWLYH VHQVLQJ
UDQJH RI WKH URERWV DOORZLQJ WKHP WR
FRPPXQLFDWHZLWKHDFKRWKHURYHUORQJGLVWDQFHV
WRFRRUGLQDWHWKHLUDFWLYLW\7KHURERWVLQWXUQFDQ
GHSOR\UHSDLUDQGPDLQWDLQWKHVHQVRUQHWZRUNWR
LQFUHDVH LWV ORQJHYLW\ DQG XWLOLW\ $ EURDG
FKDOOHQJHLVWRGHYHORSDVFLHQFHEDVHWKDWFRXSOHV
FRPPXQLFDWLRQ WR FRQWURO WR HQDEOH VXFK QHZ
FDSDELOLWLHV

7KH8-,WHOH/DE
,Q 2FWREHU  WKH 8-, 2QOLQH URERW ZDV
FRQQHFWHG WR WKH ZHE IRU UHVHDUFK SXUSRVHV ,W
FRQVLVWHG RI DQ HGXFDWLRQDO PDQLSXODWRU URERW
ZLWK WKUHH FDPHUDV ZKLFK HQDEOHG D XVHU WR
UHPRWHO\ FRQWURO SLFNDQGSODFH RSHUDWLRQV RI


 ,((( ,QWHUQDWLRQDO &RQJUHVV RI 5RERWLFV DQG
$XWRPDWLRQ%DUFHORQD6SDLQ
REMHFWVORFDWHGRQDERDUG([SHULPHQWVUHJDUGLQJ
GLVWULEXWHG V\VWHPV REMHFW UHFRJQLWLRQ YLUWXDO
UHDOLW\ DXJPHQWHG UHDOLW\ VSHHFK UHFRJQLWLRQ
DQGWHOHPDQLSXODWLRQZHUHDFFRPSOLVKHGLQRUGHU
WR HQKDQFH WKH ZD\ XVHUV LQWHUDFWHG ZLWK WKH
V\VWHP$JDLQZHSURYLGHGWKHSRVVLELOLW\WRWKH
VWXGHQWVWRSURJUDPPRUHVRSKLVWLFDWHGSLFNDQG
SODFHRSHUDWLRQVXVLQJWKLVWLPHERWKWKHRIIOLQH
DQGWKHRQOLQHURERWV
Tele-Laboratory
Inputs
Experiments (Algorithms)
3XEOLFFODVV([SHULPHQW
PDLQ^
IRUL HQGL^

`
`
Voice Commands
Speech
Recognizer
&
Sinthesizer
Server Side
Client Side
Servers Manager
Mentor
Server I
Mentor
Server II
Motoman
Robot
Adept One
Robot
Mitsubishi
PA10 Robot
CORBA CORBA CORBA CORBA CORBA
Database
Server
JDBC
Internet RMI
Experiments
Server
Robotics
Tutorial
Collaborative
Tools
Lab
Exercices
Visually Guided Grasping
Object Recognition
Natural Language Recognition
JAVA 3D Virtual & Augmented Reality
Computer Vision
Online Robots Controller
TCP/IP
(Sockets)

)LJXUH6LPSOLILHGDUFKLWHFWXUHRIWKH8-,7HOH/DE
 :H FRQVLGHUHG LW QHFHVVDU\ WR HQKDQFH WKH
V\VWHP LQ RUGHU QRW RQO\ WR OHW VWXGHQWV FRQWURO
WKH URERW IURP D XVHU LQWHUIDFH EXW DOVR WR
SURJUDP LW E\ XVLQJ DQ\ VWDQGDUG SURJUDPPLQJ
ODQJXDJH,Q$SULOWKH8-,7HOH/DESURMHFW
FDPHXSZLWKWKHJRDORIGHVLJQLQJD-DYDOLEUDU\
FDOOHG ³([SHULPHQWV´ ZKLFK DOORZHG VWXGHQWV
SURJUDP WKHLU RZQ FRQWURO DOJRULWKPV IURP DQ\
FRPSXWHU FRQQHFWHG WR WKH ,QWHUQHW DQG H[HFXWH
WKHPZLWKWKHUHDOURERW6RPHSLORWH[SHULPHQWV
KDYH EHHQ SHUIRUPHG ZLWK UHVHDUFKHUV DQG
VWXGHQWVVLQFHWKHQ7KHLQWHUHVWLQWKHGHVLJQRI
,QWHUQHWEDVHG 7HOH/DERUDWRULHV LV LQFUHDVLQJ
HQRUPRXVO\DQGWKLVWHFKQLTXHLVVWLOOYHU\QHZ
$YHU\JRRGH[DPSOHRIH[SHULPHQWVLQWKLVDUHD
FDQEHIRXQGLQ>@

5HPRWHYLVXDOVHUYRLQJ
9LVXDOVHUYRLQJLVDUDSLGO\PDWXULQJDSSURDFKWR
WKHFRQWURORIURERWPDQLSXODWRUVWKDWLVEDVHGRQ
YLVXDO SHUFHSWLRQ RI URERW DQG ZRUNSLHFH
ORFDWLRQ 0RUH VSHFLILFDOO\ YLVXDO VHUYRLQJ
LQYROYHV WKH XVH RI RQH RU PRUH FDPHUDV DQG D
FRPSXWHUYLVLRQV\VWHPWRFRQWUROWKHSRVLWLRQRI
WKHURERW
VHQGHIIHFWRUUHODWLYHWRWKHZRUNSLHFH
DVUHTXLUHGE\WKHWDVN,WLVDPXOWLGLVFLSOLQDU\
478 Tecnologías Grid, Clusters y Plataformas Distribuidas
UHVHDUFKDUHDVSDQQLQJFRPSXWHUYLVLRQURERWLFV
NLQHPDWLFV G\QDPLFV FRQWURO DQG UHDOWLPH
V\VWHPV
 5HPRWH 9LVXDO 6HUYRLQJ WHFKQLTXHV DUH
QRUPDOO\XVHGIRUWHOHRSHUDWLRQXVLQJDUHDOWLPH
FRPPXQLFDWLRQ EXV :KHQ XVLQJ WKH ,QWHUQHW DV
WKHFRPPXQLFDWLRQPHGLDWKHFKDOOHQJHLVPRUH
GLIILFXOWGXHWRWKHIDFWWKDWXQSUHGLFWDEOHWLPH
GHOD\VDQGEDQGZLGWKDUHLQWURGXFHG0RUHRYHU
LIWKHV\VWHPLVGHVLJQHGLQDGLVWULEXWHGZD\DQG
DOORZVWKHFRQFXUUHQWFRQWURORIPXOWLSOHQHWZRUN
URERWVWKHFKDOOHQJHLVHYHQPRUHFRPSOH[
7KH LGHD LV WR LQWURGXFH WKH ,QWHUQHW
FRPPXQLFDWLRQFKDQQHOLQVLGHWKHYLVXDOVHUYRLQJ
ORRSDQGWKHQWRHQDEOHWKHUHPRWHSURJUDPPLQJ
RI D UHDO ,QWHUQHW WHOHODERUDWRU\ WR WHVW WKRVH
DOJRULWKPVLQDVLPSOHZD\

)LJXUH9LVXDO6HUYR&RQWURO6WUXFWXUH
 5HPRWHYLVXDOVHUYRLQJVHWXS
+DUGZDUHGHVFULSWLRQ
7ZR HGXFDWLRQDO URERW PDQLSXODWRUV VHH )LJXUH
 DQG VHYHQ FDPHUDV DUH SUHVHQWHG WZR WDNLQJ
LPDJHV IURP WKH WRS RI HDFK VFHQH RQH SDQWLOW
FDPHUDIURPWKHVLGHWZRFDPHUDVVLWXDWHGRQWKH
JULSV DQG WZR PRUH FDPHUDV IURP WKH IURQW $OO
WKHVH GHYLFHV FDQ EH DFFHVVHG DQG SURJUDPPHG
FRQFXUUHQWO\ E\ D UHPRWH DOJRULWKP 7KH WRS
FDPHUDV DUH FDOLEUDWHG DQG XVHG DV LQSXW WR WKH
DXWRPDWLF REMHFW UHFRJQLWLRQ PRGXOH DQG '
PRGHOFRQVWUXFWLRQ7KHRWKHUILYHFDPHUDVWZR
FDPHUDV IRU HDFK PDQLSXODWRU SOXV WKH SDQWLOW
FDPHUD RIIHU GLIIHUHQW YLHZ SRLQWV WR WKH XVHU
ZKHQDWHOHRSHUDWLRQPRGHLVQHFHVVDU\LQRUGHUWR
DFFRPSOLVK D GLIILFXOW WDVN HJ PDQLSXODWLQJ
RYHUODSSHG REMHFWV )RU WKH UHVXOWV SUHVHQWHG LQ
WKLV SDSHU ZH DUH XVLQJ DQ ,QWUDQHW UXQQLQJ DW
0ESV


)LJXUH5RERWLF7HOH/DE
([SHULPHQWVGHVFULSWLRQ
REMOTE PROGRAMMING EXPERIMENTS ARCHITECTURE
Experiment
Experiment_template
Experiment1 Experiment3
Experiment2 Experiment4
Inherits
Uses
ONLINE TELELAB
Internet
TCP/IP
Connection

)LJXUH7KH([SHULPHQWV/LEUDU\
,Q RUGHU WR SURJUDP UHPRWHO\ WKH 7HOH
/DERUDWRU\ ZH SURYLGH D 7&3,3 LQWHUIDFH WKDW
FDQEHHDVLO\PDQDJHGWKURXJKRXU-DYD/LEUDU\
³([SHULPHQWV´ 7KLV OLEUDU\ DOUHDG\ LQFOXGHV
WHPSODWHVWKDWDUHH[DPSOHVRIVLPSOHH[SHULPHQWV
WKDWPDQDJHWKHUHPRWHURERWVDQGWKHFDPHUDV
XVI Jornadas de Paralelismo, JP '2005 479
// Fixed part that disconnects the experiment from the server
et.disconnect();
}
}
// Please write here your algorithm to control the robot
//E.g.: et.sendOrder(“move to position 10 10 10”, true);
//We obtain the Vision Data from the server
SceneManagerSer sms = et.getSceneManagerSer();
// Fixed part that connects with the server
Experiment_template et = new Experiment_template("127.0.0.1",7745);
et.connect();
public class Experiment_template extends Experiment {
public Experiment_template(String host, int port) {
super(host,port);
}
public static void main(String[] args) {
1. Connection
We get connection to
the Robotic System
User Interface that runs
on the local machine
and port 7745
2. Get Data
We make this call to ask
the server about the
Scene Information from
the calibrated camera
(i.e. recognized objects,
vision features, etc.)
3. To be filled
Space to be filled by the
student or scientist that
is designing the
experiment.
4. Disconnection
We disconnect the
experiment from the
Robotic System

)LJXUH5HPRWH3URJUDPPLQJ7HPSODWH

 7R IDFLOLWDWH LPSOHPHQWDWLRQ RI WKH
H[SHULPHQWV HYHQ PRUH DQ
³([SHULPHQWBWHPSODWH´ LV DYDLODEOH WKDW LQKHULWV
IURP WKH ³([SHULPHQW´ FODVV DQG SUHVHQWV WKH
VWUXFWXUH RI D W\SLFDO 5HPRWH 3URJUDPPLQJ
H[SHULPHQW ZKLFK LV  H[WHQGLQJ WKH
³([SHULPHQW´FODVVFUHDWLQJDQLQVWDQFHRIWKH
H[SHULPHQWFDOOLQJWKH³JHW6FHQH0DQDJHU6HU´
WRREWDLQWKHVHULDOL]HGREMHFWVIURPWKH7HOH/DE
 H[HFXWLQJ WKH FRUUHVSRQGLQJ DFWLRQV RQ WKH
7HOH/DE DQG  FORVLQJ WKH FRQQHFWLRQ VHH
)LJXUH
7KHUHPRWHH[SHULPHQWVWKDWZHKDYHWHVWHG
DUHWKHIROORZLQJ
([SHULPHQW5HPRWH9LVXDOVHUYRLQJXVLQJ
RQH IL[HG WRS FDPHUD 7KH FOLHQW VLGH XVHU¶V
SURJUDPGRHVWKHIHDWXUHH[WUDFWLRQDQGWKHSRVH
GHWHUPLQDWLRQ ,WPHDQV REYLRXVO\WKDWWKH7HOH
/DERUDWRU\ JLYHVWKHDFWXDOFDPHUDLPDJHWRWKH
XVHU DQG LW LV WKH H[SHULPHQW WKDW SHUIRUPV WKH
FRPSXWHUYLVLRQDQGWKHFRQWURO/DZ

)LJXUH&OLHQWVLGHDQDO\VH
 ([SHULPHQW5HPRWH9LVXDOVHUYRLQJXVLQJ
RQHIL[HGWRSFDPHUD,QWKLVFDVHLWLVWKHVHUYHU
VLGH 7HOH/DE WKDW SURYLGHV WKH XVHU ZLWK WKH
IHDWXUH H[WUDFWLRQ DQG WKH SRVH GHWHUPLQDWLRQ
7KLV VHFRQG H[SHULPHQW LV RULHQWHG WR WKH
H[SHULPHQWDWLRQ RI VLPSOH YLVXDO VHUYRLQJ
WHFKQLTXHV ZLWKLQ DQ LQWURGXFWRU\ SURJUDP RI
5RERWLFV DW WKH 8QLYHUVLW\ 7KH VWXGHQW RU
VFLHQWLVW RQO\ KDV WR UHVROYH WKH &RQWURO /DZ
IXQFWLRQ

)LJXUH6HUYHUVLGHDQDO\VHV
%RWK H[SHULPHQWV SHUIRUP WKH VDPH JOREDO
WDVN EXW WKH GLIIHUHQFH EHWZHHQ WKHVH
H[SHULPHQWV OLHV LQ ZKLFK VLGH WKH FOLHQW
H[SHULPHQW DW WKH XVHU SODFH RU WKH VHUYHU
7HOH/DE GRHV WKH IHDWXUH H[WUDFWLRQ DQG WKH
SRVHGHWHUPLQDWLRQ
 ([SHULPHQWDOUHVXOWV
)RU ERWK H[SHULPHQWV WKH URERW LV LQLWLDOO\ LQ D
IL[HGSRVLWLRQVKRZQLQ)LJXUHV$DQG%IRU
WKH 7HOH/DE XVHU¶V ,QWHUIDFH DQG LQ WKH URERWLF
VFHQDULRUHVSHFWLYHO\

480 Tecnologías Grid, Clusters y Plataformas Distribuidas
³0RYH WR 3RVLWLRQ
;<=´
&DPHUD,PDJH
%LQDUL]DWLRQ
6HJPHQWDWLRQ
,0$*( 352&(66,1*
326( '(7(50,1$7,21
&RQWURO/DZ


H

)LJXUH([SHULPHQWDOJRULWKP

)LJXUH$,QLWLDOSRVLWLRQRIWKH5RERWDVVKRZQE\WKH
7HOH/DEXVHU¶V,QWHUIDFH


)LJXUH%,QLWLDOSRVLWLRQRIWKH5RERWDWWKHURERWLF
VFHQDULR
 7KHREMHFWLYHRIWKHH[SHULPHQWLVWRPRYHWKH
UHGODEHORQWRSRIWKHERWWRPWRWKHWRSRIWKH
REMHFWSRVLWLRQDVVKRZQLQ)LJXUHV$DQG
%
 ,Q WKH IROORZLQJ ZH DQDO\]H WKH WLPH GHOD\V
GXH WR WKH FRPPXQLFDWLRQ WKURXJK D JHQHUDO
SXUSRVHQHWZRUN :H WKHQHYDOXDWHWKHWHPSRUDO
FRVWRIHDFKRQHRIWKHVWDJHVLQWKH([SHULPHQWV


)LJXUH$)LQDOSRVLWLRQRIWKH5RERWDVVKRZQE\
WKH7HOH/DEXVHU¶V,QWHUIDFH

)LJXUH%)LQDOSRVLWLRQRIWKH5RERWDWWKHURERWLF
VFHQDULR
(IIHFWRILQWHUQHW
*LYHQ WKDW LQ RXU V\VWHP FOLHQW DQG VHUYHU
FRPPXQLFDWH WKURXJK WKH ,QWHUQHW XVLQJ WKH
73&,3SURWRFROVXLWHZHFRQGXFWHGH[SHULPHQWV
WR DQDO\]H WKH GHOD\ GXH WR WKH QHWZRUN DQG LWV
SRVVLEOH HIIHFW LQ WKH UHPRWH YLVXDO VHUYRLQJ
DOJRULWKPDQGLQ WKHURERWFRQWURO,QSDUWLFXODU
ZHSHUIRUPHGUHPRWHPRYHPHQWVRIWKHURERW
LQ WZR GLIIHUHQW HQYLURQPHQWV ZLWK FOLHQW DQG
VHUYHUSODFHGLQWKHVDPHODERUDWRU\ZHREWDLQHG
DQDYHUDJHGHOD\RIDERXWPVHFRQWKHRWKHU
KDQGZKHQFOLHQWDQGVHUYHUZKHUHSRVLWLRQHGLQ
ZHOOVHSDUDWH ORFDWLRQV RI WKH VDPH FLW\ WKH
DYHUDJH GHOD\ LQFUHDVHG WR  PVHF $V WKLV
ODWHQF\ LV FRQVLGHUHG WRR KLJK KHUHDIWHU ZH
SHUIRUP DOO RXU H[SHULPHQWV ZLWK WKH ILUVW
HQYLURQPHQW

([SHULPHQW
7DEOH  UHSRUWV WKH WLPH UHTXLUHG WR FRPSOHWH
([SHULPHQW7KHFROXPQVRIWKHWDEOHVKRZWKH
WLPH LQYHVWHG WR GHWHUPLQH WKH SRVLWLRQ RI WKH
XVI Jornadas de Paralelismo, JP '2005 481
JULSSHU RQ WKH FDPHUD LPDJH ODEHOHG DV SRVH
GHWHUPLQDWLRQ DQG DOVR WKH ORRS WLPH QHFHVVDU\
WR SHUIRUP D ZKROH ORRS RQ WKH YLVXDO VHUYRLQJ
FRQWURO LQFOXGLQJ GHWHUPLQDWLRQ RI SRVH 7KH
F\FOHFRPSRVHGRI SRVHGHWHUPLQDWLRQDQGURERW
PRYHPHQW LV UHSHDWHG WLOO WKH HUURU LQ ERWK
FRRUGLQDWHV;DQG<LVFRQVLGHUHGVPDOOHQRXJK

0RYHP
HQW
3RVH
'HWHUPLQDW
LRQ
(UURU
;
(UURU
<
/RRS
WLPH
    
    
    
    
    
    
    
    
    
    
7DEOH7LPHQHFHVVDU\WRFRPSOHWH([SHULPHQW

,QVXPPDU\WRFRPSOHWHWKLVH[SHULPHQWQLQH
PRYHPHQWVRIWKHURERWDUHSHUIRUPHGLQWKHODVW
VWDJHWKHURERWLVFRUUHFWO\SRVLWLRQHGVRWKHUHLV
QR PRYHPHQW 7KH DYHUDJH JUDVS WLPH LV 
PVHF ZKLOH WKH DYHUDJH ORRS WLPH LV  PVHF
)LJXUHJUDSKLFDOO\GHSLFWVWKHH[HFXWLRQWLPHV
RIWKLVH[SHULPHQW
7KH WLPHV HPSOR\HG E\ FOLHQW DQG VHUYHU LQ
HDFK SKDVH RI WKH SURFHGXUH DUH VKRZQ
UHVSHFWLYHO\LQ)LJXUHVDQGIRU([SHULPHQW

 $V VKRZQ LQ )LJXUH  IRU WKLV ILUVW
H[SHULPHQW WKH FOLHQW H[SHQGV D WRWDO RI 
PVHFZDLWLQJIRULPDJHVIURPWKHUHPRWHFDPHUD
FDPHUDLPDJHVRQHIRUHDFKORRS0RUHRYHU
WKH ,PDJH 3URFHVVLQJ VWHS FRPSRVHG RI
ELQDUL]DWLRQVHJPHQWDWLRQHWFWDNHVDERXW
PVHFWKH3RVH'HWHUPLQDWLRQDERXWPVHF
WKH &RQWURO /DZ DERXW  PVHFDQGDPDMRU
SDUWRIWKHWLPHLVVSHQWE\ZDLWLQJIRUWKHURERWWR
DFFRPSOLVKWKHUHTXLUHGPRYHPHQW

Experiment 1
0
1000
2000
3000
1 2 3 4 5 6 7 8 9
M o v e me n t s
PoseDeter mination Looptime

)LJXUH([SHULPHQWJUDSK

Experiment Times
0
2000
4000
6000
8000
10000
12000
14000
16000
Camara
(Netw ork)
Image
Processing
Pose
Determination
Control Law Waiting Move
Process
Milliseconds

)LJXUH7LPHHPSOR\HGE\WKHFOLHQWIRU([SHULPHQW

Server times
0
2000
4000
6000
8000
10000
12000
14000
16000
Image Transfer Waiting Experiment Move Robot
Process
Milliseconds

)LJXUH7LPHHPSOR\HGE\WKHVHUYHUIRU
([SHULPHQW
 2Q WKH VHUYHU VLGH WKH ILVW VWHS FRQVLVWV RI
VHQGLQJWKHDFWXDOFDPHUDLPDJHWRWKHFOLHQW7KLV
LVIROORZHGE\DQLGOHWLPHZDLWLQJIRUWKHFOLHQW
WR FDOFXODWH WKH QH[W SRVLWLRQ IRU WKH URERW DQG
WKHQPRYLQJWKHURERWWRWKHUHTXLUHGSRVLWLRQ
 $ ZD\ WR LPSURYH WKLV H[SHULPHQW ZRXOG
DGGUHVV WKH HOLPLQDWLRQ RI WKH LGOH WLPH LQ WKH
VHUYHUVHFZDLWLQJIRUWKHFOLHQWWRSHUIRUP
WKH FRPSXWHU YLVLRQ SURFHGXUH 7KH QH[W
([SHULPHQWVKRZVDQRYHUDOOV\VWHPSHUIRUPDQFH
LPSURYHPHQWDFKLHYHGE\SHUIRUPLQJVRPHRIWKH
482 Tecnologías Grid, Clusters y Plataformas Distribuidas
&RPSXWHU 9LVLRQ DQG 3RVH 'HWHUPLQDWLRQ
DOJRULWKPVLQWKHVHUYHUVLGH
([SHULPHQW
7DEOH  VKRZV WKH WLPH HPSOR\HG WR FRPSOHWH
([SHULPHQW  ,Q WKLV FDVH  PRYHPHQWV DUH
UHTXLUHG WKH DYHUDJH JUDVS WLPH LVPVHFV
$QGWKHDYHUDJHORRSWLPHLVPVHFV

0RYHP
HQW
3RVH
'HWHUPLQDW
LRQ
(UURU
;
(UURU
<
/RRS
WLPH
    
    
    
    
    
    
    
    
    
    
    
    
7DEOH7LPHQHFHVVDU\WRFRPSOHWH([SHULPHQW

 'HWDLOHGDQDO\VHVRIWKHWLPHVHPSOR\HGERWK
DW WKH FOLHQW DQG VHUYHUDUH LOOXVWUDWHGLQ)LJXUHV
DQG7KHVHUHVXOWVVKRZWKDWDSRVVLELOLW\WR
LPSURYH WKH RYHUDOO V\VWHP SHUIRUPDQFH E\
DFFHOHUDWLQJ WKH ,PDJH 3URFHVVLQJ DQG 3RVH
'HWHUPLQDWLRQ IXQFWLRQV DSSO\LQJ SDUDOOHOL]DWLRQ
VWUDWHJLHV

Exp eriment 2
0
1000
2000
3000
1 2 3 4 5 6 7 8 9 10 11
M o v e me n t s
PoseDeter mination Looptime
)LJXUH([SHULPHQWJUDSK

Experiment Times
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
Get Pose (Network) Control Law Waiting Move
Process
Milliseconds

)LJXUH7LPHHPSOR\HGE\WKHFOLHQWIRU([SHULPHQW

Server Times
0
2000
4000
6000
8000
10000
12000
14000
16000
Camara
(Netw ork)
Image
Processing
Pose
Determination
Waiting
Experiment
Robot Move
Process
Milliseconds

)LJXUH7LPHHPSOR\HGE\WKHVHUYHUIRU
([SHULPHQW

 3DUDOOHOL]DWLRQRIWKHLPDJHSURFHVVLQJ
2QFHDQLPDJHLVFDSWXUHGIURPWKHFDPHUDLWKDV
WREHDQDO\]HGDQGLQWHUSUHWHGLQRUGHUWRDFTXLUH
DPDWKHPDWLFDOUHSUHVHQWDWLRQRIWKHREMHFWVLQWKH
VFHQH ZKLFK FRQFOXGHV ZLWK WKH VXFFHVVIXO
UHFRJQLWLRQ RI WKH REMHFWV 7KLV SURFHVV FDQ EH
GLYLGHG LQWR WKUHH VHSDUDWH WDVNV ELQDUL]DWLRQ
VHJPHQWDWLRQ DQG IHDWXUH H[WUDFWLRQ :H QH[W
GHVFULEH HDFK RQH RI WKHVH VWDJHV EULHIO\ DQG
DQDO\]HWKHLUSRVVLEOHSDUDOOHOL]DWLRQ:HWDUJHWD
JHQHULF SDUDOOHO V\VWHP FRPSRVHG RI PXOWLSOH
SURFHVVHV,QRUGHUWRNHHSWKHV\VWHPDVJHQHUDO
DVSRVVLEOHQRDVVXPSWLRQLVPDGHRIWKHQXPEHU
RI SURFHVVRUV LQ WKH V\VWHP RU LWV DUFKLWHFWXUH
GLVWULEXWHGRUVKDUHGPHPRU\K\EULGHWF
 7KH ELQDUL]DWLRQ VWDJH UHFHLYHV D JUD\ VFDOH
LPDJHDVLQSXWDQGGHOLYHUVDELQDU\RQH,QRXU
V\VWHPWKHSL[HOVLQWKHUHVXOWLQJLPDJHDUHEODFN
ZKHQ FRUUHVSRQGLQJ WR DQ REMHFW DQG ZKLWH
RWKHUZLVH $ UHODWHG SUREOHP LV WKDW RI
GHWHUPLQLQJ D WKUHVKROG YDOXH ZKLFK FDQ EH
DFFXUDWHO\ XVHG WR GHWHUPLQH ZKHWKHU D SL[HO
EHORQJVWRDQREMHFWRUQRW7KHSDUDOOHOL]DWLRQRI
WKLVVWDJHLVTXLWHVWUDLJKWIRUZDUG7KHLPDJHFDQ
XVI Jornadas de Paralelismo, JP '2005 483
EHSDUWLWLRQHGLQWRDVPDQ\SLHFHVDVSURFHVVHVLQ
WKHSDUDOOHOV\VWHPDQGHDFKSURFHVVFDQSURFHHG
LQGHSHQGHQWO\
 'XULQJ WKH VHJPHQWDWLRQ REMHFWV DQG WKHLU
FRQWRXUV DUH LGHQWLILHG LQ WKH ELQDU\ LPDJH ,Q
RUGHU WR GR VR WKH LPDJH LV VFDQQHG DQG D
GLIIHUHQWODEHOLVDVVLJQHGWRHDFKSL[HOEHORQJLQJ
WR WKH VDPH REMHFW 'LIIHUHQW REMHFWV DUH HDVLO\
LGHQWLILHG EHFDXVH WKHUH KDV WR EH D FOHDU
VHSDUDWLRQ EHWZHHQ WKHP DQG WKH\ DUH SURFHVVHG
VHULDOO\ 7KH VHTXHQWLDO FKDUDFWHU RI WKLV VWDJH
SRVHV D GLIILFXOW SUREOHP IRU WKH SDUDOOHOL]DWLRQ
+HUH ZH SURSRVH WR SURFHHG DV IROORZV (DFK
SURFHVV ZLOO VWDUW DW D GLIIHUHQW SRVLWLRQ RI WKH
LPDJHDQGV\VWHPDWLFDOO\VHDUFKIRUDQREMHFWWKDW
LV QRW \HW SURFHVVHG E\ WKH VHJPHQWDWLRQ :KHQ
GHDOLQJZLWKDQREMHFWDSURFHVVODEHOVLWVSL[HOV
ZLWKDXQLTXHLGHQWLILHUDQGDOVRNHHSVDUHFRUGRI
WKHSL[HOVEHORQJLQJWRWKHREMHFW,IWZRRUPRUH
SURFHVVHV µFROOLGH¶ ODEHOLQJ WKH VDPH REMHFW WKH
UHFRUGLVHPSOR\HGWRVROYHWKLV7KHVWDJHHQGV
ZKHQDQ\RQHRIWKHSURFHVVHVFRPSOHWHVWKHVFDQ
RIWKHFRPSOHWHLPDJH
 ,Q WKH ODVW VWDJH WKH RXWSXW RI WKH
VHJPHQWDWLRQ SURFHGXUH LV UHSURFHVVHG WR H[WUDFW
VRPH LPSRUWDQW REMHFW FKDUDFWHULVWLFV 7KLV
RSHUDWLRQ LV SHUIRUPHG RQ GDWD VWUXFWXUHV
UHSUHVHQWLQJWKHREMHFWVLQVWHDGRIWKHLPDJH7KH
SDUDOOHOVWUDWHJ\SURSRVHGKHUHLVWRXVHDVHSDUDWH
SURFHVVSHUREMHFW

 &RQFOXVLRQV
7KH JUDVS FRRUGLQDWH DFTXLVLWLRQ LV VORZHU LQ
([SHULPHQWWKDQ([SHULPHQWGXHWRWKHIDFW
WKDWZHDUHFRPPXQLFDWLQJWKURXJKWKH,QWHUQHWD
ZKROHLPDJHLQVWHDGRIMXVWWKHFDPHUDSRVLWLRQ
7KHGLIIHUHQFHLVDERXWPVHFVZKLFKHQDEOHV
YLVXDO VHUYRLQJ FRQWURO XVLQJ 5HPRWH
3URJUDPPLQJ LQ WKH VHFRQG FRQILJXUDWLRQ DQG
LGHQWLILHVDPDMRUERWWOHQHFNLQWKHQHWZRUN)URP
WKLVH[SHULHQFHZHFDQFRQFOXGHWKDWZHFDQXVH
UHPRWHSURJUDPPLQJRYHUWKH,QWHUQHWLQRUGHUWR
DFFRPSOLVK VLPSOH YLVXDO VHUYRLQJ H[SHULPHQWV
VR WKDW VWXGHQWV FDQ ODXQFK RUGHUV RYHU D UHDO
V\VWHP LQVWHDG RI HPSOR\LQJ WUDGLWLRQDO
VLPXODWLRQ WRROV 6RPH RWKHU UHVHDUFKHUV RI RXU
JURXSDUHDOVRLQWHUHVWHGLQXVLQJVXFKDWRRO
 )XWXUH:RUN
)XWXUHZRUNZLOOSXUVXHWKHGHYHORSPHQWRIPRUH
VRSKLVWLFDWHGYLVXDOVHUYRLQJORRSVXVLQJH[WHUQDO
FDPHUDVSDQWLOWDQGDOVRVWHUHRFDPHUDV,QGHHG
WKH VWHUHR FDPHUDV FRQWURO LQWURGXFHV DQ
LQWHUHVWLQJ GLIILFXOW\ UHODWHG WR WKHLU
V\QFKURQL]DWLRQ GXULQJ WKH ORRS ZKLFK
LQWURGXFHV WKH QHHG WR LPSOHPHQW 5HDO 7LPH
6WUHDPLQJ3URWRFROEDVHGFDPHUDPRQLWRULQJ$Q
LPSOHPHQWDWLRQ RI WKH SDUDOOHOL]DWLRQ DSSURDFK
SURSRVHGKHUHLVGXHDVZHOO
$FNQRZOHGJHPHQWV
7KLV ZRUN KDV SDUWLDOO\ EHHQ IXQGHG E\ WKH
6SDQLVK &,&<7 0LQLVWU\ RI 6FLHQFH DQG
7HFKQRORJ\ XQGHU *UDQWV 7,&
'3, 76,& E\ WKH
)XQGDFLy &DL[D &DVWHOOy XQGHU *UDQWV 3
% 3% DQG 3$
DQG E\ WKH *HQHUDOLWDW 9DOHQFLDQD XQGHU JUDQW
*9$

5HIHUHQFHV
>@ 5 0DUtQ 3- 6DQ] $3 GHO 3RELO ³7KH 8-,
2QOLQH 5RERW $Q (GXFDWLRQ DQG 7UDLQLQJ ([SHULHQFH³
$XWRQRPRXV5RERWVYRO1XPEHU
>@ 5 0DUtQ DQG 3 6DQ] ³*UDVSLQJ 'HWHUPLQDWLRQ
([SHULPHQWVZLWKLQWKH8-, 5RERWLFV7HOHODE´-RXUQDORI
5RERWLF 6\VWHPV ,QWHUQHW DQG 2QOLQH 5RERWV IRU
7HOHPDQLSXODWLRQ6SHFLDO,VVXH3DUWYRO1XPEHU

>@ *UHJ+DJHUDQG6HWK+XWFKLQVRQ³6SHFLDOLVVXHRQ
9LVXDO 6HUYRLQJ´ ,((( 7UDQV 5RERWLFV DQG $XWRPDWLRQ
9RO
>@ ' .UDJLF ³9LVXDO 6HUYRLQJ IRU 0DQLSXODWLRQ
5REXVWQHVV DQG ,QWHJUDWLRQ ,VVXHV´ 3K' WKHVLV &9$3
1$'$.7+6WRFNKROP6ZHGHQ
>@ % . .LP HW DO ³:HE 6HUYLFHV %DVHG 5RERW
&RQWURO3ODWIRUPIRU8ELTXLWRXV)XQFWLRQV´,Q3URFRIWKH
,((( ,QW &RQI 2Q 5RERWLFV DQG $XWRPDWLRQ ,&5$
%DUFHORQD6SDLQ$SULO
>@ '/HHDQG0:6SRQJ³%LODWHUDO7HOHRSHUDWLRQ
RI 0XOWLSOH &RRSHUDWLYH 5RERWV RYHU 'HOD\HG
&RPPXQLFDWLRQ 1HWZRUNV 7KHRU\´ ,Q 3URF RI WKH ,(((
,QW&RQI2Q5RERWLFVDQG$XWRPDWLRQ,&5$%DUFHORQD
6SDLQ$SULO
>@ *70F.HH³7KH'HYHORSPHQWRI,QWHUQHW%DVHG
/DERUDWRU\ (QYLURQPHQWV )RU 7HDFKLQJ 5RERWLFV DQG
$ULWLILFLDO,QWHOLJHQFH´,Q3URFRIWKH,(((,QW&RQI2Q
5RERWLFVDQG$XWRPDWLRQ,&5$:DVKLQJWRQ0D\
484 Tecnologías Grid, Clusters y Plataformas Distribuidas
Algoritmos y Técnicas de
Programación Paralela
488 Algoritmos y Técnicas de Programación Paralela
XVI Jornadas de Paralelismo, JP '2005 489
490 Algoritmos y Técnicas de Programación Paralela
XVI Jornadas de Paralelismo, JP '2005 491
492 Algoritmos y Técnicas de Programación Paralela
XVI Jornadas de Paralelismo, JP '2005 493
494 Algoritmos y Técnicas de Programación Paralela
An Approach to Structured Parallel Programming Based on a
Composition of Parallel Objects
Mario Rossainz López
Benemérita Universidad
Autónoma de Puebla, Avenida
San Claudio y 14 Sur,
San Manuel, Puebla, State of
Puebla, 72000, México
mariorl@siu.buap.mx
Manuel I. Capel Tuñón
Departamento de Lenguajes y
Sistemas Informáticos, ETS
Ingeniería Informática,
Universidad de Granada,
Periodista Daniel Saucedo
Aranda s/n,
18071 Granada, Spain
mcapel@ugr.es
Abstract
This article presents a programming methodology
based on High Level Parallel Compositions or
CPAN (according to its Spanish acronym) within
a methodological infrastructure made up of an
environment of Parallel Objects, an approach to
Structured Parallel Programming and the Object-
Orientation paradigm. By means of the method
application, the parallelization of commonly used
communication patterns among processes is
presented, which is initially constituted by the
CPANs Farm, Pipe and TreeDV that represent,
respectively, the patterns of communication Farm,
Pipeline and Binary Tree, the latter one used
within a parallel version of the design technique
known as Divide and Conquer. As the
programming environment used to derive the
proposed CPANs, we use C++ and the POSIX
standard for thread programming.
1. Introduction
At the moment the construction of concurrent and
parallel systems has less conditioning than one
decade ago, since there currently exist, within the
realms of HPC or Grid computing, high
performance parallel computation systems that are
becoming more and more affordable, being
therefore possible to obtain a great efficiency
today in parallel computing without having to
invest a huge amount of money in purchasing a
state-of-the-art multiprocessor. Nevertheless, to
obtain efficiency in parallel programs is not only a
problem of acquiring processor speed; on the
contrary, it is rather about how to program
efficient interaction/communication patterns
among the processes [2], [4,11], which will allow
us to achieve the maximum possible speed-up of a
given parallel application. These patterns are
aimed at encapsulating parallel code within
programs, so that an inexperienced parallel
applications programmer can produce efficient
code by only programming the sequential parts of
the applications [2, 3, 5]. Parallel Programming
based on the use of communication patterns is
known as Structured Parallel Programming (SPP)
[9, 10]. The widespread adoption of SPP methods
by programmers and system analysts currently
presents a series of open problems, which
motivate us to carry out research in this area; we
are particularly interested on those that have to do
with parallel applications that use predetermined
communication patterns among their processes. In
regarding an improvement of the use of SPP
methods, several open problems have currently
been identified. It is worth mentioning, among the
most important, the following ones:
x the lack of acceptance of structured parallel
environments applicable to developing a
wider range of software applications;
x determination of a complete set of
communication patterns as well as their
concrete semantics;
x the necessity to make available predefined
communication patterns or high level parallel
compositions aimed to encapsulate parallel
code within programs;
x adoption of a sound (i.e. without anomalies)
programming approach merging concurrent
primitives and Object-Oriented (O-O)
features, thereby fulfilling the requirements of
uniformity, genericity and reusability of
software components [9].
The present investigation centers its attention in
the Methods of Structured Parallel Programming,
proposing a new implementation (carried out with
C++ and the POSIX Threads Library) of a library
of High Level Parallel Compositions or CPANs
[9,10] classes, which provide the programmer
with the communication patterns more commonly
used in Parallel Programming. At the moment, the
library includes the following ones: Farm,
Pipeline and Binary Tree, the latter one being used
in a parallel version of Divide and Conquer
algorithmic design technique.
2. Exposition of the problem being
tackled
In order to cope with the above described items,
we have found that an O-O Parallel Programming
environment providing the features listed below
must be used,
x capacity of object method invocation that
assumes asynchronous message passing and
asynchronous futures;
x the objects should have internal parallelism;
x availability of different communication
mechanisms when service of petitions from
client processes take place in parallel;
x distribution transparency of processes within
parallel applications;
x Programmability, portability and performance,
as a consequence of software development
within an O-O programming system.
2.1. Scientific objectives aimed at in this
research
The current investigation has mostly been carried
out within the PhD thesis research work
referenced in [13], whose achieved operational
objectives are listed below:
1. To develop a programming method based on
High Level Parallel Compositions or CPANs.
2. To develop a library of classes of parallel
objects that provides the programmer or the
analyst with a set of commonly used
communication patterns for parallel
programming; the objects should be uniformly
programmed as reusable, generic, CPANs.
To offer this library to the programmer, so that
he/she can exploit it by defining new patterns,
adapted to the communication structure of
processes in his/her parallel applications, by
following an O-O programming paradigm, which
includes class inheritance and object generic
instantiation as its main reusability mechanisms.
3. High Level Parallel Compositions or
CPANs
The basic idea of the programming method
consists in the implementation of any type of
communication patterns between parallel
processes of an application or distributed/parallel
algorithm as classes, following the O-O paradigm.
Starting from these classes, an object can be
instantiated and its methods can be invoked, and
then be executed, on a client-server basis, thereby
hiding parallelism or communication protocols to
the application processes. A CPAN is made up of
the composition of a set of objects of three types,
see Figure 1.
An object manager that represents the CPAN
itself, making of it an encapsulated abstraction
that hides its internal structure. The manager
controls the references of a set of objects (a
denominated Collector object and several
denominated Stage objects) that represent the
components of the CPAN and whose execution is
carried out in parallel and should be coordinated
by the manager itself.
Figure 1. Internal Structure of a CPAN.
The stage objects are objects of specific purpose
responsible for encapsulating a client-server type
interface between the manager and the object
slaves (objects that are not actively participative in
the composition of the CPAN, but rather, are
considered external entities that contain the
Collect
Stage
Manager
Slav
e
Stage
Stage
Stage
Slav
e
Slav
e
Slav
e
496 Algoritmos y Técnicas de Programación Paralela
sequential algorithm constituting the solution of a
given problem) as well as providing the necessary
connection among them to implement the
communication pattern semantics, whose
definition is being sought. In other words, each
stage should act in parallel as a node of the graph
that represents the communication pattern and
should be capable of executing its methods as an
active object. A stage can be directly connected to
the manager and/or to another component stage
depending on the particular pattern of the CPAN.
And an object collector which is an object in
charge of storing in parallel the results that it
receives from the stage objects connected to it,
i.e., during the service of a petition. The control
flow within the stages of a CPAN depends on the
communication pattern implemented between
these. When the CPAN concludes its execution,
the result does not return to the manager directly,
but rather to an instance of the class Collector,
which takes charge of storing these results and of
sending them to the manager, which then sends
them to the exterior as they arrive, i.e., without
being necessary to wait for all the results to be
obtained at the end of the computation.
3.1. Types of communication between the
parallel objects
1. The synchronous way stops the client’s activity
until the object’s active server gives back the
answer to the petition.
2. The asynchronous way does not force any
waiting in the client’s activity; the client
simply sends its petition to the active server
and then it continues.
3. The asynchronous future way makes only to
wait the client’s activity when the result of the
invoked method is needed to evaluate an
expression during its code execution.
3.2. Basic classes of a CPAN
The abstract class ComponentManager defines
the generic structure of the component manager of
a CPAN, from which all the concrete manager
classes are derived, depending on the parallel
behaviour which is needed to create a specific
CPAN.
The abstract class ComponentStage defines the
generic structure of the component stage of a
CPAN as well as its interconnections, so that all
the concrete stages needed to provide a CPAN
with a given parallel behaviour can be obtained by
class instantiation.
The concrete class ComponentCollector defines
the concrete structure of the component collector
of any CPAN. It implements a multi-item buffer,
which permits the storage of the results from
stages that make reference to this collector.
3.3. The synchronization restrictions MaxPar,
Mutex and Sync
Synchronization mechanisms are needed when
several petitions of service take place in parallel in
a CPAN, being capable its constituting parallel
objects of interleaving their concurrent executions
while, and at the same time, they preserve the
consistency of the data being processed. Within
the code of any CPAN, execution constraints are
automatically included when the reserved words
MAXPAR, MUTEX and SYNC of the library are
found. The latter ones must be used to obtain a
correct programming of object methods and to
guarantee data consistency in applications.
4. The CPANs Farm, Pipe and TreeDV
The parallel patterns worked until now have been
the pipeline, the farm and the TreeDVD, since
they constitute a significant set of reusable
communication patterns in multiple parallel
applications and algorithms.
1. The pipeline is made up of a set of
interconnected stages, one after another. The
information flows between stages until an
ending condition is determined in one of the
stages. At this moment the pipeline enters in
another execution mode in which each stage
unloads its data to the next one. The last stage is
responsible for sending the processed data to
the Collector. See Figure 2(a).
2. The Farm is composed of a set of worker
processes and a controller. The workers are
executed in parallel until a common objective of
the parallel computation is reached. The
controller is the component in charge of
distributing work to slave processes and
controlling the progress of the global
calculation. See Figure 2(b).
XVI Jornadas de Paralelismo, JP '2005 497
Figure 2(a). The Cpan of a Pipeline
3. The TreeDV is a communication pattern in
which the information flows from the root to
the leaves of the tree and vice versa. The nodes
on the same level are executed in parallel in
order to implement a parallel version of the so
called Divide and Conquer algorithmic design
technique. The stage situated at the root of the
TreeDV will obtain the solution of the problem
when the global calculation finishes. This
CPAN is configured in a similar way, see [13]
for details.
Figure 2(b). The Cpan of a Farm
4.1. Use of a CPAN within a parallel
application
Once implemented a selected CPANs according to
the communication structure of the parallel
processes, the way in which it must be used to
build a complete parallel application is detailed
below.
1. It is necessary to create an instance of the
adequate class manager, that is to say, a
specialized instance (this involves the use of
inheritance and generic instantiation)
implementing the required parallel behavior of
the final manager object. This is performed by
following the steps:
1.1 Instance initialization from the class manager,
including the information, given as
associations of pairs (slave_obj,
associated_method); the first element is a
reference to the slave object being controlled
by each stage and the second one is the name
of its callable method.
1.2 The internal stages are created (by using the
operation init()) and, for each one, the
association (slave_obj, associated_method)
is passed to. The second element is needed
to invoke the associated_method on the
slave object.
2. The user asks the manager to start a calculation
by invoking the execution () method of a given
CPAN. This execution is carried out as it
follows:
2.1 a collector object is created for satisfying this
petition;
2.2 input data are passed to the stages (without
any verification of types) and a reference to
the collector;
2.3 results are obtained from the object collector;
2.4 The collector returns the results to the exterior
without type verification.
3. An object manager will have been created and
initialized and some execution petitions can
then start to be dispatched in parallel.
Collector
Stage_n
Manager
Slave
Stage_n-1
Stage_n-2
Stage_1
Slave
Slave
Slave
Collector
Stage_n
Manager
Slave
Stage_n-1
Stage_n-2
Stage_1
Slave
Slave
Slave
498 Algoritmos y Técnicas de Programación Paralela
Figure 3. The Cpan Branch & Bound
Figure 4(a). Scalability of the Speedup found for the
CpanFarm in 2, 4, 8, 16 and 32 processors.
Figure 4(b). Scalability of the Speedup found for the
CpanPipe in 2, 4, 8, 16 and 32 processors.
4.2. Results obtained
Assuming that we want to sort an array of data,
some CPANs will adapt better to communication
structure of a Quicksort algorithm than others.
These different parallel implementations of the
same sequential algorithm will therefore yield
different speedups. The program is structured of
six set of classes instantiated from the CPANs in
the library High Level Parallel Compositions,
which constitute the implementation of the
parallel patterns named Farm, Pipe and TreeDV.
The sets of classes are listed below:
1. The set of the classes base, necessary to build a
given CPAN.
2. The set of the classes that define the abstract
data types needed in the sorting.
3. The set of classes that define the slave objects,
which will be generically instantiated before
being used by the CPANs.
4. The set of classes that define the Cpan Farm.
5. The set of classes that define the Cpan Pipe.
6. The set of classes that define the Cpan TreeDV.
4.3. Analysis of Speedup
The analysis of Speedup of the CPANs Farm, Pipe
and TreeDV that appears in Figures 4 and 5, was
carried out in a Parallel System Origin 2000
Silicon Graphics (of 64 processors) available in
the European Center for Parallelism of Barcelona
(CEPBA). In all the cases the implementation and
test of the CPANs Farm, Pipe and TreeDV 50000
integer numbers were randomly generated to load
each CPAN.
Collector
Manager
OE
Stage_1
Collector
Manager
CpanFarm
Stage_1 Stage_n
Collector
Manager
CpanFarm
OE
OE
Stage_1 Stage_2 Stage_n
Collector
Manager
CpanFarm
OE OE
OE
Stage 1
Stage 2
Stage n
0.00
2.00
4.00
6.00
8.00
10.00
cpuset2 cpuset4 cpuset8 cpuset16 cpuset32
Númer o de P r ocesador es
Speedup del CpanFar mQS Ley de Amdal h par a el CpanFar mQS
0.00
2.00
4.00
6.00
8.00
10.00
cpuset2 cpuset4 cpuset 8 cpuset16 cpuset32
Núme r o de P r oc e sa dor e s
Speedup del CpanPipeQS
Ley de Amdalh del CpanPipeQS
XVI Jornadas de Paralelismo, JP '2005 499
Figure 5(a). Scalability of the Speedup found for
the CpanTreeDV in 2, 4, 8, 16 and 32 processors.
Figure 5(b). Speed Up of Parallel Cpan B&B
5. Parallelization of Branch & Bound
technique
Branch-and-bound (BB) makes a partition of the
solution space of a given optimization problem.
The entire space is represented by the
corresponding BB expansion tree, whose root is
associated to the initially unsolved problem. The
children nodes at each node represent the
subspaces obtained by branching, i.e. subdividing,
the solution space represented by the parent node.
The leaves of the BB tree represent nodes that
cannot be subdivided any further, thus providing a
final value of the cost function associated to a
possible solution of the problem. Three stages are
performed during the execution of a program
based on a BB algorithm,
1. Selection: A node belonging to the set of live
nodes, i.e. those not pruned yet, is extracted.
Node selection depends on the strategy search
on the live node list, which was previously
decided for its use in the algorithm.
2. Branch: the node selected in the previous step
is subdivided in its children nodes by following
a ramification scheme to form the expansion
tree. Each child receives from its father node
enough information to enable it to search a
suboptimal solution.
3. Bound: Some of the nodes created in the
previous stage are deleted, i.e. those whose
partial cost, which is given by the cost function
associated to this BB algorithm instance, is
greater than the best minimum bound calculated
up to that point.
The ramification is generally separated from the
bounding of nodes on the expansion tree in
parallel BB implementations. Each object node of
the expansion tree must contain all the necessary
information to be an active object.
The ramification and bounding are implemented
using the CPAN Farm of the proposed library, so
that the ramification and the distribution of work
to the application processes are carried out by
using the Farm communication scheme. The
expansion tree, for a given instance of the BB
algorithm, is obtained by iteratively subdividing
the stage objects according to the farm pattern
until a stage representing a leaf-node of the
expansion tree is found, see Figure 3.
On the other hand, the pruning is implicitly
carried out within another farm construction by
using a totally connected scheme between all the
processes. The manager can therefore
communicate a sub-optimal bound found by a
process to the rest of branching processes to avoid
unnecessary ramifications of sub-problems, i.e.,
those that do not lead to improving the best upper
bound obtained up to that moment.
The Cpan Branch & Bound is composed of a set
of Cpans Farm, see Figure 3, which represent
each one a set of worker processes and one
manager, therefore, forming a new type of
structured Farm, the Farm Branch & Bound or
FarmBB, which is also included in the library of
CPANs. All the worker processes of the Farm BB
are executed in parallel, thereby forming the
expansion tree of nodes given by the BB
algorithm technique. The initial problem, or the
root of the expansion tree, is given to the manager
process of the initial Cpan Farm, which is in
charge of distributing the work and of controlling
the global calculation progress. It is also
responsible for sending results to the collector of
the Cpan FarmBB, which will display them.
0.00
5.00
10.00
cpuset 2 cpuset4 cpuset 8 cpuset 16 cpuset 32
Núme r o de P r oc e sa dor e s
Speedup del CpanTreeDVQS
Ley de Amdalh para el CpanTreeDVQS
Speed Up of Parallel Cpan B&B
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
cpuset2 cpuset4 cpuset8 cpuset 16 cpuset32
P r oc e ssor s
500 Algoritmos y Técnicas de Programación Paralela
5.1. Application to the Travelling Salesman
Problem (TSP)
The Travelling Salesman Problem could be
represented by a directed graph consisting of a set
of vertices (cities) and labelled arcs (distances
between cities). One optimized solution of the
TSP is a path in which all the vertices have been
visited exactly once with minimal cost [4].
Formally, the problem can be enunciated as
follows: given a connected and weighted graph g
and given one of its vertices v0 as the initial one,
find the Hamiltonian cycle of minimum cost that
begins and finishes in v0 [12]. The search strategy
which was used in the implementation and test of
the distributed TSP was the first best search
strategy that uses the calculation of cost functions
for each live node to select the node (strategy
HEAP, using minimum cost or LC). The graph
taken from reference [12] represents a network of
5 cities.
6. Conclusions
An programming method has been presented,
which is based on the High Level Parallel
Compositions of Corradi , but updated and
adapted to be used with C++ programming
language and POSIX standard for thread
programming. Several patterns of
communication/interaction between processes
have been implemented as generic, reusable
library of CPANs, which can even be used by
inexperienced parallel application programmers to
obtain efficient code by only programming the
sequential parts of their applications.
The CPANs Pipe, Farm and TreeDV conform a
first version of a library of classes intended to be
applied to the solution of several complex
problems, as the parallelization of the B&B
technique to offer an optimal solution of the TSP
NP-Complete problem.
Seq CPU2 CPU4 CPU8
CPU1
6
CPU
32
Run
time
35.42
Seg.
21.88
Seg.
14.21
Seg.
11.34
Seg.
10.27
Seg.
9.10
Seg.
Time
Usuary
25.80
Seg.
22.14
Seg.
20.16
Seg.
18.16
Seg.
21.67
Seg.
21.1
4
Seg.
Time
System
1.30
Seg.
1.11
Seg.
1.01
Seg.
1.03
Seg.
1.02
Seg.
1.04
Seg.
Time
CPU
27.10
Seg.
23.25
Seg.
21.17
Seg.
19.19
Seg.
22.69
Seg.
22.1
8
Seg.
Cycles
2669
4871
9
69877
161
69073
500
67663
433
66942
422
6599
2570
Instruct
ions
2021
0611
2
73380
571
73219
450
72932
731
72454
022
7223
5919
CPI
1.321 0.952 0.943 0.928 0.924
0.91
4
Speed
Up
1.00 1.62 2.49 3.12 3.45 3.89
Amdalh 1.00 1.68 2.55 3.43 4.16 4.64
Table 1. Execution of Parallel CpanB&B in 2, 4, 8, 16
and 32 processors with N=50 cities
References
[1] Birrell, Andrew. “An Introduction to
programming with threads”. Digital Equipment
Corporation, Systems Research Center, 1989.
[2] Brinch Hansen; “Model Programs for
Computational Science: A programming
methodology for multicomputers”, Concurrency:
Practice and Experience, Volume 5, Number 5,
407-423, 1993.
[3] Brinch Hansen; “SuperPascal- a publication
language for parallel scientific computing”,
Concurrency: Practice and Experience, Volume 6,
Number 5, 461-483, 1994.
[4] Capel M.I., Palma A., “A Programming tool
for Distributed Implementation of Branch-and-
Bound Algorithms”. Parallel Computing and
Transputer Applications. IOS Press/CIMNE.
Barcelona 1992.
[5] Capel, M.; Troya J. M. “An Object-Based
Tool and Methodological Approach for
Distributed Programming”. Software Concepts
and Tools, 15, pp. 177-195. 1994.
[6] Capel M., Rossainz, M. “A parallel
programming methodology based on high level
parallel compositions”. Proceedings of the 14th
International Conference on Electronics,
Communications and Computers, 2004, IEEE CS
press. 0-7695-2074-X.
[7] Cole, M. “Algorithmic Skeletons: Structured
Managment of Parallel Computation”. The MIT
Press, 1989.
[8] Corradi A., Leonardi L. “PO Constraints as
tools to synchronize active objects”. Journal
Object Oriented Programming 10, pp. 42-53.
1991.
[9] Corradi A, Leonardo L, Zambonelli F.
“Experiences toward an Object-Oriented
Approach to Structured Parallel Programming”.
XVI Jornadas de Paralelismo, JP '2005 501
DEIS technical report no. DEIS-LIA-95-007.
1995
[10] Danelutto, M.; Orlando, S; et al. “Parallel
Programming Models Based on Restricted
Computation Structure Approach”. Technical
Report-Dpt. Informatica. Universitá de Pisa.
[11] Darlington et al. “Parallel Programming
Using Skeleton Functions”. Proceedings
PARLE’93, Munich (D), 1993.
[12] GoodMan S.E., Hedetniemi S.T.
“Introduction to the Design and Analysis of
Algorithms. Mc Graw Hill Book Company.
United States of America 1977. ISBN:0-07-
023753-0.
[13] Rossainz, M. “Una Metodología de
Programación Basada en Composiciones Paralelas
de Alto Nivel (CPANs)”, Universidad de
Granada, PhD dissertation, 02/25/2005.
502 Algoritmos y Técnicas de Programación Paralela
   
       
  

  !  #  
 
' ( * ( - / * ( 2 3 ( 4 ( 6 6 ( 3 ( * : < = > @ * @ B @ D @ E : F 2 G : * 2 J 2 3 : K
L M N P R T P U M W T Y Z M \ ] T P Z ^ ] T ` a P b c d e d f g Y U N i T P a ` j W
\ d k d l d c W o M W ` M R ^ P c W q Y R U t T ` a P
v W ` x M R ] ` Z P Z Z M z P z P o i W P
\ | } ~  €  z P z P o i W P b k M W M R ` q M ƒ \ ] N P … P †
ƒ o U ` R P W Z P ‡ a ˆ M Y W † Š i ˆ ˆ d M ]
‹ Œ  Ž  Œ 
‘ ’ ” • – ” – ™ š œ š  ž • ”   ™ ” • ” ’ – š ¢ ’ ” • £ ¢ ” ¤ ” – ž   š ¦
™ š œ § • £ ¢ ” ¨ š • © ª « ‘ • – ” ” • £ ¢ ” ¤ ” – ž   ™ ž   ž ™ ° ± ž ’ š
š ¤ ¢ • ¢ š ™ ± ž ¨ ž • ” • £ ¢ ” ² š • ¨ ” ™ ” • ž ¤ ¢ ° ± ´ ’ µ ¢ ’ ž • ” ¦
° ¢ ” ’ ° ± š ¤ ¶ ž – ™ ž   š ™ š ¤ ” ¤ ž « · š ¤ ± œ ™ ” ™ ¸ š • ” ¹ š ¨ ” ¦
• š ™ ™ ž ¤ ¤ š ¨ ž ” ’ º » » ™ ” ¨ ¢ ° ± ” ’ ¨ ž ” ¤ – ™ š œ š  ž ¨ ” ¤
¢ • ¢ š ™ ± ž š ¤ š ” •   ” ° ± ¿ ° š ° ± ´ ’ ¨ ” ¤ š • ° ¤ š • ” • ¶ ² À ¦
– ž ¨ ž • ’ ” ° ” • š ™ ± ž •   š ™ š ” ¤   ™ ž œ ¤ ” ² š ° ž ’ ° ™ ” – ž £ ¢ ”
¨ ” • ” ” ™ ” • ž ¤ Á ” ™ « ‘ ¤   š – ™ ´ ’ ¨ ” ™ ” • ž ¤ ¢ ° ± ´ ’   š ™ š ¤ ” ¤ ž
  ™ ” • ” ’ – š ¨ ž ” • –  œ š • š ¨ ž ” ’ ² ” ² ž ™ ± š ° ž ²   š ™ – ± ¦
¨ š ¶ • ” ¹ š ± ²   ¤ ” ² ” ’ – š ¨ ž ¢ • š ’ ¨ ž à   ” ’ Ä Å « º ž ¦
² ž ° š • ž ¨ ” ” • – ¢ ¨ ± ž • ” ¹ š ” ¤ ” Æ ± ¨ ž ” ¤ Å ™ ž œ ¤ ” ² š
¨ ” º ž ™ – ” Ç ± ¨ ± ² ” ’ • ± ž ’ š ¤ È   š ™ š ” ¤ £ ¢ ” • ” ² ¢ ” • ¦
– ™ š ’ ¤ ž • ™ ” • ¢ ¤ – š ¨ ž • ° ž ²   ¢ – š ° ± ž ’ š ¤ ” • ž œ – ” ’ ± ¨ ž •
  š ™ š ¢ ’ ² ¢ ¤ – ±   ™ ž ° ” • š ¨ ž ™ «
Ê Ë Í
 Î Ï Ð Ñ Ž Ò Ò Ó Ô 
Õ
” ¨ ” ’ ž ² ± ’ š ™ Â Ö × Ø Ù Ö Ú Ö Û Ü Ý Ú Þ Ü ß à Û á â ã Ü š ¢ ’ ° ž ’ ¦
 ¢ ’ – ž ¨ ”   ™ ž ° ” ¨ ± ² ± ” ’ – ž • £ ¢ ” ° ž ’ • – ± – ¢ ¶ ” ’ ” ¤ š ™ ¦
² š ä ´ ’ ° ž ’ ” ¤ £ ¢ ” ¨ ” • š ™ ™ ž ¤ ¤ š ™   ™ ž Æ ™ š ² š •   š ¦
™ š ™ ” • ž ¤ Á ” ™ ¢ ’   ™ ž œ ¤ ” ² š ¨ š ¨ ž ¢ – ± ¤ ± ä š ’ ¨ ž ¢ ’ š
– À ° ’ ± ° š š ¤ Æ ž ™ ¸ – ² ± ° š   š ™ – ± ° ¢ ¤ š ™ « · ž • ” • £ ¢ ” ¤ ” – ž •
  ™ ž   ž ™ ° ± ž ’ š ’ ² ž ¨ ¢ ¤ š ™ ± ¨ š ¨ š ¤ ¨ ± • ” ç ž ¨ ” š ¤ Æ ž ¦
™ ± – ² ž • È ¤ ž £ ¢ ” • ¢   ž ’ ” ¢ ’ š Æ ™ š ’ Á ” ’ – š  š ™ ” • ¦
  ” ° – ž š ¤ š ± ²   ¤ ” ² ” ’ – š ° ± ´ ’ ¨ ± ™ ” ° – š ¨ ” ¤ š ¤ Æ ž ™ ± – ¦
² ž ¨ ” • ¨ ” ” ¤   ™ ± ’ ° ±   ± ž È ’ ž • ´ ¤ ž ” ’ – À ™ ² ± ’ ž • ¨ ”
™ ” ¢ – ± ¤ ± ä š ° ± ´ ’ ¨ ” ° ´ ¨ ± Æ ž È • ± ’ ž – š ² œ ± À ’ ” ’ ² ” – ž ¦
¨ ž ¤ ž Æ ¸ š ¶ ° ¤ š ™ ± ¨ š ¨ ¨ ” ° ž ’ ° ”   – ž • « ‘ ’ Æ ” ’ ” ™ š ¤ È ” ¤
• ž é – ê š ™ ” £ ¢ ”   ™ ž   ž ™ ° ± ž ’ š ” • £ ¢ ” ¤ ” – ž •   ™ ” • ” ’ – š
¨ ” ° ¤ š ™ š ° ± ž ’ ” • ¨ ” ° ¤ š • ” • Á š ° ¸ š • £ ¢ ” ” ¤ ¢ • ¢ š ™ ± ž
¹ š ¨ ” ™ ” ¤ ¤ ” ’ š ™   š ™ š š ¨ š   – š ™ ¤ ž š ¤ š ™ ” • ž ¤ ¢ ° ± ´ ’
¨ ” ¢ ’   ™ ž œ ¤ ” ² š ° ž ’ ° ™ ” – ž «
‘ ’ ¤ š ™ ” • ž ¤ ¢ ° ± ´ ’ ¨ ”   ™ ž œ ¤ ” ² š • ¨ ” ž   – ± ² ± ä š ¦
° ± ´ ’ ° ž ² œ ± ’ š – ž ™ ± š È ¤ š œ § • £ ¢ ” ¨ š ¨ ” ¢ ’ š • ž ¤ ¢ ¦
° ± ´ ’ ì   ž ™ ”  ” ²   ¤ ž È ² š í
± ² ± ä š ™ ž ² ± ’ ± ² ± ä š ™ ¢ ’ š
¨ ” – ” ™ ² ± ’ š ¨ š é ¢ ’ ° ± ´ ’ ž œ  ” – ± Á ž î ° ž ’ • ± • – ” ” ’ ” ’ ¦
° ž ’ – ™ š ™ ¢ ’ š – ™ š ¶ ” ° – ž ™ ± š ” ’ ” ¤ ” •   š ° ± ž ¨ ” ” • – š ¦
¨ ž • ž  ™ œ ž ¤ ¨ ” œ § • £ ¢ ” ¨ š £ ¢ ”   š ™ – š ¨ ” ¤ ’ ž ¨ ž
™ š ¸ ä ¶ ° ¢ ¤ ² ± ’ ” ” ’ ¢ ’ ’ ž ¨ ž ¹ ž  š « ñ ’ š   ž • ± œ ¤ ”
– À ° ’ ± ° š   š ™ š ” ’ ° ž ’ – ™ š ™ ¤ š ² ”  ž ™ • ž ¤ ¢ ° ± ´ ’ š ¢ ’
  ™ ž œ ¤ ” ² š È ° ž ’ • ± • – ± ™ ¸ š ” ’ ” í   ¤ ž ™ š ™ – ž ¨ ž • ¢ ” •   š ¦
° ± ž ¨ ” œ § • £ ¢ ” ¨ š È š ’ š ¤ ± ä š ’ ¨ ž – ž ¨ š • ¤ š •   ž • ± œ ¤ ” •
• ž ¤ ¢ ° ± ž ’ ” •   š ™ š È ¿ ’ š ¤ ² ” ’ – ” È • ” ¤ ” ° ° ± ž ’ š ™ ¤ š ² ” ¦
 ž ™ ¨ ” – ž ¨ š • ” ¤ ¤ š • « ‘ ¤ ± ’ ° ž ’ Á ” ’ ± ” ’ – ” ” • £ ¢ ” ” ’ ¤ š
² š ¶ ž ™ ¸ š ¨ ” ¤ ž • ° š • ž • È   š ™ š   ™ ž œ ¤ ” ² š • ¨ ” – ±   ž
° ž ²   ¤ ”  ž ž ± ’ • – š ’ ° ± š • ¨ ” ¢ ’ – š ² š ç ž ° ž ’ • ± ¨ ” ™ š ¦
œ ¤ ” È ¤ š • ¨ ± ² ” ’ • ± ž ’ ” • ¨ ” ¤  ™ œ ž ¤ ¨ ” œ § • £ ¢ ” ¨ š • ž ’
” í ° ” • ± Á š • « Å ž ™ ” • – ” ² ž – ± Á ž È • ” ” ²   ¤ ” š ’ – À ° ’ ± ° š •
£ ¢ ” ” Á ± – ” ’ – ” ’ ” ™ £ ¢ ” ” í   ¤ ž ™ š ™ – ž ¨ ž ” ¤ ” •   š ° ± ž
¨ ” œ § • £ ¢ ” ¨ š «
ñ ’ š ” í   ¤ ž ™ š ° ± ´ ’ ¹ ” ¢ ™ ¸ • – ± ° š È š ¤ ° ž ’ – ™ š ™ ± ž £ ¢ ”
¢ ’ š ” í   ¤ ž ™ š ° ± ´ ’ š ¤ Æ ž ™ ¸ – ² ± ° š È ™ ” š ¤ ± ä š ¤ š œ § • £ ¢ ” ¦
¨ š ¨ ” ’ – ™ ž ¨ ” ¤ ” •   š ° ± ž ¨ ” ” • – š ¨ ž • š ¶ ¢ ¨  ’ ¨ ž • ”
¨ ” š ¤ Æ § ’ ° ž ’ ž ° ± ² ± ” ’ – ž ” •   ” ° ¸ ¿ ° ž ž ¹ ” ¢ ™ ¸ • – ± ° ž
¨ ” ¤   ™ ž œ ¤ ” ² š « ‘ • – ” – ±   ž ¨ ” ± ’ é ž ™ ² š ° ± ´ ’ Á ± ” ¦
’ ” ¨ ” – ” ™ ² ± ’ š ¨ š   ž ™ ¢ ’ š ò Ù ó ã â ô ó õ Ö Ö ö Ý Ú Ù Ý ã â ô ó
÷
Ö Ù ß à × Û â ã Ý « · š é ¢ ’ ° ± ´ ’ ¨ ” ” Á š ¤ ¢ š ° ± ´ ’ ¹ ” ¢ ™ ¸ • – ± ° š
¨ ” ¢ ’ ¨ ” – ” ™ ² ± ’ š ¨ ž ’ ž ¨ ž ø • ” ¨ ” ’ ž ² ± ’ š ù ú û ø ü
¶   ™ ž ¨ ¢ ° ” ¢ ’ Á š ¤ ž ™ £ ¢ ” • ” ” ²   ¤ ” š   š ™ š ™ ”   ™ ” ¦
• ” ’ – š ™ ¤ ž ¨ ” • ” š œ ¤ ” ž ± ’ ¨ ” • ” š œ ¤ ” £ ¢ ” • ” ™ ¸ š ¤ š ” í ¦
  š ’ • ± ´ ’ ¨ ” ¨ ± ° ¹ ž ’ ž ¨ ž « · š œ § • £ ¢ ” ¨ š © ª   ” ™ – ” ¦
’ ” ° ” š ” • – ” – ±   ž ¨ ” ” • – ™ š – ” Æ ± š • ¶ È ” ’ ° ž ’ ° ™ ” – ž È
¹ š ° ” ¢ • ž ¨ ” ¢ ’ š ò Ù ó ã â ô ó õ Ö ã Ü × Û Ö Û Ü Û Ý Ú Ö × Û â á Ý ý
õ Ü þ
ú
û ø ü   š ™ š ° š ¨ š ’ ž ¨ ž ø « ‘ • – š é ¢ ’ ° ± ´ ’ Á ± ” ’ ”
¨ š ¨ š   ž ™ µ
þ ú û ø ü ÿ û ø ü  ù ú û ø ü
¨ ž ’ ¨ ” È û ø ü ™ ”   ™ ” • ” ’ – š ” ¤ ° ž • – ” š ° ¢ ² ¢ ¤ š ¨ ž ¨ ” • ¦
                 ! " $  &  )  +
          1 2  4 1 5    4          
        ; <   1 > @ 4              1 2  +
C D E   4   ) ;   2        I  1  
L N  4 1 5    >   N  4 1 5    2 )    D
 )   1   +
   1 )  L N  4 1 5   I  1  T     4    V
 N     N 4 1 5  5 )  1 2        Y  V     
  ) N Z     ;   \ )   2 V  2     +
 D
_        ;  <   )       N    b N       +
Y   2 1 4 )           Y 1  c d D e  1 2 )   2   +
  4 1 5         1     h
i i
T ) ) 4 1   
  N  N  1   1 )   )          N 4 1 5  k
N    4 N   4 1     )      ;      2  +
2 1  4 2 )   1  D
l
   N  1  1   o )   p E   
)              b N  2  )      T b N 
4    1  N      )   4 1 5  ) 1  4 1 )         +
  4 N  D _    b N         ) ;  4  ) ;   +
2     1 )  4  Z 2 1 4  4  ) ;   2   2 V 
4 2 )   <     D  b N    )            N    
4 2 ) N   4 1      ;    1  )     E ;   2 
 h   s 1 1 2    1    D _       4     1 +
     N 4  N      1 Y N 1     L 2  k _   
  4 4 1 5    )         1    L    N  N  1   
L N  4 1   2 1        b N  2    4 N   4 1      
; u  b N    c d D _      4 4 1 5       4 1 ;   
          b N     )      D _      4 4 1 5  
  )            N     4 2 ) N   4 1      D
 1    2     T        4  4  N  1       2   +
4 1                ;  < L N  N   D
 y 
z  { |  | ~  z | € { |  € ‚  
_  N    b N     T     4    1 b N    N  N  1
 I   N     1   4       1 2 )   2     N 
4  < N    2 Z   D _      4   T    4     
 b N  1     k   " $ % ' @   2  4       4   4 +
     1 4     ) ;   2      >  C T ) $ + , . /
@  I   4 5 2    )       V       N 4 1    C
 ) + "   " $ % ' @  )       N     V ; 
  )  4 1  ; u  b N   C D _  N  N  1   2 ; 1 Z 
) N   2 1 I 4     2 1     4   4      1 4  
   ; u  b N       1   2  1     N   4    
 4  I Y N  4 1 5     D
e  4     ) + "   " $ % '     b N   I    
; u  b N   )   N  ) ;   2  )   1 4 N     +
;  4      N  4  2 )    1 ) ) $ + , . /  
  b N    >      2  4         N 4 1 5  @ )  +
4 1   C D e  2 Z   b N         I  1
  k . / . , ) + "   " $ % ' 5 7 " ' 8 : + " 7 " ' : < 1  1 4
1   1 +
    >    N ; ) ;   2  >   )   1   )   1
  ) ;   2  1 Y 1    D $ @ %  A " + / B 5 7 " ' < 4   +
4 N     4     4 N 2 N   F $  &    N ; ) ;   2  D
+ 7 7 %  A " + / B 5 7 " ' 8 : $ < 4   4 N     4       
   1 2  ‰ " $  &    N ; ) ;   2  D "  H / I J 5 7 " ' 8
: + " 7 " ' : < Y     N  4  < N     N  >   N ; +
) ;   2    )   1    N ; ) ;   2   4  N   D
"  H / I J 5 7 " ' 8 : 7 8 : + " 7 " ' : < Y     N  4  +
< N     N  >   N ; ) ;   2   ;    1     +
> Z     4 2 ; 1   4 1 5     N ; ) ;   2   4  N  
4    N ; ) ;   2   D . N O H $ . B 5 7 " ' <  +
  2 1    1 N   N ; ) ;   2    1     \ )  4 +
   1 >    Z \ 1  D
l
  2 )          b N  2  )  +
    )     4     N ; ) ;   2   b N     
   N 4 1 5    4 N   4 1        ;    Y     D
: . ' . $ H  Q 5 : 7 <  4 1   1   N ; ) ;   2    +
    1 2 1      D
l
  2 )    )     \ +
)       4    b N           \ )  +
 N   1 2 1    2  < D " % , , %  Q J H / 5 : 7 <  +
4 1  4 N V     N ; ) ;   2       2  < D
E  2 1      4     )     N ; ) ;   2  
 1 2 1     D
_     1 Y N  U   2 N       4 5 1 Y b N  1 2 +
)   2     N   s u  b N   c d   4 N   4 1   D _   
  b N     T )    N L N  4 1   2 1    T   4  N 
   1             k 7 % /  " % : , D _   
) 1 2         T     2  4      4  < N   
 N ; ) ;   2   Y       b N     V  )   1   +
        1   D
l
1   ) ;   2     2  \ 1 2 1 +
  4 1 5    1          N ; ) ;   2    2  
 2     L N  4 1 5    N 4           1 2 
@ + 7 7 %  A " + / B C   1    2 1  1 2 1   4 1 5    1  +
      2    2   D _     1    " % : ,  
>   1          N ; ) ;   2         1   +
 D
 )   1         )  4 1 I 4  4 1       1 +
    )   N  N  1 T      1       >  V   4  +
       V  1  1    N ; ) ;   2    1 2 1   +
  D
l
1       )  4 1 I 4  b N         N 
) ;   2  4  Y      b N  1 2 1      2  +
2 1  T    1     2  <          1 )
Y Z Y
A [ \ ] ^ T )   )  2 1  1 N   Y    1 5   I 4   
  2 1  2  D
e  ; u  b N   : % H  I J . / ` 5 <     1 Y N  U
   1   N    2 1 I 4  4 1 5   1 2 )     N ; ) +
;   2   T  2 )       2 Z  "  H / I J 5 7 " ' 8
: + " 7 " ' : < )    N Y     4 1 5  D _  ) 4      
 1 Y N 1     k c  1 4 1   2     T    \      ) 1 2   +
    1      ; 1    @       C D _    ) 1 +
504 Algoritmos y Técnicas de Programación Paralela
   
    
            ! #
$ % % %
& '      )  *  % , * - .  ! ! 0 0  ) 2       ! ! #
3    5  *  %  ,    ! 9 ; ; < = -   ,       ?   -  ? A *   A  ,        C  
D
  , * ? -  E    F F 9
H  2     %   '  ) 5    % ? * *  ! # ; ;
  K           -          ?   M 
N ; ; O  , *   A              !  ?  K       .       C   
R ; ;     K   ? A *   A  ,    ,     . , S    ?    - ?  
U  2  A  - %     -     ! ! 5 5 -  ? ! #
V ; ; W      M       ?     ? A *   A  ,  
   %  * % A       -    X Y * A , Z  ? A * A ,  ! 9
$ 2    ?        5 V 9  ]  ? A * A ,  %   C  ! 9  F F ! #
&   '  5  ? A * A ,  ^  _ %   '   A  ?    * A , ! 9
3 ? * *  5  ? A * A ,  ^  _ % ? * *   A  ?    * A , ! 9
D
 '     5  ' `   - E   ]
? A a   A  , Y   ? A * A ,  ^  _ Z   '  Z ? * *  ! 9
H  *  %     -   '     ! 9 ; ; c      M       ? A *   A  ,  
N d
R  ? A * A ,  %      ! 9
U  2  -    X Y A  - %  -
    e -     ! 5 5 e < e  f g h i !
$ V   -     ! 9
$ d d
$ $   # ; ;
        -          ?   M 
$ & A  -
  ? -    5    %   '  9
$ 3    ? -    5    %  * %    ? -    9
$
D
2       5 -  ? 9
$ H   -     ! 9
$ N d d d
m
    n  o            
        

$ & ( * , . , & 1 2 1 & 5 6 * 8 : 1 & 1 = > $ : ? > , * & 1 ( & : 8 > A : B
. : 1 2 & 8 * , . , $ & G , ( . & 8 , 1 H I & J : 8 = : * M , ( & P B
M : * . > ( R
S
> * , 1 & W : 8 8 & 5 : . , : 8 : 1 , 8 I ? > [ * 2 1 &
> * 1 & ( = : & 8 * , . , : * = & ( > , ( & * 8 : 8 > 1 = : . & $ & G , ( & 1
_ 8 a * & : p b R d * ? : 1 , . & H I & * , 1 & M I & . : > * 1 & ( = : (
M , ( H I & i : & P > 1 = & I * , 1 > $ > 8 : ( i $ & G , ( & * & 1 :
8 > 1 = : 2 1 & M : 1 : : : * : 8 > A : ( & 8 1 > 5 I > & * = & * , . , . & 8 :
8 > 1 = : . & : n > & ( = , 1 R d * ? : 1 , ? , * = ( : ( > , 2 1 & ( : $ > p B
? : & 8 1 I n M ( , n 8 & $ : . & 8 * , . , I 1 : * . , & 8 $ q = , . ,
q s u w y z { | q  € ‚ ƒ q | q  ‚ … > $ M 8 & $ & * = : . , M , ( & 8
I 1 I : ( > , _ 8 a * & : † † b R ˆ , . , 1 8 , 1 * I & t , 1 1 I n M ( , n 8 & B
$ : 1 5 & * & ( : . , 1 1 & > * 1 & ( = : * . & J , ( $ : , ( . & * : . :
& * 8 : 8 > 1 = : . & : n > & ( = , 1 _ 8 a * & : † Š b R
S
> i : & P > 1 B
= & I * 1 I n M ( , n 8 & $ : > 5 I : 8 & * 8 : 8 > 1 = : 2 & 8 * I & t ,
1 I n M ( , n 8 & $ : * , 1 & > * 1 & ( = : 2 & t > = : * . , : 1 a = & * & (
1 I n M ( , n 8 & $ : 1 . I M 8 > ? : . , 1 R
S
& ? , * = > * 6 : ? , * & 8
$ > 1 $ , M ( , ? & 1 , W : 1 = : H I & & 8 * , . , H I & 1 & & P B
= ( : > 5 : . & 8 : 8 > 1 = : . & : n > & ( = , 1 t & ( > p H I & H I & & 8
$ & G , ( ? , 1 = & : ? I $ I 8 : . , 1 & : > 5 I : 8 : 8 $ & G , ( ? , 1 B
= & = , = : 8 _ 8 a * & : ΠΠb R d * & 1 = & ? : 1 , 2 1 & p * : 8 > A : 8 :
n 6 1 H I & . : M I & 1 = , H I & i : 1 & W : 8 8 & 5 : . , : 8 : 1 , B
8 I ? > [ * . & 8 M ( , n 8 & $ : R
S
> 8 : 8 > 1 = : . & : n > & ( = , 1 1 &
H I & . : t : ? a : 2 & 8 M ( , n 8 & $ : M 8 : * = & : . , * , = > & * &
1 , 8 I ? > [ * R
d 8 & 1 H I & 8 & = , = : $ n > q * M ( , M , ( ? > , * : 8 : M , 1 > B
n > 8 > . : . . & & 1 M & ? > p ? : ( . & M & * . & * ? > : & * = ( & 1 I n B
M ( , n 8 & $ : 1 R d * & 1 = & ? : 1 , 2 1 & & $ M
8 & : & 8 $ q = , . ,
q s u w y z { | q  € ‚ | € ‚ ƒ q | q  ‚ … 2 & 1 M & ? > p ? : . , M , (
& 8 I 1 I : ( > , 2 H I & 5 & * & ( : * I & t , 1 1 I n M ( , n 8 & $ : 1 :
M : ( = > ( . & 8 : ? = I : 8 i . & , = ( , 1 I n M ( , n 8 & $ :  ‘ . : B
. , R d 1 = & $ q = , . , 1 & & $ M 8 & : ? I : * . , M : ( : ( : $ > p B
? : ( I * 1 I n M ( , n 8 & $ : 1 & . & n & ? , $ n > * : ( q 1 = & ? , *
= , . , 1 8 , 1 H I & i : W : * 1 > . , & P M 8 , ( : . , 1 2 , 8 , H I &
& 1 8 , $ > 1 $ , 2 ? , * = , . , 1 8 , 1 & 8 & $ & * = , 1 . & 8 : 8 > 1 = :
. & $ & G , ( & 1 R d * 8 I 5 : ( . & ( & : 8 > A : ( I * : 6 * > ? : ( : B
$ > p ? : ? > [ * _ q s u w y z b 2 ? , $ , & * & 8 ? : 1 , > * . & M & * B
. > & * = & 2 1 & > * t , ? : : 8 $ q = , . , I * : t & A ? , * ? : . :
I * , . & 8 , 1 & 8 & $ & * = , 1 H I & ? , $ M , * & * 8 : 8 > 1 = : . &
$ & G , ( & 1 _ q “ ‚ ” b i & 8 1 I n M ( , n 8 & $ : : ? = I : 8 R
• : i H I & = & * & ( & * ? I & * = : H I & & 1 = & & 1 H I & $ :
. : ( y 8 : 1 , 8 I ? > [ * [ M = > $ : : 8 M ( , n 8 & $ : 1 [ 8 , 1 > 8 :
J I * ? > [ * ƒ | | “ s – q ˜ ƒ w ™ & 1 1 > & $ M ( & I * : 1 , n ( & & 1 B
= > $ : ? > [ * _ , 1 I n & 1 = > $ : ? > [ * 1 > & 1 I * M ( , n 8 & $ :
. & $ > * > $ > A : ? > [ * b . & 8 t : 8 , ( ( & : 8 R
š z œ
{  | } Ÿ } ~  ¡ ¢ € ¢ Ÿ } Ÿ 
d 1 = & M : = ( [ * . & ( & 1 , 8 I ? > [ * 1 & n : 1 : & * & 8 I 1 , . &
$ & $ , ( > : ? , $ M : ( = > . : M : ( : : 8 $ : ? & * : ( 8 : 1 8 > 1 B
= : 1 . & 1 I n M ( , n 8 & $ : 1 ˜ | “ w i q “ ‚ ” 2 H I & 1 & $ : * B
= > & * & * . I ( : * = & & 8 M ( , ? & 1 , . & n 6 1 H I & . : R ¥ $ B
n : 1 8 > 1 = : 1 = > & * & * 8 : $ > 1 $ : J I * ? > , * : 8 > . : . H I &
XVI Jornadas de Paralelismo, JP '2005 505
  
   
                       
  "     %        )    )     
 /   %      %           % 0    
1    %      
 4      
 % 
    %   7     )    )       % /   %
8
9 :    < = <    %      @ < B B C C < = 4  %   : 
B B D
E    F    F    G <    %  :  
H   G B I
J % 
 K    %      7  < B I   " M              %     )    )    
N    F  %    F    G <    %  :  
H   G B I
O       
P 
  Q Q I
S
 4 < % 
    9   = K % 
       B D   W   X % %    :   %   %   
         %
  4 < )      %     < % 
 B K K     B D   W  )    )     @   %    Y 

  Z         
 [     % 
    %       )    )        %   
 
1 \          4    :
8
   F    F    G < % 
     G B I
E  4 < = < % 
       % 
B C C = < % 
 
 %  B B D
J   ^ %
    [     % 
    _     % 

N % 
       % 
K     I
O    F  %    F    G < % 
     G B I
 S
   `  %          )    )              %
  %   
    % W  )   <  )  b % 
 B I
   % P 
  Q Q I
 1

8
  ^ %
    [     % 
 @  %     _     % 

 E    F    F    G < % 
     G B I
 J % 
       % 
K 4     I
 N c
 O    F  %    F    G < % 
     G B I
S
  "            :  ) d     X % :       )    %
  %   % 

 9 :    < % 
       % 
B B D
\          4    :
1 c
8
E   ^ %        %        /   %      )    )     
  % 

J  %     W  )   < % 
 B I
N  4 <  :   e f          h     @ i  
< B B
O
     < % 
 B I
1 S c c
1     D   W    :   %   %   
         %
1  )    W       % K % 
    9   I
1        % K % 
            % I
1 1 4  %   : 
K     I
1
8

     < % 
 B I
1 E c c
1 J 4  %   : 
K     I
1 N   
m
    o  
          
    " # %   ) * "  - %   - . 0 2 4 0 6 . 7  9   - . 0 9 0 6 . - 0
  # %  <    " )  - 0 " * < 0  " ) 0 9 0 C 0 -   0 6 0 "  
C  C * 9 . 0 - * C F 0 9 ) . 6 0 < 6 . " ) .  ) * " I . * " J K
L
M N O P Q R
F %  6    " ) 0 9 ) 9 0 T 0 U 0  6 * " . C % ) W   0 C   )   
0 Z    9 0 - . [  6  " % T F 9 * T  C 0 " 0 F 0 9 ) . 9 6  6 . 7  `
9   )  " " % T F 9 * T  C 0 " 2 a F 9 .  - . F 0 F 9 * T  C 0 6 
 " )   " # %  C 0  " C 0  )    9 0 . " ) 0 6  0 T .  9 ) * "
* 9 6   0 6 0 2 a * 9 6    "  " ) 9 . - ) 0 C   )    -  " 0 9 . *
F * 9 # %  6  * - *  ) 9 0 9 . * "  F %  6   * T )    9 " * `
% - . *   " 6 . " ) .  ) 0 " 0 0 " [ F ) . C 0 " 2 q 6  C W " < " . " 
 l F 0  6   F 9 . C  9 *  * 6 * " F  * 9  " < 0 C T 0 " . " ) 0 "
. 9 m 0  - 9  - .   6 * .    -  " 0 9 . 0 C   )  < * # %  0 % `
C   ) 0 9 m 0  - * " )  6  0 T q " # %  6 0 2 r * 9  * <  *
"  I 0  F * 6 . 6 *  C F  0 9 C  - 0  . " C * "  " ) W  6 0 9
F 0 9 0 0 6 . " ) 9 . T % - . [  6  ) 9 0 T 0 U * 2
4 0 ) v -  . - 0 "  Z % . 6 0 "  T 0 " 0   %  C * 6  *
y O N Q K M z { N Q | } O ~ z 2 q  )  " 6  # %  ) * 6 * " * " I . * "
- * C .   -   0 ) 9 0 T 0 U 0 9 - *  U %  ) 0 C   )  <  C 0  " `
) 9 * "    - 0 9 Z 0 6  Z    9 0 9 * " " % T F 9 * T  C 0 " .  . `
- . 0  "  .  "  9 ) 0 9 * "   0 . " ) 0 6  0 T .  9 ) * " 2 q
F 0 9 ) . 9 6   " )  C * C   ) * < ) 0  ) *  C 0  " ) 9 * - * `
C *  9  " ) * 6  * " I . * " - * C .   ƒ 0  0 ) 9 0 T 0 U 0 9
506 Algoritmos y Técnicas de Programación Paralela
  
   
                        
!   "  $        (    (   $  
 +   ,   ,   $  /     0   ,          (    (   $  
1 3 4    6 7 /  ,   4 
8 8
9
:
;   + (   ,        $     (    (   $    ,     ,   0   ,    (       4    
= >     $   $  /    4
?  $  @    @    A 6    ,  4  
E   A 8 G
H , 
 I    ,  4  
G
K  / 6 , 
 7 I M N E E 8
 $  @    @    A 6 , 
     A 8 G
  $  @  ,    @    A 6    ,  4  
E   A 8 G
! 3 4    6 6 , 
 7 I M N E E 8 R R 6 6 , 
       , 
8 T T 6 , 
 
 ,  8 8 8
1 :
9
    , 
 I , 
 G
; , 
 I , 
  ,  X  G
=  $  @  ,    @    A 6     , 
     A 8 G
?  / 6 , 
 7 I M N E E 8
H  $  @    @    A 6 , 
     A 8 G
 K >     $   $  /    4
 Z
 
 !   "   (       (      , 
    (    (   $ 
 1  / 6 , 
 7 I M N E E 8

9
:
 ;   [ ,
    \    4      , 
    ]     , 

 = , 
       , 
I     G
 ?  $  @  ,    @    A 6 , 
     A 8 G
 H   , ^  ( $  6  ( $ _ , 
 8 G
! K   , M 
  ` ` G
!
!    [ ,
    \     , 
 0  ,     ]     , 

! !  $  @    @    A 6 , 
     A 8 G
! 1 , 
       , 
I /     G
!
9
 $  @  ,    @    A 6 , 
     A 8 G
! ; Z
! = >     $   $  /    4 6 /  ,   4 8
! ? Z
! H   
b
    d  
          
 " $ % & ( ) + , " + ) & + + ) % , 4 +  5 % $ 6 7 ) 9 + % ; 4 5 < % + =
" , > ? ) ; 4 " + 4 % $ B , 4 D  + + F ; % 6 , + ) I $ K 6 5 )   =
& + + % & 4 , < , P 5 4 + , % Q , 9 5 ; 5 4 + % " , +  & 4 5 T e B $ 4 ,
f U > ? % " , +  & 4 5 + ) 6 , 9 , ; ,  5 D  , 6 , + % ; 4 " + 4
) 5 9 5 9 + % , %  & , 9 + , < + 4 & 5  T % ` ) + , h U a 6 5 " =
; 4 $ + < ,  a ,  + f , % % + B , 9 5 , % ,  5 % $ 6 7 ) >
i
a ,
 + f , % % + B , 9 5 , % ,  5 % $ 6 7 ) D % , < j  I $ + 9 ,  + 9 ,
; 5 4 k ) , % Q , 9 , T % ` ) + ,  i f = i l U > ? ) 6 ,  5 6 5 ) & 4 , =
4 5 D  + )  + 4 & , + %  $ < ; 4 5 < % + " , 5 ) 5 9 5 , 6 & $ , %
+ ) % , %  & , 9 + " + P 5 4 +  T % ` ) + , n f U D  + " ; 4 + I $ +
) 5  + f , a , , ) , % Q , 9 5 a , $ ) 5  " % , 4 a " + P 5 4 >
i
$ ; 5 ) + ) 9 5 I $ + + % ) 5 9 5 +  )  + 4 & , 9 5 + ) p r s u D
+ %  B $ + ) & + ; ,  5 6 5 )   & + + ) 6 5 " ; 4 5 < , 4  f , a
, % B $ + ) + ) 6 , 4 B ( ) 9 5  + 9 +  $ 4 , " k 6 , 6 7 ) 5 
K  & , a , f ,  9 5 + q + 6 & $ , 9 , T % ` ) + , n w U > ? ) + %  $ =
; $ +  & 5 9 + I $ + + % ) 5 9 5 ) 5  + f , a , + F ; , ) 9 9 5
) ) , 9 + % 5 +  & K f , 6 + ) 9 5 D +  + % ; 4 5 ; 5 " , +  =
& 4 5 I $ + )  + + ) 6 , 4 B , T % ` ) + , f f U >
i
+ % ) 5 9 5 +  & (
,  B ) , 9 5 D + % " , +  & 4 5 9 + < + +  ; + 4 , 4 ; $ +  & 5 I $ +
+  5  B ) k 6 , I $ + , % B j ) +  6 % , s 5 % + +  & ( B + ) + 4 , ) =
9 5  $   $ < ; 4 5 < % + " ,  T % ` ) + ,  y f = y i U > u ) , s + Q
% 5   $ < ; 4 5 < % + " ,  9 + % ) 5 9 5 a , +  & K ) B + ) + 4 , 9 5  D
+ % " , +  & 4 5  + + ) 6 , 4 B , 9 + )  + 4 & , 4 % 5  9 + q 5 4 " ,
5 4 9 + ) , 9 , + ) % , %  & , { | r } T % ` ) + , y h U >
? ) % , e B $ 4 , y  + " $ +  & 4 , + % 6 7 9 B 5 9 + % 5 
+  6 % , s 5  > ‚ ,  & , I $ + + % " , +  & 4 5 ) 5 ) 9 6 , I $ +
% , < j  I $ + 9 , f , k ) , % Q , 9 5 D 6 , 9 , +  6 % , s 5  + + ) =
6 , 4 B , 9 + B + ) + 4 , 4  $ < ; 4 5 < % + " ,  , % 5  ) 5 9 5  9 +
{ | r } I $ + & 5 9 , s ` , ) 5  + f , a , ) + F ; % 5 4 , 9 5 > z 5
; 4 " + 4 5 I $ + f , 6 + 6 , 9 , +  6 % , s 5 +  4 + 6 5 4 4 + 4 % ,
%  & , 9 + , < + 4 & 5  f ,  & , + ) 6 5 ) & 4 , 4 $ ) ) 5 9 5 I $ +
) 5 +  & K ,  B ) , 9 5 a I $ + & + ) B , & 4 , < , P 5 ; 5 4 f , =
6 + 4 T % ` ) + ,  h = f n U > { $ , ) 9 5 + ) 6 $ + ) & 4 , $ ) ) 5 9 5
I $ + 6 $ " ; % , % 5  4 + I $  & 5  , ) & + 4 5 4 +  D % 5 " , 4 6 ,
XVI Jornadas de Paralelismo, JP '2005 507
                     " #   "   &
           +       "  /  1    2 4  4  1
       /          8  :   
 &   < =  &
# > #    "                   + 
   "  /    1      G   : 4    +         
 I     +    " G +    4  L     M    =
N  O        L    #           
+        M    " G +        +        &
L   O      " #   "                &
     T     T    T    = U            &
  I                   W   O        ! " 
>   #                 I  M      
" #   "            = \        " #   &
"            +      W              
  #  "   ! "        1     #  % &    #   
       #    +   #         " #   "    
       1     #      "       2   &
I  " #   "     = N  #   "      #       &
  I        I   #    /   #      #   "  
+           2       1        
         "            L     = (   "  > 
4  1 #   "              I     #   "   
       2            #           
    +      I  I                &
    = U     I          #      )      4 
 i                I     "     "   +   =
N   I     "          #  & !  , . & / 0 , 1 1 
  #    +    +       8        
      <     #  2 " " 3    %        
4     W      k   I  #   #        G   &
 4    = l         I    2             
       "                        2    &
       #               8      M    
   :           "  M          <     &
        "  >     #         I     "    
"   +   #       "  M    &    = N   I     "  
  "              #         L   8  :   
     6   
<      8  :    8     6   
 <    "  M             "      = U      
       1   #          4  4    +     
  4           I   O             
I     "     #       =   4 :  +     #    
  I    ; . < " > #         +         
  W      O       M    =
N        +        L   O       
              T    T             O   
  " #   "                "  4  &
  +   4  1    "              " &
#   "     #   I   = U           #     "   
        "  / 
#               +     &
#   "      G          " #   "     + 
4    #      #        L   8 . 2 " 1 A " <    G  &
                        /    =
o
   
    :     #             I  " #   &
"       #                          
  . 2 " 1 A " 4          L              " 1 =
C p
q r s t E u F v w s x w y H t u F x z w | F E r s
N  #   "           #         M       2   
                 +         U   "      
l     ~            J L   M = \    #         O 
     M         +       "   #          
              N       4   1 ~  4  J P   M =
N           #       +    +       O 
 #     "             "     O      &
     €  ‚ Q ƒ ‚  „  ƒ … † ‚   #   M    "       
W     4    M      1 I       = N          &
   4              +           
‡ † S ƒ ˆ ‰ €  ‚ Q ƒ ‚  „  Š …              +      &
W       M +          #   L   V 1   "      
  4    M      1   I             /    €  ‚ ‰
Q ƒ ‚  „  ƒ … † ‚          #   I        = N   &
        M          O               
    T    T    = U             #       
 4                        /     
       #   #      J
M              ‹
W X
 Y Z 1 Y \ =
\   k #          4        M       
 2 +        #           #        
^     _    L  a a Πb M = N    2 +    W    
#               \  "           U        &
         I         \  \    8 c † ƒ d Ž   < =
U                    "           &
    #      +    #             l    
L              #     /   O     
 +            1 #           G   
4    = N    l    
         G      
      #         G              &
    1       #          /   O      &
+      #         
  1  4    =
\  6           2 L          G   &
               #     1        
  #    I        #      #   "          &
    = \  6    i   #        2 L        
                "       = j   4     
        #        /   O        =
k                  "          &
508 Algoritmos y Técnicas de Programación Paralela
     
  
      
  

                   
                 
   
     ! " !  # ! % ' ' " ) #  )     ! )  # ' % # " ,   #
- ) " # )  " )  " '  % , ) # , " # " )   !  ,  % ,  # , "
-   # ' )   ! ' , # %  '   ! )     !  ! % #  " , #
   
       
               " 
$   %   
 ) 
!
  / 
  / )
  /

               
             
             
   
  )     !  #  ) % " , )   # ) ! !   !   "  % ' ' ' " # ) )  ) )    # "  %  "    #
- ) "  )  '  ' ' , %      " ) "  #  ' ! , %   ' , ) # " #   ) ' , " ' %  #  )  "
-      # ! " ! # % # ! ,  ) #   ! ' # ! # "  % " '      ! #  " '   %   ! !  "
   
       
   ,         " 
$   %   
 ) 
 4 6 8 : < 4  6 = > ? > : < = 4 A B D 8 : G : ? > H < I > J G : M >
)    O     )
Q R  S O   )           )  O    
 X %  
  

 [      
 \ 

 O      
   )          )     $    )
 b       
 
        S       
,      
    O     )  
f       R  

    %   %
h           j 
          Q )

 
   $ , 
$   %       
  
     )          )     $    )
 h
m
   % $   [
Q
      O   %  ,      

   $ , 
$   %      
%              )          

S  j 
 
     )      # %     
   R


     
  p  
h  X  )  %
  $ , 
$   %  [      
   
,   %  
O          )  Q    )
    f q  O      
  
          h  )
,     , 
f
   O   

  $ , 
$   %   
  [    f  
    
 )  )
)  
  )  %  
\ ; ' ' ( <
) > ?
; r + b O        f   )  
  
     ) 
   $    )
   [ X    t    
 
    
   )    )   h "

) 
  
Q       
    
       j  ,        
 [        j      $ , 

$   %       ,       )  Q     
  R  
)   $   

   

Q   [      )

      $ , 
$  
%   h      
  [        j    ,       )  Q  
,     [       % t 
%  
   $ , 
$   %    
[ X    t  )
    %   )
  x   )          )   #  .

 
 O    X  
  R  S  
% $    
h 0


  
R    O     ,      ,      )    
%   z  

%
     , 
$   %  2 4 
   O     , 
   
  ,                  t    
             j  h
@ { B
| } ~ 6  €  | } ‚ €
   )  )   $  
  R  ,      )  
    O   % 
    
    j            S
) 
,      
,   
$ X  O      ƒ „ h    O     )
,      

  )  )  S 
    ,
 )    j  
f  
  Q ,    )
O         ) 
  )    
  R     
 )   
  O   %       ) 
)  ,
,    … ,   † " h 0  % $  q    R   %
 )  


      )  

$ )    
 ,      , 
$   % 

% ,   
h
%
  ,      ,       Q       

  p    j           ,    %   )           )    
%  %
   
% ,   )      ) 
       
$      [ 

       $      f     j  ,        h ‡   %  
  
 
$ )      [        O       f     j  ,   
    Q 
 ˆ
 %  
  $
   % t  , 
    
   Q  
f          
   X %  
  

 [      
 h
 )
    $   O       )     p    j      %  


)    )      f       p   
  %   ) t    %   ) 
,
 )

 
 R  
 Q 
O      ,   %  )       
)     $ , 
$   %   O         
          R 
XVI Jornadas de Paralelismo, JP '2005 509
 
  
     
 
  
        

 ! # % '     ( * % , ( * .  , . * 0 , . , 1 3 ' % ' * 6 % ,  6 * ( ' . * ; , % = *

  ?     C   E  C 
   
I
     J    K

 M      N          
 M

 J    
      
    J  
U 
? K   X
 
   C   J          C    U    C  C  X
   J
E  J     C
 C   
 

I    M
K

      M   N      J    

   
`     X
    J
 J
E    K        N   J  K J 

C 
  C  
      
I     C e 

    X
     J  f 
C g      J J       C         C X
        f 
C g      J J  C   J        X
 C     
   
 N
I
 h  
i  j k l m n m k p q r s
t
      N  v 
C  
  f   C         `   X
 
         U    J y C  C
  C   z C  X
 C  U     J   ?   J       J } J  
 X
 C    J  # %  % # )    J    U     €   
*
#  + - - + . - 0 0 1 3 . 5 - 7 . - 7 I     C e  v       C X
  C   J 8   C     z     C 
   J    U   
;  ‚ 9 9 ƒ ; 9 ‚ ‚
I t J      N   8 I y C     
v 

    J J       J     } … X  } X     X     I
† k = k i k p l m  s
    U  ? v  A K I K C E F " ‰ Š ‰ ‹ F ‰  H Ž    ‘ ‹ ’ ‘ “
I ’ ” J  ‘ ‹ I • ‰ M Š – — ˜ K t       O      J  `
š     C    J Q
   v K $  J     K   ( R
 (  K     I
   C › K y I K S — " • ‰ œ – — – ‘  ‰  U  ˜ 0 ’ ‘ ’ 

’ ‘ ’ ‘ “
1 ’ ‹ ”

 V ˜ X Z ’ ”  C Š ‹ ‰ •  

—  ‰ • H ‰ ‘ ˜  • ’  ‘ – “
E 0 ‰   ]  — – ‘ ˜  ‰ ‘ ’ Š H Ž    ‘ ‹ _  ‰ ” J K z     X
  š 
   C  
Q
   v K $  J     K 5  5 R
5 6 7 K    5 I
 6  y C      K 8 I K ¡ g  K z I K Q    ?   ¢ K z I K S —  
" Š – — – ‘  ’ ”  £ ‘ “ – Š I • ‰ M Š – — ’ “ – H ‰ •  – 1  “   
— – ‘ ˜  ‰ ‘ ’ Š ” ‰ ‘ Š ’ d  M • – • ¤ ’ f g h h i g K    

 J 
: $ O      
 }    J J C
  K  J  X
 ?  K
¥
  C  K  7 R    K     I
   y C      K 8 I K ¡ g  K z I K X ˜ ¦ Ž – Š –  ‰ ˜ " ’ • ’ C Š  
‹ ‰ •   — ‰ ˜ C k K     I  t
   ?
 C   K A I š I U
z        C g  K …  C f 
C     ¡  ¡      K
  X  t A š z X   X  7 K     I
 (  š   y }    v C      Q f C § ¨     K
m
" – ‘ n I H ’ ‘ “ H p p C " " Š  ” ’  
  ‰ ‘ I • ‰ ‹ • ’ — S ‘  – •  ’ ” – K $ 
C    I  K
v    © C C § § § I      I    K    D I
 7 
¥
§  U K } I t I K }     
  K t I Q I K H Ž   
  ‘ ‹ ’ ‘ “ I ’ ” J  ‘ ‹ I • ‰ M Š – — ˜ v C H ’  – ‹ ‰ •   
x
– “ z C " " Š  ” ’   ‰ ‘  
m
•  – ‘  ’  – “ { – ˜ – ’ • ”

1   
M Š  ‰ ‹ • ’ "

F K O      J  `  v š     C    J Q X

   v
¥
  C  U K $  J    6 K 7   R 5  7 K     I
 5  $ C
§     v   K } I $ I K ¨    v C K  I K 1 – ˜    ~  • ˜ 
_ – ’ • ”

n – 

‰ “ ˜  ‰ • H ‰ ‘ ˜  • ’  ‘ – “ E 0 ‰  
]  — – ‘ ˜  ‰ ‘ ’ Š H Ž    ‘ ‹ _  ‰ ” J I • ‰ M Š – — ˜ K š  X
   C  
Q
   v K $  J     K 5 7 D R 5 5 7 K
   6 I
510 Algoritmos y Técnicas de Programación Paralela
   
                   #       '   )     #    '
     0   
1 3 5 7 8  : 1 3 5 8 #  :  5 7 @ 8
A B C E G I E K L M N B O I Q E G G S K A B O I Q E G G S K M W B X Z K E [ \ ]
^ _ ` b c e _ g h i k l b _ m b k h n o p _ m q r t r w x n ^ _ ` b c e _ { l _ q m l n e _ t n { r | ` k b n m l  q
e _ { r | ` k b n e r h _ € _  q b _ t l w _ q m l n g h b l „ m l n t
… q l † _ h € l e n e ‡ l w k _ t ‰ _ h q Š q e _ ‹ … q l † _ h € l e n e e _ g t l m n q b _
 Ž    
t m ‘ _
 Ž  ’ ” •
n q – l m _ q b _
g t l m n q b _ —
•
` n l q g t l m n q b _ —
•
` n l q
˜
† w n t l n q r — ‘ | l w n t t r q š › k | ‘ c _ €
˜
† l r t _ b n —  ` _ q n e _ € š › e m m l n c k n c _ €
Ÿ ¡ ¢ £ ¤ ¡ ¥
¦ ¨ © ª « ¬ « ­ ® ° © « © ° ± ² ³ ¬ © ± ´ ­ ¨ ¶ « © ° ± ² « ® ³ ¬ ¸ ³ « ® ° ¹
º
« ² » ³ ¶ ³ ¸ ´ ° ² « » « ¬ ± ­ ³ ¸ « © ° ± ² ³ ¬ » ³ ® ½ ® ¾ ³ ¿ ¸ « ® ° ² ³ ¹
« ® » ³ ¨ ² « À ± ¸ ´ « ° ² ¶ ³ ² ¬ ° Ã « ­ ± ¸ ® ± Ä ¨ ³ ¬ ³ ³ Å ° ¾ ³
¨ ² « ® ¶ ± ¸ ³ ² » ° ´ ° ³ ² ¶ ± ³ ² ® « ¬ ´ ° ¬ ´ « ¬ È É » ³ ´ ½ ¬ Ë
¾ ¸ « ² ­ « ¸ ¶ ³ » ³ ³ ¬ ¶ « ¬ « ­ ® ° © « © ° ± ² ³ ¬ ¸ ³ « ® °
º
« ² © ½ ® ¹
© ¨ ® ± ¬ ¬ ± ¿ ¸ ³ ¨ ² ³ ® ³ Ã « » ± Ã ± ® ¨ ´ ³ ² » ³ » « ¶ ± ¬ Ë ® ±
Ä ¨ ³ ¸ ³ Ä ¨ ° ³ ¸ ³ ¬ ¨ ³ Ð ³ © ¨ © ° Ñ ² ³ ² ­ ® « ¶ « À ± ¸ ´ « ¬ » ³
« ® ¶ « ¬ ­ ¸ ³ ¬ ¶ « © ° ± ² ³ ¬ È Ò ± ¬ ° ² Ã ³ ¬ ¶ ° ¾ « » ± ¸ ³ ¬ ³ ° ² ¾ ³ ¹
² ° ³ ¸ ± ¬ Ä ¨ ³ » ³ ¬ « ¸ ¸ ± ® ® « ² ³ ¬ ¶ ³ ¶ ° ­ ± » ³ « ­ ® ° © « © ° ± ² ³ ¬
© ± ² ¬ ¨ ´ ³ ² ´ ¨ © ª ± ¶ ° ³ ´ ­ ± Ô ³ ¬ À ¨ ³ ¸
º
± ³ ² » ³ ¬ « ¸ ¸ ± ¹
® ® « ¸ Ô ³ Ð ³ © ¨ ¶ « ¸ © Ñ » ° ¾ ± ¬ ³ Ö © ° ³ ² ¶ ³ ¬ ³ ² ³ ¬ ¶ ³ ¶ ° ­ ±
» ³ ­ ® « ¶ « À ± ¸ ´ « ¬ È Ø ¬ ¶ ± ¬ ³ ¬ À ¨ ³ ¸
º
± ¬ » ³ ¿ ³ ¸ Ù « ² ¬ ³ ¸
¨ ¶ ° ® °
º
« » ± ¬ ³ ² ³ ® « ² ½ ® ° ¬ ° ¬ » ³ ® ± ¬ ¸ ³ ¬ ¨ ® ¶ « » ± ¬ Ô
² ± ³ ² ° ´ ­ ® ³ ´ ³ ² ¶ « ¸ ¨ ² « « ­ ® ° © « © ° Ñ ² Ä ¨ ³ ­ ³ ¸ ´ ° ¹
¶ « ± ¿ ¶ ³ ² ³ ¸ » ° © ª ± ¬ ¸ ³ ¬ ¨ ® ¶ « » ± ¬ È Ý « ¸ « « ® ° Ã ° « ¸ ³ ¬ ¶ «
­ ¸ ± ¿ ® ³ ´ ½ ¶ ° © « Ë ­ ¸ ± ­ ± ² ³ ´ ± ¬ ® « ¸ ³ ¨ ¶ ° ® °
º
« © ° Ñ ² » ³
® ° ¿ ¸ ³ ¸ Ù « ¬ ¸ ± ¿ ¨ ¬ ¶ « ¬ Ô ´ ¨ Ô ³ Å ¶ ³ ² » ° » « ¬ © ± ´ ± ® « ¬
° ² © ® ¨ ° » « ¬ ³ ² ® « Þ ± ® ³ © © ° Ñ ² É Þ ß à Ë Ô ­ ¸ ³ ¬ ³ ² ¶ « ¹
´ ± ¬ ² ¨ ³ ¬ ¶ ¸ ± ¶ ¸ « ¿ « Ð ± ³ ² ® « © ¸ ³ « © ° Ñ ² » ³ ° ² ¶ ³ ¸ ¹
À « © ³ ¬ » ³ « ® ¶ ± ² ° Ã ³ ® « ¨ ² ¬ ¨ ¿ © ± ² Ð ¨ ² ¶ ± » ³ ¸ ¨ ¶ ° ¹
² « ¬ » ³ ³ ¬ ¶ « © ± ® ³ © © ° Ñ ² È Ý « ¸ « ³ ® ® ± ª ³ ´ ± ¬ ³ ® ³ ¾ ° ¹
» ± ³ ® ® ³ ² ¾ ¨ « Ð ³ Ý Ô ¶ ª ± ² © ± ´ ± ® ³ ² ¾ ¨ « Ð ³ » ³ « ® ¹
¶ ± ² ° Ã ³ ® Ë » ³ ¬ » ³ ³ ® Ä ¨ ³ « © © ³ » ³ ¸ ³ ´ ± ¬ « ® « ¬ ® ° ¹
¿ ¸ ³ ¸ Ù « ¬ » ³ « ® ¶ ± ¸ ³ ² » ° ´ ° ³ ² ¶ ± Ä ¨ ³ ª ³ ´ ± ¬ ® ® « ´ « ¹
» ± Ý Ô É Þ ß à È Ý ± ¸ á ® ¶ ° ´ ± Ë © ± ´ ­ « ¸ « ´ ± ¬ ® « ­ ¸ ± ¹
¾ ¸ « ´ « © ° Ñ ² ¶ ¸ « » ° © ° ± ² « ® © ± ² ® « ­ ¸ ± ­ ¨ ³ ¬ ¶ « ³ ° ® ¨ ¬ ¹
¶ ¸ « ´ ± ¬ « ® ¾ ¨ ² ± ¬ ³ Ð ³ ´ ­ ® ± ¬ » ³ ³ ¬ ¶ « ¬ ° ² ¶ ³ ¸ À « © ³ ¬ Ë
³ Ã « ® ¨ « ´ ± ¬ ¬ ¨ ¸ ³ ² » ° ´ ° ³ ² ¶ ± © ± ² ¸ ³ ¬ ­ ³ © ¶ ± « ® «
´ ³ ¶ ± » ± ® ± ¾ Ù « ¶ ¸ « » ° © ° ± ² « ® Ô ® « ¬ ´ ³ Ð ± ¸ « ¬ » ³ ­ ¸ ± ¹
» ¨ © ¶ ° Ã ° » « » ³ ² ³ ® ¨ ¬ ± » ³ ³ ¬ ¶ ³ ² ¨ ³ Ã ± ³ ² ¶ ± ¸ ² ± È
â ã å
¥ æ ç è é £ ê ê ë ì ¥
Ø ² ´ ¨ © ª « ¬ ½ ¸ ³ « ¬ © ° ³ ² ¶ Ù Ö © « ¬ Ô » ³ ° ² ¾ ³ ² ° ³ ¸ Ù «
³ ¬ ² ³ © ³ ¬ « ¸ ° ± ¸ ³ ¬ ± ® Ã ³ ¸ » ³ ¶ ³ ¸ ´ ° ² « » ± ¬ ­ ¸ ± ¿ ® ³ ´ « ¬
© ± ´ ­ ¨ ¶ « © ° ± ² « ® ³ ¬ ¸ ³ ® « ¶ ° Ã ± ¬ Ë ­ ± ¸ ³ Ð ³ ´ ­ ® ± Ë « ¨ ² «
¬ ° ´ ¨ ® « © ° Ñ ² Ë ­ « ¸ « ³ ¬ ¶ ¨ » ° « ¸ ¨ ² À ³ ² Ñ ´ ³ ² ± À Ù ¬ ° © ±
­ « ¸ ¶ ° © ¨ ® « ¸ È Þ ° ³ ² ¶ Ù Ö © ± ¬ ³ ° ² Ã ³ ¬ ¶ ° ¾ « » ± ¸ ³ ¬ ­ ° ³ ¸ » ³ ²
¨ ² « ­ « ¸ ¶ ³ © ± ² ¬ ° » ³ ¸ « ¿ ® ³ » ³ ¬ ¨ ¶ ° ³ ´ ­ ± ³ ² » ³ ¬ « ¹
¸ ¸ ± ® ® « ¸ ³ ¬ ¶ « ¬ « ­ ® ° © « © ° ± ² ³ ¬ Ä ¨ ³ ¸ ³ Ä ¨ ° ³ ¸ ³ ² » ³ ¨ ²
© Ñ » ° ¾ ± « ® ¶ « ´ ³ ² ¶ ³ ³ Ö © ° ³ ² ¶ ³ Ä ¨ ³ ­ ¨ ³ » « ¬ ³ ¸ ³ Ð ³ ¹
© ¨ ¶ « » ± ³ ² ­ ® « ¶ « À ± ¸ ´ « ¬ » ³ « ® ¶ « ¬ ­ ¸ ³ ¬ ¶ « © ° ± ² ³ ¬ È
à ° ² ³ ´ ¿ « ¸ ¾ ± Ë ® ± ¬ » ³ ¬ « ¸ ¸ ± ® ® « » ± ¸ ³ ¬ » ³ ¿ ³ ¸ Ù « ²
© ³ ² ¶ ¸ « ¸ ¬ ³ ³ ² ¬ ¨ ° ² Ã ³ ¬ ¶ ° ¾ « © ° Ñ ² Ô ³ ² ³ ® « ² ½ ® ° ¬ ° ¬
» ³ ® ± ¬ ¸ ³ ¬ ¨ ® ¶ « » ± ¬ » ³ ® « ¬ ¬ ° ´ ¨ ® « © ° ± ² ³ ¬ ´ ½ ¬ Ä ¨ ³
³ ² ³ ® © Ñ » ° ¾ ± » ³ ® « « ­ ® ° © « © ° Ñ ² « » ³ ¬ « ¸ ¸ ± ® ® « ¸ È Ý « ¸ «
« ® ° Ã ° « ¸ ³ ¬ ¶ ± Ë ­ ¸ ± ­ ± ² ³ ´ ± ¬ ® « ¸ ³ ¨ ¶ ° ® °
º
« © ° Ñ ² » ³ ® ° ¹
¿ ¸ ³ ¸ Ù « ¬ ³ ¬ ¶ « ¿ ® ³ ¬ © ± ´ ± ® « ¬ ° ² © ® ¨ ° » « ¬ ³ ² ® « Þ ± ® ³ ¹
© © ° Ñ ² É Þ ß à í î ï È à © « Ò É Ý É Þ ð í ñ ï Ë ò Ò É Þ à í ó ï
Ô Ý ò Ò É à í ô õ ï ¬ ± ² « ® ¾ ¨ ² « ¬ » ³ ® « ¬ ª ³ ¸ ¸ « ´ ° ³ ² ¶ « ¬
» ³ ® « Þ ± ® ³ © © ° Ñ ² É Þ ß à Ô ¬ ³ ¨ ¶ ° ® °
º
« ² « ´ ­ ® ° « ¹
´ ³ ² ¶ ³ ³ ² ´ ¨ © ª « ¬ « ­ ® ° © « © ° ± ² ³ ¬ © ° ³ ² ¶ Ù Ö © « ¬ Ä ¨ ³
³ Å ° ¾ ³ ² « ® ¶ « ¬ ­ ¸ ³ ¬ ¶ « © ° ± ² ³ ¬ È à © « Ò É Ý É Þ ð ° ² ¶ ³ ¸ ¹
² « ´ ³ ² ¶ ³ ° ´ ­ ® ³ ´ ³ ² ¶ « ³ ® ­ « ¸ « ® ³ ® ° ¬ ´ ± Ô ® « ³ ¬ © « ® « ¹
¿ ° ® ° » « » « ­ « ¸ ¶ ° ¸ » ³ ® ¨ ¬ ± » ³ ® « ¬ ® ° ¿ ¸ ³ ¸ Ù « ¬ ò Ò É Þ à
Ô Ý ò Ò É à È Ø ² ´ ¨ © ª ± ¬ © « ¬ ± ¬ Ë © ° ³ ² ¶ Ù Ö © ± ¬ ³ ° ² ¾ ³ ¹
² ° ³ ¸ ± ¬ ³ ² © ¨ ³ ² ¶ ¸ « ² ´ « Ô ± ¸ » ° Ö © ¨ ® ¶ « » ³ ² ® « ¨ ¶ ° ¹
® °
º
« © ° Ñ ² » ³ ® « ¬ ® ° ¿ ¸ ³ ¸ Ù « ¬ ò Ò É Þ à Ô Ý ò Ò É à » ³ ¹
¿ ° » ± ´ ½ ¬ « ® ± ¬ « ¸ ¾ ¨ ´ ³ ² ¶ ± ¬ ² ³ © ³ ¬ « ¸ ° ± ¬ ³ ² ¬ ¨ ¬
° ² ¶ ³ ¸ À « © ³ ¬ ¸ ³ ® « ¶ ° Ã ± ¬ « ­ « ¸ ½ ´ ³ ¶ ¸ ± ¬ » ³ ® ³ ² ¶ ± ¸ ² ±
Ô » ³ ¸ ³ ² » ° ´ ° ³ ² ¶ ± Ë Ä ¨ ³ « ® « ¸ ³ ¬ ± ® ¨ © ° Ñ ² » ³ ® ­ ¸ ± ¹
¿ ® ³ ´ « Ö ² « ® È ù ± ¬ ± ¶ ¸ ± ¬ ¶ ¸ « ¿ « Ð « ´ ± ¬ ³ ² ³ ® » ³ ¬ « ¹
¸ ¸ ± ® ® ± » ³ ¨ ² « © « ­ « ¬ ¨ ­ ³ ¸ ° ± ¸ « ® « ¬ ª ³ ¸ ¸ « ´ ° ³ ² ¶ « ¬
   
            "    $ &
  '    * ,
-   / /  0         - * 3   0   0   3   3 :   ;  0 
  -  3 * >   /    " - A  3 "
  '     3 -      3
  -  0  /    3 -  /  3    * 3 -   E  /        * I    J  
K L   " K L  Q R  -   0    * I    J   *  '  * /  3
 3  /   '   ;    -   / -    0  0  -   0 *  -  * I  * 0 

     * 3 -   E  /   0  " K L   " " K L 

  /  3 0  3        *  \ 3   & A  / * ] 3 0     ^    3 ,
/ *       - *  *
_
 / * ` 3 Q
   /       -   * 3 -   E  /   A        : * 0   
  3 :   ;  " - A  3 0  I * 0   0 * >       
_
 3  
 
 e '  * /        3     / / * ` 3 i Q R 3     / / * ` 3
k
& * 3 -   0  / *    I   >    3 -      I ;  - * >   0  
'   "  / -  "   
      3 l /    0   -   I  ; 
'     3 -  0  Q R 3      / / *  3   n " o & '     3 -  ,
       ` 0     " K L   " " K L  &    ,
'  / - * >    3 -  & /   '    3 0      3 0 *  *  3 -  0 
  -    * I    J   /  3    '  / -      3 0 *  *  3 -   3
    -  0    : J  3  - * >  Q   l  - *   & '     3 -  ,
   3    -    /  3 /    *  3   "     J 3    0  -   ,
I  ;  E  -      3     / / * ` 3 u Q
v  
w  x y  y z
 
 {
" - A  3 | } } ~    3   3 :   ;  0  '   :     / * ` 3
* 3 -   '   -  0  & * 3 -    / - * >  "   *  3 -  0    I ;  ,
-   Q " - A  3 /   I * 3   3  '  -  3 / *      >  3 - 
/  3  3   * 3 -  e *    " /     Q *  '  3  0   ` 0  ,
   & /      &  e /  ' / *  3   & - * '   0  0  -   0 * 3 ^  * ,
/   0    -  3 * >   "  -    /    / -   J  - * /  
 
  A  /  3   " >    ^ - *  Q  E   /  * 3 -   E  /   '   
  / A   0          0      *  -    "      * ,
I    J   &   J /    >   *    *  -     0    3  ;  0 
>  3 -  3     } } &   - * E &   &   / &    $ Q  
 -     0  & /     3   >    ` 0       /  * -    3 
       3  -       "   3 / *    Q
" - A  3   - ^ 0 *     0  '    '   * I *  * -     * 3 ,
-  :   / * ` 3 /  3  -    /   '  3  3 -     E -      3
   *  -    Q L   '   :        /  * -    3 " - A  3
'   0  3     / *  3     0  E       "   3 / *    /  3
 -      3 :   ;   Q 0   ^  &     /  * ' -  0  " - A  3
'   0  3     *
_
       0     * I    J    e *  -  3 -  
 &    " /      0    >   3 -    -    Q R  - 
l  - *   /    / -   J  - * /  A   * 0  0  -    * 3  3 -   3
3    -    '    -  '     -    3 :   ;  Q
R 3       3 &    -        :  3   0      
_
 3  
'     
  A        : * 0  " - A  3 '    /    
   * 3 -   E  /   0     * I    J  "   
•
…  A  " '     0  /   ' *   / * ` 3   3  
_
 0 
0   I ;  -   Q
•
…        *
_
 0  /     / * ` 3 0  - * '   0 
0  -   Q
•
L    '    / *  3   "    - * '   0  0  -     3
0    -  3 * >   Q
•
R e - *  3 0     E  3 / *  3   * 0  0   /  3  * I    J  
 Q
•
      *
_
  3  /   :  0 * 3 ^  * /  0      ` ,
0         0 * 0 
  ]  -     3  /   * -  3 Q
•
   ;  /  -   3 0     0   * 3 -   '   -   * 3 ,
-    / - * >  Q
0   ^  & " - A  3   '   -  I   &   0  / *  &    ;  ,
/  -   3   / A   *  '     3 -  / *  3   0  " … $  &
% * 3 0    &   / "  -    '   -  E      Q " - A  3  
 3   3 :   :  '   ' *  -   *  '    0   * I   0 *  -  * I  ,
/ * ` 3 "    & * 3 /     /  3 \ 3   /     / *     "    
/  3  * 0    /     3   3 :   ;  * 0    '      0  ,
        0  '   -  - * '   "  -    -      (  0 , A  / ) &
 * 3 /   '     -       3 -  3 *  *  3 -  3 *   /   ,
'   3  * ` 3 0   / ` 0 * :  Q
R 3   E       * : * 3   & " - A  3 3    - ^  3 E  /  0 
'    '   :     / * ` 3  3 '        Q    '    * - * 
   ;  /  / * ` 3 0   * 3 -   '   -   3  3  3 -   3  '  ,
      & A      >     0  0   *  '     3 -  / *  3  
0 * E    3 -    / *  3 - * \ / " - A  3 | * ~ " "  $ | + ~ Q
  3 0    3 -     3 -  &   I   A      *  3 -     3
 e -  3  *  3    " - A  3 0 *     0   '    '   >   
 '    / *  3    3 '         3  3  3 -   3  0 *  ,
-  * I  * 0   - *  *
_
 3 0    * 3 -   E 
_
0  '    0    3 ,
  ;    $ | n ~ Q ,       -  0 *  0    /   '   ,
-   *  3 -  0  3    -      - * 3   0  "     3
  I   *  '     3 -  / *  3   "        -  0  A   * 0 
 *  *    Q  * 3     3 -  &   * 3 - ]  '   - 
   - *  *
_
   ,
    3   '     3 -  -   I  ;    "  $ 0  I * 0  

  ]  -       ^   e -  3 0 * 0   3 -           *  
0  " - A  3 Q R e '  * /        /  3 - * 3   / * ` 3 " 0 
  0  I   >       0  "  $ Q
"  $ -   I  ;  /  3  -   "  3 0   3 * 3 -   '   - 
 e -  3 0 * 0   " - A  3 & " '   -  3 -  3   '    * - 
 - *  *
_
  -  0       ` 0     * 3  -    0   "   
 *     / ` 0 * :   *  '     3 -  0   Q   0  E  / -  &
"  $    ;  /  -   3   0   $  * 3 * / *   *
_
 3 ,
0   l  - * '    * 3 - ]  '   -   & /  0   3  /  3  / /    
   /    3 * /  0     0   $ " /  3  3 >     * 0  3 ,
- * \ /  - * >  0  '   /    Q    -    0  & -  0     
'   /      ;  /  -  3    *     /  * ' - '    '   0  3
512 Algoritmos y Técnicas de Programación Paralela
            
   



  
        
  
    "  #
$
%
&
  
'
  

) *

*
   ,   
     
!
" # " $ % ' ) + - / 0 " + " 3 ' "
5 / 3 5 ' + % $ $ / : 3 " 5 " 3 0 % 3 $ / ; 3 - " =
> ) = : + . 0 - " $ ) - ) C + : $ " 5 : D F ) " # " $ % $ / ; 3 " 5 ) 5 J 3 K
$ + : 3 ) ) P " 3 : 5 Q % " 5 " % ' / = / $ " 3 0 % 3 $ / : 3 " 5 - " 5 / 3 K
$ + : 3 /
R
) $ / ; 3 D T V W T . C % " - " % ' / = /
R
) + 5 " ' ) 3 ' : " 3
P : - : / 3 ' ] + C + " ' " _ 3 4 6 7 9 ; = > ? ` $ : P : " 3 P : - :
/ 3 ' " + ) $ ' / > : D
b 3 " = P : - : / 3 ' ] + C + " ' " d 5 " % ' / = /
R
) % 3 5 $ + / C '
Q % " " = / 3 ' ] + C + " ' " % 5 ) $ : P : j $ k " + : - " / 3 5 K
' + % $ $ / : 3 " 5 _ C : + " # " P C = : d
            
A B
     
" # " $ % ' ) " = / 3 ' ] + C + " ' " " 3 ' + " 5 C + : $ " K
5 : 5 $ : 3
A B
     
$ : P : j $ k " + : - " / 3 5 ' + % $ $ / : K
3 " 5 ` D T ) + ) / 3 / $ / ) + T V W T . " 3 P : - : / 3 ' " + ) $ ' / > : d
k " P : 5 - " " # " $ % ' ) + = : - " = P / 5 P : P : - : Q % " 5 "
" # " $ % ' ) % 3 ) ' ) + " ) " 3 C ) + ) = " = : V : x ' " 3 - + " P : 5
= ) + " 5 C % " 5 ' ) - " 5 / 5 ' " P ) ) = ) " 5 C " + ) - " $ : P ) 3 K
- : 5 T V ' k : 3 _
  
` ' ) = V $ : P : P % " 5 ' + ) = ) F / z % + )
{ D | : P : 5 " k ) P " 3 $ / : 3 ) - : ) 3 ' " + / : + P " 3 ' " d = : 5
C + : $ " 5 : 5 5 " " # " $ % ' ) 3 - " 0 : + P ) ) 5 J 3 $ + : 3 ) C : +
' ) 3 ' : = ) > ) = : + " 5 - " = : 5 / - " 3 ' / j $ ) - : + " 5 - " C + : K
$ " 5 : 5 C % " - " 3 P : 5 ' + ) + 5 " - " 5 : + - " 3 ) - : 5 D
G  I K M
€ 
N
‚ ƒ „ 
O N Q S U V
F ) | : = " $ $ / ; 3 † | ‡ ˆ ‰ Š ‹ " 5 % 3 $ : 3 # % 3 ' : - "
k " + + ) P / " 3 ' ) 5 5 : 0 ' W ) + " Q % " ) V % - ) ) / 3 > " 5 ' / K
z ) - : + " 5 V C + : z + ) P ) - : + " 5 ) - " 5 ) + + : = = ) + ) C = / K
$ ) $ / : 3 " 5 $ / " 3 ' J j $ ) 5 - " ) = ' ) 5 C + " 5 ' ) $ / : 3 " 5 D F )
| : = " $ $ / ; 3 † | ‡ ˆ " 5 % 3 C + : V " $ ' : Y C ) + ) z % ) 5 [
Q % " ) z + % C ) k " + + ) P / " 3 ' ) 5 Q % " 0 ) $ / = / ' ) 3 = ) / 3 ' " K
+ : C " + ) x / = / - ) - V 5 : 3 P ) V : + / ' ) + / ) P " 3 ' " = / x + " + J ) 5
_ ) = z % 3 ) 5 - " " = = ) 5 " 3 | d | ] ] : F : + ' + ) 3 ` Q % "
5 " k ) 3 - / 5 " a ) - : C ) + ) 5 " + " # " $ % ' ) - ) 5 " 3 $ : P K
C % ' ) - : + " 5 $ : 3 P " P : + / ) - / 5 ' + / x % / - ) D F ) C : + ' ) K
x / = / - ) - V " = + " 3 - / P / " 3 ' : 5 : 3 - : 5 0 ) $ ' : + " 5 P % V
/ P C : + ' ) 3 ' " 5 " 3 5 % - / 5 " a : D
” % " 5 ' + : ' + ) x ) # : $ : 3 5 / 5 ' " " 3 " 5 ' ) x = " $ " + % 3 ) $ ) K
C ) 5 % C " + / : + " 3 T V ' k
: 3 Q % " C " + P / ' ) = ) / 3 ' " + ) K
$ $ / ; 3 " 3 ' + " = ) 5 - / 5 ' / 3 ' ) 5 = / x + " + J ) 5 / 3 $ = % / - ) 5 " 3
= ) | : = " $ $ / ; 3 † | ‡ ˆ ) 5 J $ : P : % 3 ) $ $ " 5 : P – 5
$ ; P : - : ) = ) 5 P / 5 P ) 5 z + ) $ / ) 5 ) = ) 5 0 ) $ / = / - ) - " 5
Q % " C + : C : + $ / : 3 ) T V ' k : 3 D 0 " " 5 ' " P : - : d C + : K
C : + $ / : 3 ) + " P : 5 % 3 " 3 ' : + 3 : / 3 ' " + : C " + ) x = " - : 3 - "
- / 0 " + " 3 ' " 5 = / x + " + J ) 5 C % " - ) 3 5 " + % ' / = /
R
) - ) 5 " 3
" = P / 5 P : $ ; - / z : " / 3 ' " + $ ) P x / " 3 - ) ' : 5 - " % 3 )
0 : + P ) 5 " 3 $ / = = ) D | : 3 " 5 ' " C + : C ; 5 / ' : d - " j 3 / P : 5
% 3 3 % " > ) $ = ) 5 " - " : x # " ' : " 3 T V ' k : 3 c
 "    e
  f g h i
D j 3 ) / 3 5 ' ) 3 $ / ) - " % 3 ) P ) ' + /
R
T V † | ‡ ˆ
$ : 3 ' / " 3 " = ) 5 5 / z % / " 3 ' " 5 C + : C / " - ) - " 5 c
• k
 l
c j 3 " 3 ' " + : Q % " / - " 3 ' / j $ ) = ) = / x + " K
+ J ) † | ‡ ˆ % ' / = /
R
) - ) D b 5 ' ) C + : C / " - ) - 3 : 5
5 " + > / + – C ) + ) / - " 3 ' / j $ ) + " = 0 : + P ) ' : " 3 " =
Q % " 5 " " 3 $ % " 3 ' + ) 3 = : 5 - ) ' : 5 V 5 " + – ™ ' / = " 3
= ) $ : 3 > " + 5 / ; 3 - " = ) > ) + / ) x = " C ) + ) 5 % % ' / K
= /
R
) $ / ; 3 " 3 : ' + ) 5 = / x + " + J ) 5 † | ‡ ˆ D
• m n
A B
c ˆ " $ : + + " 5 C : 3 - " $ : 3 = ) P ) ' + /
R
- " 5 K
$ + / C ' : + ) - " = : 5 - ) ' : 5 " 3 = ) = / x + " + J ) 5 " K
= " $ $ / : 3 ) - ) D p " 3 " + ) = P " 3 ' " d = ) 5 = / x + " + J ) 5
% ' / = /
R
) 3 - " 5 $ + / C ' : + " 5 C ) + ) ) = P ) $ " 3 ) + = : 5
) ' + / x % ' : 5 z = : x ) = " 5 D
• m
"  "
c | : 3 ' / " 3 " % 3 : x # " ' : - " ' / C : ” % P " + / K
$ ) = † + + ) V _ P – 5 $ : P ™ 3 P " 3 ' " = = ) P ) - : ” % K
P ) + + ) V ` ‰ { ‹ D ” % P ) + + ) V " 5 % 3 $ : 3 # % 3 ' : - "
" › ' " 3 5 / : 3 " 5 - " T V ' k : 3 Q % " C " + P / ' " = ) P ) K
3 / C % = ) $ / ; 3 " j $ / " 3 ' " - " P ) ' + / $ " 5 D
| : 3 " = j 3 - " C + : C : + $ / : 3 ) + % 3 ) / 3 ' " + 0 )
R
/ 3 K
' % / ' / > ) d 5 " 3 $ / = = ) d V ) 5 % > "
R
d : 0 + " $ " + % 3 ) > ) K
+ / " - ) - - " 5 " + > / $ / : 5 $ : P C % ' ) $ / : 3 ) = " 5 d C + : C : + K
$ / : 3 ) P : 5 % 3 $ : 3 # % 3 ' : - " + % ' / 3 ) 5 Q % " C : - " P : 5
- / 0 " + " 3 $ / ) + " 3 c
• q s t u v x v z | ~  | v x z |
c % 3 $ : 3 # % 3 ' : - " + % ' / K
3 ) 5 T V † | ‡ ˆ Q % " C " + P / ' " 3 = ) $ + " ) $ / ; 3 d
= / x " + ) $ / ; 3 d - % C = / $ ) $ / ; 3 d ) $ ' % ) = /
R
) $ / ; 3 V
$ : 3 5 % = ' ) - " / 3 0 : + P ) $ / ; 3 - " = " 3 ' : + 3 : D
• q s t u v x v z | €  ‚
c + % ' / 3 ) 5 - " b 3 ' + ) K
- ) ƒ ˆ ) = / - ) - " - ) ' : 5 D
• „ s t v † x ‡ x v ˆ Š Œ u ‡ Ž v  ‡ x v ˆ Š
c ) z + % C ) = ) 5
+ % ' / 3 ) 5 Q % " C " + P / ' " 3 = ) > ) = / - ) $ / ; 3 - "
C ) + – P " ' + : 5 ) 3 ' " 5 - " 5 " + % ' / = /
R
) - : 5 " 3
3 / > " = " 5 / 3 0 " + / : + " 5 D
XVI Jornadas de Paralelismo, JP '2005 513

          
 
   
   




  


!
    &  ( 
) *
    +
,
 ( 
- .


/ 0     1
,
 (
/

 


/
!
 
- 4
/    




5


7 8
/ 

&
/ 

&   
* : ;

:
 <
*
 ,
7

4
/    

.
   >


 /

/        /

/
/    
)
     & /
:
    +
,
 (
*

   D      

/ 
 


 

7
 
;
D
:

 F
:
D
:
D
:



,
:
D < D

   D
,
 (  D
:
/ 5
,
 (
:
D J
! 
7 
 D
:
/ 5
! 
7 

   D
!
/  /  D
:
/ 5
!
/  /


!  L
  &
*
M
  

N
           

O
 " $
%
&
• P R R S R T U W T Y [ T \ [ ^ S ` T U
a ( ) + ( - . / 1 3 5 7 9
1 ; ( 7 ( = + ? ( ; A 3 = + . 3 ; D ; ? . ( ? ; 5 7 ( = + ? A 5 G = H (
; 3 ) ( . . 3 . ( ) 1 . 3 H / A 5 H 3 ) 1 3 . ; ? 5 = A 3 . . ( A + ?
/ + 5 ; 5
O
? A 5 G = H ( ; ? ) . / + 5 = ? ) T D V W Y Z [
• b S ` d T R U ^ f ` h T h j k S U
a 5 7 1 ; ( 7 ( = + ? ; ?
5 = + ( . 3 1 ( . ? ] 5 ; 5 H ? H ( = + . ( H 5 ` ( . ( = + ( ) ( ) + . / A 9
+ / . ? ) H ( H ? + 3 ) / + 5 ; 5
O
? H ? ) ( = ; ? ) ; 5 ] . ( . e ? )
V W Y Z [
f = ; ? m 5 - / . ? j k 7 3 ) + . ? 7 3 ) / = ( o ( 7 1 ; 3 H (
; ? 5 7 1 3 . + ? A 5 G = H ( ; 3 ) H ? + 3 ) H ( ) H ( / = ? 7 ? 9
+ . 5
O
t / 7 ? . . ? D ? / = ? 7 ? + . 5
O
T D V W Y Z [ f =
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55
56 57 58 59 60 61 62 63
00 01
10 11
Orden
Malla de datos
Malla de Procesos
M
  
w N
x
y  
o  z
{   |    y  | ~   

&   &
     

/ 
 


 

7
 
; p : p
<
,
 ( 
-
J
! 
7 

; - p
 
) ) p p
r
<
!
/  / 
; p
 s
)
r
p
- v
s s
r
-
r
- )
s w
r r y
-
s s z
r y
<
     

/ 
 


 

7
 
; - : p
<
,
 ( 
-
J
! 
7 

; - p
 
) ) p p
r
<
!
/  / 
; -
w
)
r r

y
w
-
z
)
y r
v
y
z
) p )

y
)
w
p ) - ) v
y
s w
-
<
     

/ 
 


 

7
 
; - : -
<
,
 ( 
-
J
! 
7 

; - p
 
) ) p p
r
<
!
/  / 
; -

)
w
y
p
y

- v )
z
y
-
y
v
) )
s
p
y r
w
) )
s s
-
y y
w s <
     

/ 
 


 

7
 
; p : -
<
,
 ( 
-
J
! 
7 

; - p
 
) ) p p
r
<
!
/  / 
; ) - p
s
r r
)
s
- -
s
y r
s
w
-
r
s 
r
w z
-
y
s
v
r
z <
M
   €
N 
| y  €     | € |  | z  z
{   | ~   

&   &
( ) + ( ( o ( 7 1 ; 3 k ( ; 1 . 3 A ( ) 3 A 3 =



/
!

-
ƒ - ( = ( 9
. ? ; 7 ( = + ( ( ; 1 . 3 A ( ) 3
; p : p
<
… A . ( ? / = ? 7 ? + . 5
O
H ( + 5 1 3 t / 7 ( . 5 A H ( + ? 7 ? ‚ 3
8 × 8
A 3 = ‡ ? ; 3 9
. ( ) 5 = A . ( 7 ( = + ? ; ( ) H ( ˆ ? ‰
Š
[ f ; . ( ) + 3 H ( 1 . 3 9
A ( ) 3 ) Œ / ( 5 = + ( . ‡ 5 ( = ( = 5 = 5 A 5 ? ; 5
O
? = ; ? ‡ ? . 5 ? ] ; (
/
A 3 = / = ‡ ? ; 3 . = / ; 3 ƒ
  

( = T D +  3 = … [ ‘ ?
. / + 5 = ?
/    
)
     & /
:
    +
,
 (
*
k H ( ‡ / ( ; ‡ (
( = A ? H ? 1 . 3 A ( ) 3 / = ? ‡ ? . 5 ? ] ; ( H ( + 5 1 3 T D 9
V W Y Z A 3 = ; 3 ) H ? + 3 ) H 5 ) + . 5 ] / 5 H 3 ) A 3 = ` 3 . 7 (
? / = ? H 5 ) + . 5 ] / A 5 G = A e A ; 5 A ? j ƒ [ Z 5 ( o ( A / + ? 7 3 )
( ) + ( ) A . 5 1 + ( = A / ? + . 3 1 . 3 A ( ) 3 ) ƒ „
  
  …  
r
 †  ‡  
/
)
5  ‰
… k ) ( . ( ? ; 5
O
? . e ? / = ? H 5 ) 9
+ . 5 ] / A 5 G = H ( ; 3 ) H ? + 3 ) . ( 1 . ( ) ( = + ? H ? ( = ; ? m 5 - / 9
. ?
Š
[ f = ; ? m 5 - / . ? š 7 3 ) + . ? 7 3 ) ( ; . ( ) / ; 9
+ ? H 3 H ( ( ) + ? ( o ( A / A 5 G = Π/ ( 5 7 1 . 5 7 ( ( ; A 3 = 9
+ ( = 5 H 3 H (
/
H ( A ? H ? / = 3 H ( ; 3 ) 1 . 3 A ( ) 3 ) [
f = ( ) + ( ( o ( 7 1 ; 3
  
 
? ) 5 - = ?
  
r
k D ( ;


!
   
( ) + ? ] ; ( A ( / = ? A 3 = œ - / . ? A 5 G = H ( ; ?
7 ? ; ; ? H (
2 × 2
1 . 3 A ( ) 3 ) [ Z 5 = ( 7 ] ? . - 3 k ( ;
? ) 1 ( A + 3 H ( ; ? 7 ? ; ; ? H ( A 3 = œ - / . ? A 5 G = 1 / ( H (
) ( . 7 3 H 5 œ A ? H 3 1 3 . ( ; / ) / ? . 5 3 ƒ 1 3 . ( o ( 7 1 ; 3 k


!
    &  ( 
) :
 
 F 
r
:
 


,

- *
A 3 = œ - / . ?
/ = ? 7 ? ; ; ? H ( 1 . 3 A ( ) 3 )
4 × 1
… [ ‘ ? 3 1 A 5 G = 1 3 .
H ( ` ( A + 3 3 ] + 5 ( = ( / = ? 7 ? ; ; ? A / ? H . ? H ? 3 A ? ) 5
A / ? H . ? H ? k A 3 = ( ; = ž 7 ( . 3 H ( 1 . 3 A ( ) 3 ) 7 Ÿ ) 1 . G 9
  5 7 3 1 3 ) 5 ] ; ( ?
 
[ V H ( 7 Ÿ ) k ) (  ? ( ) 1 ( A 5 œ A ? H 3
/ = + ? 7 ? ‚ 3 H ( ] ; 3 Œ / (
 ( 
)
H 5 ) + 5 = + 3 H ( ) / ‡ ? ; 3 .
1 3 . H ( ` ( A + 3 ƒ
 (  w
r
… 1 3 . ; 3 Œ / ( ; ? H 5 ) + . 5 ] / A 5 G =
) ( . ( ? ; 5
O
? ( = ] ; 3 Œ / ( ) H ( + ? 7 ? ‚ 3
2 × 2
[
514 Algoritmos y Técnicas de Programación Paralela

   
 
                      "  $ & 
(
)  $ 
 - -    $    $ 4 "    -  4         : $  $ ; 
     =     : $  $ ;        " @        )  $ 
) $  )  $ -    $ $ 4 "     -   4  -  -  D  4
 "      " $  : 4       @  :  "     @  I  : $ 
     = K        -   ) 4 "  -     -   "  
4         ) $  -     4         R
      S 4  -    ) $  -       -   4 
)  $ "        "        " $  -   X  - "  $  =
    : $  $ ;        -  4   $ 4 "   ; - $  
   X ;   $  -  ) -  D )  $  -   4  -  $ 4    R
" $ 
(
 4 :   " $ 
(
    4 ) $  -     " $  [ )  $ 
  & 4   $   " $  -    " $  ) $  -    )  $  -   R
- 4   $ X    $  I   :    =

       ! #  $   ' (

       ! *   , -   ! #  $   ' (
0
 #
2
# 4 # ' 6
7
4 $   8
9
4 $
:

;
9
    8
9
 
:

;
<
0
 #
2
# 4

 6
7
#
:
>
; ; ?
 < $ 4 B  6     8
9
 
:

;
7
#

    8 < <
F
> 4
2
 
:

;
< <
F G

  # # 4  > 4
0
?
I F 9
4 $   8 J
G

  K # 4  > 4
0
?
I F 9
4 $
:

;
J
G
#

# N <
F
> 4
2
K N <
F G
#
:
>
; ; ?
 <
0
?
 Q
R
2
6 #
:
>
; ; ?

9
#
9
K
7
$   8
9
$
:

;
< $
:
  
2
6 #
:
>
; ; ?

7
#

$   8 N < # > 4
2
$
:

;
N < K
G
$  # 4 ' W Y  #
2 ?
    N W
? ;
Z
?
G
0
?
Z
2
R
2
6 #
:
>
; ; ?

9 F 9 F 7
0
 #
2 ? [
# ' 6
7
\ _ ` a b d ^
_ e
f h i j k l a m h k k l c l b k o d p l q
e
r f g s u
v
w
    : $      $ 4 "          
      $       : $       : $  $ ; 
     =     :  $ I  [  4  $ 4 "       R
     [   -   "     )  -  } -  $   "  )   
   $ I 4   "  )        $ 4 "   ) 4  "  S 4 
         "  - "  4 "  )   $    
(
         
   $ 4 "   -  $ $  )     "  = K "  "  )   
  "     [   - 4  "    4 4  $     -  ‚      @
 -     4 4  = K   i  I 4 $  „ [   " $    4
- D   I       $    …   )   k      l  $   m  -  4  R
       " $  : 4 -  D  " @   $         
† o o o q s t v w x z q { | ~  z w €  ‚  ƒ „ … † ˆ  Š ‹ € Œ
w t ‚ q  v Œ w ‡ =
K  - D   I   $  I     i  $ " $   - 4 )    $    R
  $   4    "   ;      " $ 4 - -    =
  $  " $      [       & 4 -        
  
  )     "    -         
‹  -    "  Œ   ;   = K  "   …   R
)   [   ) $  -  
I F 9 F
J
$  -  :       "  } R
-    $   -    ) $  -  
I
#
9
K J
        
†
#
:
>
; ; ?
 <
0
?
 Q
R
2
6 #
:
>
; ; ?

9
#
9
K
7
‡  -   - 4  
  -   $          ) $  -    )  $ "  $   4
   "  } -    $ †
$   8
9
$
:

;
< $
:
  
2
6 #
:
>
; ; ?

7
‡ =
  $  X  $  } -  $ 4  -  $ $  - "  -  } I 4 $  -  D  
           -   -    $   -   $     
-   - 4     -    4 "   
(
      $  -  ) -  D
      "  } -    $ =
0
10
20
30
40
50
1024 2048 8192 4096 8192 16384 32768 65536 131072
Size (bytes)
Bandwidth
(Mbytes/sec.) BLACS
PyBLACS
\ _ ` a b d 
_
f g s u
v  e
r f g s u
v
h q
v
h d  l b ` w
0
5
10
15
20
25
30
35
40
45
50
1024 2048 4096 8192 16384 32768 65536 131072
Size (bytes)
Bandwidth
(Mbytes/sec.)
BLACS
PyBLACS
\ _ ` a b d
• _
f g s u
v  e
r f g s u
v
h q h k u k a – — h b w
  $  -   ) $  :  $    } -   -            [
      )     "    X  $   ) $ 4  :  S 4   
-   )  $  -      : $  $ ;         
 "      &  $  "  = ‘     "   4 ’  ›
   “  œ œ œ [           :  $ I [   -   
(
  
    ” • –  ”    ™     ™  ™ ”  š ›  š ™  •  š
– œ " $ •   ™  • ™     $      [ ‘   =    :  $ I
 4 -   ) 4 "    $ -      $     " $  : 4   
XVI Jornadas de Paralelismo, JP '2005 515
   

                       "  # 
%   '  #    "   
)
         "   
   0    
     "        "   6   "   # 8  :  
)
   "       #      "      #  "    
    0  "  " '     " 
C  
   0       
)
          "        
        J L         N   #    "       ' 
  0      0 "     
     U     "   "  #    
  #     Y   N  #
          '    0    
 "   
)
         "     ^ C ` b c J      "   U   
6 J ^ C ` b c  6   
      "  #     
i      
  "        
  6 J ^ C ` b c N '  #       
)
  
 
  

       "    J 6 J " '    C  
#  "       "  #        #   "         p q   J
   0    
 "    #   " 
     "  #       ' 
  0     
6    #   p   %       '    0      0 "     
 "   
)
         "     ^ C ` b c     U   # 
        s
     #     "    t         #   " 
 
        0 "       "   
)
    6 J ^ C ` b c 
  "      0     %        "   U      6 J " '  
    
)
   #
  0         "    
      
    #   "        v "         s  0 Y  "    # x

  "       b N b     "    t z { : |    "    

#     N   " 
i             #    "    p 
 #
           #  Y       " i  #      

    "  p     N 
   0       J U         
   
        
6 J 6 ^ C ` c
 
              
6 J " '         "               6 ^ C ` c
z {  |  6 ^ C ` c       Y   "      "     ^ C ` c
 
       z
‚
|  C     0    q   ^ C ` c    
 
  "         "       
   
       
0 ƒ       "   p  "     J #  "      C   ^ C ` c
    p   {     
)
  
          "   p  "     N
       p   :  #
  #   "   
          "  
#  "     J p  "     J
  „  "  #       "    
^ C ` c     p  
‚
    
)
  
          "  
#  "      C     0    q   ^ C ` c J 6 ^ C ` c   
 †    "   N
  "  0    N J  #
   #   "   "   
)
   
                  U "       ƒ    0        
    "        
         
N '  #       "   
     # 
%   '             "        p  
‚
s
! #
$
%
& &
t 
b  #
        "  ‰        
     # 
(
) * & - . / 1 3 4 6 & ! * ) 9 :
(
) * & - . / 1 3 4 < - . - > ? / 4 6 & ! * ) 9 :
6 & ! * ) 9 9 6 &
%
C D
E
F F
/ 1 3 4 G
H
6 J D
K L
4
M
N ? / - / 1 O
H
6 J ) N ) .
- . / 1 3 4 <
$
) 6
Q
6 C 6 9 T
U L
6 C 6 9 6 N
H
6 W
%
$
) 6
Q
L
M
* C #
%
) 9
Y M
N
H
N ) 9 * - . / 1 3 4
Y M
N
H
N )
N
H
!
\
N D 4
M
N
H
]
- . / 1 3 4 T
] ^
/ 1 3 4 G
H
6 J
U
J
%
9 N D 4
M
N
H
]
- . / 1 3 4 T `
^
/ 1 3 4 G
H
6 J
U
L
$
%
C
%
) N 9
%
) N C
Q
* & - . / 1 3 4 N ) ) N .
N D  N C
Q
]
- . / 1 3 4 T C
^
C
^
/ 1 3 4 G
H
6 J
U
J D  N C
Q
]
- . / 1 3 4 T C
^
C
^
/ 1 3 4 G
H
6 J
U
M
D  N C
Q
]
- . / 1 3 4 T C
^
C
^
/ 1 3 4 G
H
6 J
U
L
M
N
H H H %
#
% H
` - > ? / 4 ) * b 9 6 C
%
M
D ! #
$
%
& & T N
H
!
\
N
^
N
^
J
^
J
%
9 N
^
M
U
$
) 6
Q % d
6 9 T
U
e ‹ Œ  Ž  
f 
‘ “ ” • – — ˜ “
g
™
g
h i š
› f      
œ
  ƒ          "    s p       Y  #
   6 ^ C ` c
k k k m o p r s t v m w x y z { | } s }  } |  z p  } €  s p { z  v s } { m r y  t N
   #
  Y               0   #   "    x
U           "   Y  #
  N          "   
#  "     6 J ` b  c     "      s
N
^
J
^
M
t
#      " 
 N C
Q
]
- . / 1 3 4
   ƒ        x
  
)
  N
c = alpha · a · b + beta · c
N  
 U  " „  #      "       #    6 J 6 ^ C ` c N
M
D ! #
$
%
& & T N
H
!
\
N
^
N
^
J
^
J
%
9 N
^
M
U
     "   Y  # x

  N          ‰         "       "       
    
)
     #   "  N     # 0     #      "   
 "   
)
  ‰   
 b &
]
- . / 1 3 4
     "      
#  "  
)
     "   0  J     "     
         
#     J     #           #  "     6 J ` b  c
    U   #  "        
       "   
)
  
 
     "                  6 J ` b  c  `   # ƒ  N
 "   
)
 #       "   
! #
$
%
& &
          
" 
     "         # 0         "     6  
    "      N      "     6 ^ C ` c s       
%        "     ^ C ` b c t "          # 0  
 
      "     " 
 N          "   
# !
 
   "  "  J 
   "     U    ‰     " 
     "  
 "   
)
   s c N  N b J # t z {  |      0  "   "  N "  
J  #     #   " ‰     c   ‰  8 N     
  "   U     6 J " '                
  †  
  " 
     "  
  %      #  "        #     J
    J     "    U   #   ‰  %      ƒ  "   
)
  

        
      "    "      6 J 6 ^ C ` c 
6         p   N '  #    #
      
516 Algoritmos y Técnicas de Programación Paralela
0,0
0,2
0,4
0,6
0,8
Tamaño del vector
Segundos
PyPBLAS 2x2 0,037 0,063 0,092 0,183 0,421 0,907
PBLAS 2x2 0,009 0,042 0,090 0,166 0,423
PyPBLAS 3x2 0,098 0,029 0,057 0,112 0,290 0,521
PBLAS 3x2 0,007 0,031 0,062 0,116 0,276 0,588
1000000 5000000 10000000 20000000 50000000 100000000

  





 


  
 
        
0,0
0,5
1,0
1,5
2,0
2,5
3,0
Tamaño Matriz/vector
Segundos
PyPBLAS 2x2 0,22 0,48 0,84 1,30 1,89 2,56
PBLAS 2x2 0,24 0,50 0,90 1,20 1,38 1,53
PyPBLAS 3x2 0,12 0,22 0,36 0,56 0,78 1,09
PBLAS 3x2 0,09 0,20 0,35 0,42 0,78 1,06
4000 6000 8000 10000 12000 14000

  
 



 


 
 
        
" # % ' ) + ) # % . / ' # 3 4 6 8 : < 3 < 3 4 6 8 : ? : # B D %
" # D F )
H
D ' / # L M # " ) + # % . / P Q / % ' ) S # " # % . # P . D + D
/ P
' # W # Q . / " # P < + D . " ) Q # P < ' ) S # " # % . # % [ + # " / ' #
M " / Q # P / P \ ^ M " / Q # P / P # % ` % D + D F F D
2 × 2
a / b
M " / Q # P / P # % ` % D + D F F D
3 × 2
d ? f % F D P  ) h ` " D P
' #  D k l + / P . " D + / P F / P . ) # + M / P ' # # o # Q ` p
Q ) q % # % F D " # P / F ` Q ) q % ' # 3  8  3  \ % ) W # F k 
x + αy, α ∈ R, x, y ∈ Rn d a 3   f  \ % ) W # F
l 
αxyt
+ A, α ∈ R, x, y ∈ Rn
, A ∈ Rn×n d
< 3   f y y \ % ) W # F
z

αAB + βC, α, β ∈
R, A, B, C ∈ Rn×nd ? 6 / P ' D . / P ' # # % . " D ' D ` . ) p
F )
H
D ' / P B D % P ) ' / + D . " ) Q # P < W # Q . / " # P D F # D . / " ) / P ?
f % F D P  ) h ` " D P  < k | a + / P . " D + / P F / P . ) # + M / P
' # # o # Q ` Q ) q % /  . # % ) ' / P # % # F Q F ` P . # " M D " D F D P
" ` . ) % D P ' # % ) W # F k < l " # P M # Q . ) W D + # % . # ? 3 D " D # P p
. / P % ) W # F # P a F / P . ) # + M / P ' # 3 < 3 4 6 8 : P / % F ) h # p
" D + # % . # P ` M # " ) / " # P D F / P . ) # + M / P ' # F D P " ` . ) % D P
3 4 6 8 : ? : ) % # +  D " h / a M D " D . D + D
/ P # F # W D ' / P
' # ' D . / P B # + / P M / ' ) ' / # o # Q ` . D " / M # " D Q ) / % # P
0
2000
4000
6000
8000
10000
12000
14000
16000
Tamaño Matrices
Segundos
PyPBLAS 2x2 76,0 608,3 2038,7 4812,6 9149,1 15890,7
PBLAS 2x2 76,0 610,2 2043,3 4805,9
PyPBLAS 3x2 51,3 403,1 1360,0 3236,3 6319,4 10826,5
PBLAS 3x2 51,0 404,0 1367,2 3241,1 6310,4
2000 4000 6000 8000 10000 12000

  
 



 
„

 

… …

        
0
200
400
600
800
1000
1200
1400
Tamaño Matrices
Segundos
PyPBLAS 2x2 6,140 51,526 172,333 385,544 760,118 1314,502
PBLAS 2x2 6,310 51,336
PyPBLAS 3x2 4,693 34,191 116,347 275,947 544,187 945,903
PBLAS 3x2 4,295 33,937 115,630
2000 4000 6000 8000 10000 12000

  
 



 
„

 

… …
†
  ‡    
Q / % + D . " ) Q # P < W # Q . / " # P ' # . D + D
/ P P ` M # " ) / p
" # P # % 3 < . B / % ‹ ` # # % # F M " / h " D + D  / " . " D % ?
f P . # B # Q B / P # /  P # " W D Q F D " D + # % . # # % F D " ` . ) p
% D ' # % ) W # F
z
M " /  D ' D # % D +  D P M F D . D S / " + D P a
. D F < Q / + / P # + ` # P . " D # % F D P  ) h ` " D P k k < k l ?
8 ' # +  P a M / ' # + / P D M " # Q ) D " ‹ ` # # F " # % ' ) + ) # % . /
' # 3 4 6 8 : < 3 < 3 4 6 8 : # P P ) + ) F D " < M / " . D % p
. / a F D M # % D F )
H
D Q ) q % M / " ` . ) F )
H
D " F D P ) % . # " S D Q # P ' #
3 < . B / % # P ) % D M " # Q ) D  F # ?
  
 ‘ ’

“ ” •  ‘ – ”
8 Q . ` D F + # % . # a F / P F # % h ` D o # P ) % . # " M " # . D ' / P # P p
.  % h D % D % ' / D ' # M . / P ' # % . " / ' # F D Q / + ` % ) ' D '
' # Q ) # % Q ) D P Q / + M ` . D Q ) / % D F # P a # % M D " . # M / " # F
D ` + # % . / # % F D Q / + M F # o ) ' D ' ' # F / P Q q ' ) h / P D Q p
. ` D F # P a F / P " # Q ` " P / P Q / + M ` . D Q ) / % D F # P F ) + ) . D ' / P a
# F W / F ` + # % # F # W D ' / ' # ' D . / P < F D # o # Q ` Q ) q % ' #
XVI Jornadas de Paralelismo, JP '2005 517
                        !       " $
      (              +  !            .
    0                        4  5     
   0           (           !       .
+            !        +  !        5 
@         !   B !
   C   +         "
F   !   !   G                L C $ N O Q
+     !          !          !        +  .
        +  !       " L C $ N O Q +   +         U
     !   B 
W
   !    0    @         .
!   B !
      !   +   U    " ]       !   4 .
!           G U    +     !      !   
 B               +        0  @         .
!      !   B 
W
L C $ N O Q " O   G  c  @   
  !      0   !      L C $ N O Q     .
  !           +       !   B    L C .
j ] $ N Q C L C L j ] $ Q o   +    G       

            q C @       +   G    
    
W
   r       +  s       !    
 +           " ]  +    G     
W
    
 Q        u C w    !    (      + 
  L C ! @     +   +           @         ! 
       +          r       +    
W
   r 
        G  "
z     !   B  !    !   G    5  G           0 
 G    4   !  
W
 G       !   G    r  L C $ N O Q
!       Q   ] $ L $ N |   G    4         
  !  " L    !      5  !        !    G   !  0 
  U                     r      + !   
W
 .
  " z !              r     +        U   
                   !      $ N O Q 5
    +   U   !   r + !    G         .
             L C $ N O Q "
} ~  ~  ~ €  ‚  ƒ
„ … † $  @   5  " 5   G   5 L "  " 5      5 | " 5
       5  " 5  + @   ! 5 O " 5   ! #   % ' 
  ) + -  " O   @       +   ! . N  ] . Š $ .
… ‹ 0 w Œ 1 " ] 
     ]  0       F  !     ]  G .
   !   C 5 ]  0       o ‹ Ž Ž … q "
„ ‹ † j   2 B    5 ] " Q " 5 N @   5  " 5 N    C 5 $ " 5

!
$
W
 0    5 z " 5      5  " 6 " 5  @    5
7 " 5         5  "  " 5          5 Q " 5    .
 C 5 < " 5 L  !  !  ! 5 $ " 5 Q !    C 5 | " 5 6  2   5
 " 5 6 @   C 5  " N " 5 # % ' % '  '
* , .
/ #  1 /
2
  B # " Q 7 $ Š " L @     + @   5 L $ o … 1 1 ‘ q "
„
’
† j   2 B    5 ] " Q " 5      5  " 5         5  " 5
  5 7 " 5          5 Q " 5     C 5 < " 5      “ 5
Š " 5 |   B    5 ] " 5 ]        5 $ " 5 L  !  !  ! 5
$ " 5 L 
W
 5  " 5       !   5 | " 5 6 @   C 5  "
N "
5 '   6 B ' ) # B / # ) - 9 : ' /  % %   # '  '  ? # I  '
#  I  -  )   # / C : % ' # E " $ N Š O    " Š  ! @ "
Q  B ! " ‹ 0 o ‹ q o ‹ Ž Ž ‹ q …
’
w G … w … "
„ u †         5  " 5   . ]        5 Q " 5 ! !  5 Q " 5
Q    5 Š " 5 6  2  5  " 5 H  K L N + # % - ! 6  # ) #
 # 9 #  #  % # " O @  Š 7 O L   " N   G      5 Š $
o … 1 1 0 q "
„ w †         5  " 5 6 @   C 5  " N " 5 : ' /  % %   Q
# '  '  ? # I  '
*
- ! !    % ' )  -  #  I 6  - ?  ' ! /
C : % '
*
# E " @ ! ! + R S S


"   !  G "    S G  
„ Œ †         5 ] " $ " 5        
W
5 V " 5 Š   .
(   5 " 5      5  " z " 5 V    5 V " 5 '
# )  B  - 9 X - I  / ) # %  #  )  Y % %  I  '   # / 9 -  ) + #
' B Z '  % # ! #  ) - 9 # %  #  % # / '  B ]  ?   # #  Q
  ? " L           B ! @  Π! @ 7  !     !    
N   B            @ L   B        N   +  ! .
   B   N   +  !  !     Q       " V       5
Q +    o ‹ Ž Ž u q "
„ ‘ †         5 ] " $ " 5 Š   (   5
" 5 N + # '
*
N #
*
-   # % )  -  X - Q
I  / ) '  B _  ? + Q  #  9 -  ! '  % #
N - -  / 9 -  # %  #  )  Y %
*
- ! 6  )   ? "
@ ! ! + R S S   ! "     "   0 S        ! S ] j F ] .
L . j .
’
… ‘ w " +  B
„ 0 †      5 | " 5 # %  #  )  Y %   ) + - 
.
/ #  1 /
2
  B # "
N   !     j   + @ C  (   Š         N F  Q "
<     G  5       o ‹ Ž Ž ‹ q "
„ 1 † Š    5 L " 5   H  K Q '    )  - B  % Q
)  -  ) - 6 '  '   #    ) + -   /   ? H  K 5
@ ! ! + R S S      B     "   ! S +      ! S + C  + 
„ … Ž †  ] N % K : L  '  '   #  : ' /  % %   Q
# '  '  ? # I  ' #  I  -  )   # / C  : % ' # E 5



"   !  G "    S    +   2 S + G  l (   B " @ ! 
„ … … † 0       5 < " 5    2  5  " ] " 5   " 5 '  K  Q
)  - B  % )  -  ) -   ) + -  " F  !
  2 O @    C ] ! 
o ‹ Ž Ž
’
q "
„ … ‹ † 0       5 < " 5    2  5  " ] " 5   " 5 ] q Q
) #  B   ? '  B ] ! I # B B   ? ) + #   ) + -  K  ) #  Q
6  # ) #  " F  !
  2 O @    C ] !  o ‹ Ž Ž
’
q "
518 Algoritmos y Técnicas de Programación Paralela





   




 
 




  
  

  
   




   


   
  

 !"#   $
%

&'' '&''



 

       

    


  
 
  
   
      
     

      
 

 
 
   
 
 

   
  

      
   
   

   
 
  
   
   
  !  
  " #
 # $
  

   

  
 

   
  


# 
    


  %
 



 
     
  

     &       

 
  
 
 '  

#
  $   # %

 (   


 
 
 
 

  



   
   
 
 
     
 
 
        

  
 
  ) 
 
 

     
 

    
 

    

   
*

  


   
   
 
  
   
 

  
  &   
 

  +    
  
 


  

   


  
  

 
,       

 

         -

        
   . /    
 

 
 
  
  


   
 



0     

 
    $   


 
   



        

  
 
 
1 




    
   
   
-   
 
 . 2345  , -  ,
  
  
. 265


 
    
#

    275 &# -( 0 
   1     

. 285  #&* -# 

 &   
 '  
. 295
   
  #      
 

   
   
 
 
    
:


 
& 


 
    
  
   

   


  
     
      

  

 

    
 

  



  

 
 
  
 
 

   




      



      !
"  !

#
 



   

  
   
 



 $



 


   %
  

 



 
 
  
    & 

 




 
  '( )
 
   
 

 

 
   
 


  
 
 
 
 


   
  
 


 
 
  
  



  

 



 
 
 

  

 
 *

 +
 

   
  

 
 
 





 

 
,
,    
 



   
   


 
-
 
   
 
   
  
   

 


      





  
-   %
  
 
 %
  
  


  -

- , 
 
 
 

 
  
 
 
 
 
  
  
 

 

 
  

 ,

,  





 
   

   
  

 



 
 
 . 

  


   
    

 

 

 





  
   
,
,  

 
 

 
 
  
 "
 
# 

    

   
  %

  
 
 
 
 



"   
#  

 
  
 
 
 
$ 

 
  

 
  
 
 
  
  

 /  
 $
 

  

 

 

 
 
+
 
  
 


  

 
 '( )
  

    +  0 &  

 N  
 
  

   
  
 C 1 
   
+

pi   
wi 
 
  
 

  
 
 

 
 

 C  

 
+
   

 
 

 
 
   


    
   ! "#    ! "#
$
  
  
%   

   

&

 ''
  

()
 
 * () 
 * ()
$ **
$
  
 +, 
 
 ,+


 
% 

 
   
** 
 * () 
 * ()
$

 - 
%
.   () 
  ()
$


 
%''

%
/
  
 +,   
 ,+
 
  
 *

(),
 +()
$ $



 


 

    

  +
 &

 ( . 
   


 

 
 
  

   + 
   
520 Algoritmos y Técnicas de Programación Paralela



  
 
    
   
  


 

 

 

 






 



 

 

   

   
  
   !
 " #

 $   
 !
 
 !%  !%
 ! 
  ! 


 
  !% & ' !
(

 ) * 
  ! 
" ' !
(
 !
 
 !% 
 ! 
 

 
+ + +



 
   

 





 

 
 
  
 



 

 
 
 ,
 

- . /

 
 -
0 1
 
 

-
/ 
 2.2/


- $ . 
- .


- $ / 
 
+


-
+

 
 
   
 
  

 

  
 

 



    
   !


 " 



   
  #
    

 
 


 $  



 

 

 
  

  



 $

  
 
  



 

 
%
 



 !

 

   


   
 $ 
 

 
% 

 $   
" !

  
 

 


  
 

  

  

 $
 
 3   44 3  
 
-
5

 !
 *
 !% 6
 ! 
 *

 
 ,


7
- -7 
 #
+

 
 
   
 
 
 & 
   



  
 


 

 '  
  






 $  
  


  
 

 


 
 ( 
 $
 &))

  

  &)) 


%
 $ 
   *

   
 
 
   

  



 
  
 
+
   
 




 
   
 ,
   
-    
 


  
     






 


  

  $ 
   


*
• 
 * .    

  
  
  
 

 

 

 

 


 
 
 
   
• 
 * .    

 
  
  
 
XVI Jornadas de Paralelismo, JP '2005 521


   
      
  
       
  

•
  
   
   
  
   

     
 
 
    
   


        

      
 

   
   
  
  
      



 
 



 


  

 

   

 
 

  

    


 

  



  
  

 !     
 !   

" 
 ! 
#
  
$  >  


 ! 

#
 
$ 
 >  
 
 
 ! 
 
 ! 
%
$  ! = 


   
% %


 

%



  
  



   
   

     
 

  
  
 
  
      

 

    
 
  

 
• ! 
  
    

  
   "  

   
    
 
   

  
 

 

 

     

  
   
• #
 
    

  
 $     

  %




 

 
   &     


'  ( 

 !  
 #
 )( * +, 
      

 
    
    


  
  
  

 
   
   

!   
 
   
522 Algoritmos y Técnicas de Programación Paralela

  
        
 
          
         

        
         
           
          
   
     
        
 
     
    
    
    
         
         

 
       
          
    
    
        
           
! 
  
      
  
         
       
 
  ! 
    
            
         
          
         
  
 

        


       
    "#$
  
     %     
  
    
         
  

    &     
       
    
'  ( 
         
       )  
             
  
     
        

        
       )  
        
 
          

        
   
    
 

      
           
  

  



 




 
 


          

* +,-       

  ".$     
 / /    
          
     / / 
       0   
   011 !   !2 

XVI Jornadas de Paralelismo, JP '2005 523

 

     
 


• 
 

  
 



 
  !"# !$
$ 


 % & !"# !$
$ 


   !"# !$'(
)$ 


 ( ! *   *

 ) + *  
 
, 
-



  


  
  +  . . /
 *-
• 01! .23(& 401! . 
5 )&%
 6   0  2   07 )
+"# 8 '1 
 && +1  *

  - 1 
 
,-



 
 096-


  
 
 



 
*
 
$  . 

--8: 4
  ;5
   <<

 +9/  
 ---) 


 
 
8-- -

 

 
 .23(& 

  
 << 
     
 

 !0"+! 
  !0 4* 
  !05-

  

  
 
   




  




 
 
  
 <<   



 
    - =

)  % 

 
  

  

  
 
   





 >
#

 ,

,   


?  
@


 
   
#
 
A8&--:8( B-
 
  
*

 

    

-

?
 
      
0003( !
# 
( !  *-
= 



   



,
,   

     C


  

    
 
 -
 


  


.23(&    <<   


 - 
   
 
  

  
<<
, 
 

D


   
 
-



, 

 
    

* 

 1
1 


   

-
 



  

, 

 
  <<-


  


  

#-





  
* 
 
 
  
   #   
-

, 

 
? 
   


   
 > - 
 


    C 4EE5 

524 Algoritmos y Técnicas de Programación Paralela

  

    
 


   
   

  
       
        
           
         
 
     
           
          

         
     
    
     !  
"  

    

# 

 ! $
 

          
    

  
 



#         
 %&#  " #%'('))*+',', -
        . 
  /  %  
    012 34
 .
  /  3 1
 
 1 " 51.6/1 7/%%8#(''8
,'2'9*: -        
%.; #    
    
  

<=> ?  % @A  / B
C  
/ "  


  



  



 




     %
 
A    (,
)D=8 ('')
<(> ?  % @A  / B
C   / 
"   
 

  ! 



" 
 
# 
#
$


 1 
  .  .
     1   ? 
  E  F  1  

%...   4  
 (*(D(*+
(''8
<8> ?  % @A  / B
C   / 
"   % 
&'
 '


  ! # 
#


  
  1   
 .  
=8  =+,=*( ('')
<)> .  ! 1      5
-. %"&(  & )
&


*

+ ! 
 #  
#
 /
  /  /  ('''
<,> @ F  /    # (
#  

',   %
%E0/;4 %  0  /  ;

 4 =**,
<2> ;  4  #  1 - '  

 . 
"'
 %'


  !  -  G 4  @ =**'
<9> ; 
 1 
% 0  %( 

.
' .  
!


 %
  !   4 
 
    5
 1   

 +
8D) =**)
<+> /   #H  @I @
/0&1/(  
 *

+ ! # 2 " 



JJ 
J4&;15
E& ('''
<*> 4  & 5
 ;  5 
/  3

,

4 ! 

#  
#
. 1  
XVI Jornadas de Paralelismo, JP '2005 525

   
 
  
      

       !"#$
$%
&$#' ( 
)* %  + (%

 
 
  , 

 (
  -# ,-

.  / 
011222%-
%1 - $%
526 Algoritmos y Técnicas de Programación Paralela
   
     
    
  
 $  '  )  *  +  .   1 )  * 
5 7 8 9 ; < > @ A B D A E G H I 9 8 ; < L ; > N B P A < Q 9 G T 9 8 < A B V > 8 E D B A E
W X Y [ ] _ ` X a c d ` X g h a i j ] l ] m o [ p Y r X a h g s t
u t g v x y ` g c a c c x z a z a } r t a
z a z a } r t a
x ~ p a g €  g } t a h g [ Y Y „ } p a g € ] h [ p i † ‡ a € p x g c a i c } [ t p [ y ˆ „ r € € ] x `
‰ ‹ Œ  Ž ‹ 
 ‘ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ™ ‘ ¤ ¥ ¦ ž ‘ § ¨ ™ ž › ™ ‘ ‘ © ª
• ” “ « § — › ™ ‘ ¦ ¥ ‘ ¬ ‘ ­ ‘ “ ‘ “ ¤ ¥ ” © ® ¤ “ ¦ ž ‘ • “ ‘ ž ® ‘ “ ª
› ¤ ¬ ‘ ¬ ¬ ¤ ­ “ ” ± © ¤ — ‘ ¥ ¬ ¤ ” ­ § › — › ² ‘ ™ ›  ž ³  ” ¥ ­ “ ” ª
• “ ‘ — ‘ ¥ ¬ ¤ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ™ ‘ • ¤ ž ¤ “ ‘ © ª
— ¤ ž § ¤ ¥ ¤ ¬ › ¥ ¤ ¶ ‘ ž ™ ” — ” ‘ ­ © › ™ ‘ ™ › ” ž ¤ ¥ › ž ¬ › ® › ¬ ª
¦ ‘ © ¤ ¥ ¹ º © ‘ ¥ » ¤ “ “ ‘ — › ¤ ž § ‘ ¥ ¥ ” ¼ § ¾ ‘ “ ¤ ¤ ¥ § ¢ ž ‘ ¬ ‘ ­ ª
§ ‘ ¬ ‘ ¥ ‘ ¤ ™ ¦ ‘ ™ › ” ž ¤ ¥ ¹ — ¤ § ” ¬ ” © ” • « ‘ ¥ ¤ ¥ ­ ¤ ™ « ¿ ™ ‘ ¥ ³
À ¥ § ” ™ ” ž § “ ‘ ¥ § ‘ ™ ” ž ” § “ ‘ ¥ § ¨ ™ ž › ™ ‘ ¥ ‘ © • ” “ « § — › ™ ‘ ¥ º
¬ ” ž ¬ ¤ ¦ ž ­ “ ” • “ ‘ — ‘ • ¤ ž ¨ “ › ™ ” ¤ ¥ ™ ‘ ­ ‘ ² ¬ ¤ “ ¤ ª
¥ ” © ® ¤ “ § ” ¬ ‘ ¥ © ‘ ¥ › ž ¥ § ‘ ž ™ › ‘ ¥ ³ Ä ¤ — ” ¥ ¬ ¤ ¥ ‘ “ “ ” © © ‘ ª
¬ ” ¦ ž ‘ » ¤ “ “ ‘ — › ¤ ž § ‘ • ¤ ž ¨ “ › ™ ‘ Å ¦ ¤ ­ “ ” ­ ” “ ™ › ” ž ‘
¥ ” ­ ” “ § ¤ ‘ ¦ ž ‘ ‘ — ­ © › ‘ • ‘ — ‘ ¬ ¤ — ¤ § ” ¬ ” © ” • « ‘ ¥
¬ ¤ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ™ ‘ ± ‘ È ” ¬ › ¼ ¤ “ ¤ ž § ¤ ¥
­ ‘ “ ‘ ¬ › • — ‘ ¥ ­ ‘ “ ‘ © ¤ © ” ¥ ³  ‘ • ¤ ž ¤ “ ‘ © › ¬ ‘ ¬ º É ¤ Ê › ± › © ª
› ¬ ‘ ¬ ¹ ¤ ¿ ™ › ¤ ž ™ › ‘ ¥ ” ž ‘ ¥ ­ ¤ ™ § ” ¥ ± ¢ ¥ › ™ ” ¥ ¤ ž ¤ © ¬ › ¥ ª
¤ ¶ ” ¬ ¤ © ‘ » ¤ “ “ ‘ — › ¤ ž § ‘ ³ À © ­ ‘ “ ‘ © ¤ © › ¥ — ” ¥ ¤ ­ “ ” ª
­ ” “ ™ › ” ž ‘ ‘ © ¦ ¥ ¦ ‘ “ › ” ¬ ¤ ¦ ž ‘ ¼ ” “ — ‘ § “ ‘ ž ¥ ­ ‘ “ ¤ ž § ¤
‘ § “ ‘ ® ¨ ¥ ¬ ¤ ¦ ž ‘ › ž § ¤ “ ¼ ‘ ² ¥ ¤ ™ ¦ ¤ ž ™ › ‘ © ³ Í ž ™ ” ž È ¦ ž ª
§ ” “ ¤ ­ “ ¤ ¥ ¤ ž § ‘ § › ® ” ¬ ¤ ¬ › ¼ ¤ “ ¤ ž § ¤ ¥ § › ­ ” ¥ ¬ ¤ ­ “ ” ± ª
© ¤ — ‘ ¥ ¬ ¤ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ™ ‘ ž ” ¥ » ‘ ­ ¤ “ ª
— › § › ¬ ” ® ‘ © › ¬ ‘ “ ž ¦ ¤ ¥ § “ ‘ » ¤ “ “ ‘ — › ¤ ž § ‘ ¥ ” ± “ ¤ ¦ ž ‘
Ï Ð Ñ Ó ’ ³
Ô Õ ×
 Ø Ù Ú Û  Ü Ü Ý Þ 
 ‘ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ™ ‘ ß ’   á ¤ ¥ ¦ ž ‘ › — ª
­ ” “ § ‘ ž § ¤ § ¨ ™ ž › ™ ‘ ‘ © • ” “ « § — › ™ ‘ ‘ — ­ © › ‘ — ¤ ž § ¤ ¦ ¥ ª
‘ ¬ ‘ ¤ ž ¬ › ® ¤ “ ¥ ” ¥ ™ ‘ — ­ ” ¥ º § ‘ © ¤ ¥ ™ ” — ” § ¤ ” “ « ‘ ¬ ¤
™ ” ž § “ ” © º › ž ® ¤ ¥ § › • ‘ ™ ›  ž ” ­ ¤ “ ‘ § › ® ‘ º ± › ” © ” • « ‘ ¤ › ž ª
¼ ” “ — ¢ § › ™ ‘ ³ ⠔ ¥ ­ © ‘ ž § ¤ ‘ — ” ¥ ™ ” — ” ” ± È ¤ § › ® ” ¤ ©
¬ ¤ ¥ ‘ “ “ ” © © ” ¬ ¤ ¦ ž ¤ ¥ Å ¦ ¤ © ¤ § ” ‘ © • ” “ « § — › ™ ” ¬ ¤ ¬ › ™ ‘ ª
¬ ” ‘ © ‘ ’   ³  ” ¥ ¤ ¥ Å ¦ ¤ © ¤ § ” ¥ ‘ © • ” “ « § — › ™ ” ¥ ¥ ” ž
ž ” “ — ‘ © — ¤ ž § ¤ ¬ ¤ ¥ ‘ “ “ ” © © ‘ ¬ ” ¥ — ¤ ¬ › ‘ ž § ¤ ­ “ ” ™ ¤ ¬ ª
› — › ¤ ž § ” ¥ • ¤ ž ¤ “ ‘ © ¤ ¥ Å ¦ ¤ ¬ ¤ ¥ ™ “ › ± ¤ ž ¤ © — ¨ § ” ¬ ” ‘
› — ­ © ¤ — ¤ ž § ‘ “ ³ À ¥ § ” ¥ ­ “ ” ™ ¤ ¬ › — › ¤ ž § ” ¥ • ¤ ž ¤ “ ‘ © ¤ ¥
¥ ” ž ž ” “ — ‘ © — ¤ ž § ¤ ¬ ¤ “ › ® ‘ ¬ ” ¥ ¬ ¤ © ‘ ¼ ” “ — ‘ © › ² ‘ ™ ›  ž
¬ ¤ © ‘ § ¨ ™ ž › ™ ‘ ‘ © • ” “ « § — › ™ ‘ ³ À Ê › ¥ § ¤ ž ž ¦ — ¤ “ ” ¥ ‘ ¥
¼ ” “ — ‘ © › ² ‘ ™ ›
” ž ¤ ¥ ­ ‘ “ ‘ © ‘ ’ “ ” • “ ‘ — ‘ ™ ›  ž   › ž ¢ — › ª
™ ‘ º ­ ” “ ¤ È ¤ — ­ © ” ä å æ ç º ä å è ç ³ Ó › ž ¤ — ± ‘ “ • ” º © ‘ — ‘ ¹ ª
” “ « ‘ ¬ ¤ ¤ ¥ § ” ¥ § “ ‘ ± ‘ È ” ¥ ž ” ­ “ ¤ ¥ ¤ ž § ‘ ž ¦ ž ­ “ ” ª
• “ ‘ — ‘ • ¤ ž ¨ “ › ™ ” Å ¦ ¤ ¥ ” © ¦ ™ › ” ž ¤ § ” ¬ ‘ ¥ © ‘ ¥ ‘ ­ © › ™ ‘ ª
™ › ” ž ¤ ¥ ¬ ¤ ¥ ¦ ¥ ¼ ” “ — ‘ © › ² ‘ ™ › ” ž ¤ ¥ ³  ‘ ™ ” ž ¥ § “ ¦ ™ ™ ›  ž
¹ © ” ¥ — ¤ ¬ › ” ¥ ž ¤ ™ ¤ ¥ ‘ “ › ” ¥ ­ ‘ “ ‘ ¤ Ê ­ “ ¤ ¥ ‘ “ ¬ › ™ » ”
­ “ ” • “ ‘ — ‘ • ¤ ž ¨ “ › ™ ” º » ‘ ž ¥ › ¬ ” § ¤ — ‘ ¥ § “ ‘ § ‘ ¬ ” ¥
¤ ž ä å å ç ¹ ä é ç ­ ¤ “ ” º © ‘ ¥ ¤ ™ ¦ ‘ ™ › ” ž ¤ ¥ ¬ ¤ © ” ¥ ­ “ ” ± © ¤ ª
— ‘ ¥ ­ ¤ “ § ¤ ž ¤ ™ › ¤ ž § ¤ ¥ ‘ © ‘ ™ © ‘ ¥ ¤ ê ë ì í î ï í ð ñ ä å ò ç º
ä è æ ç ¤ ¥ § ¢ ž ¼ ¦ ¤ “ ‘ ¬ ¤ © ‘ © ™ ‘ ž ™ ¤ ¤ ž ‘ — ± ‘ ¥ ‘ ­ “ ” Ê ª
› — ‘ ™ › ” ž ¤ ¥ ³ À ž ‘ © • ¦ ž ” ¥ ” § “ ” ¥ ™ ‘ ¥ ” ¥ º ä ó ç © ‘ ¼ ” “ ª
— ¦ © ‘ ™ ›  ž ¬ ¤ © ­ “ ” ± © ¤ — ‘ ¥ ¤ ¬ ¤ ¬ › ™ ‘ ‘ ­ “ ” ± © ¤ — ‘ ¥
ê ë ì í î ï í ð ë ô õ ë ô ö ÷ í ñ ì ö ô º — › ¤ ž § “ ‘ ¥ Å ¦ ¤ © ” ¥
­ “ ” ± © ¤ — ‘ ¥ ô ö ÷ í ñ ì ö ô ù ú ì û í ö û ñ ê ñ ô ¥ ” ž ™ ” ž ¥ › ¬ ª
¤ “ ‘ ¬ ” ¥ ™ ” — ” ™ ‘ ¥ ” ¥ ­ ‘ “ § › ™ ¦ © ‘ “ ¤ ¥ ³ ü ¦ ž Å ¦ ¤ ¤ ¥ § ”
¤ ¥ ™ › ¤ “ § ” ¬ ¤ ¥ ¬ ¤ ¤ © ­ ¦ ž § ” ¬ ¤ ® › ¥ § ‘ § ¤  “ › ™ ” º ¤ ž © ‘
­ “ ¢ ™ § › ™ ‘ º ­ ‘ “ ‘ ¥ ¤ “ ¤ ¿ ™ › ¤ ž § ¤ ™ ‘ ¬ ‘ ™ © ‘ ¥ ¤ ¬ ¤ ­ “ ” ± ª
© ¤ — ‘ ¬ ¤ ’   ¬ ¤ ± ¤ ¥ ¤ “ ™ ” ž ¥ › ¬ ¤ “ ‘ ¬ ” ™ ” — ” ¦ ž ™ ‘ ¥ ”
¤ ¥ ­ ¤ ™ › ‘ © ³
ý
” ž ™ © ¦ › — ” ¥ Å ¦ ¤ © ‘ ¥ ‘ ­ “ ” Ê › — ‘ ™ › ” ž ¤ ¥ • ¤ ž ª
¤ “ ‘ © ¤ ¥ ¤ ¥ § ¢ ž © › — › § ‘ ¬ ‘ ¥ ‘ ™ © ‘ ¥ ¤ ¥ ¬ ¤ ­ “ ” ± © ¤ — ‘ ¥
” ž ” ¥ ” ž ‘ ­ “ ” ­ › ‘ ¬ ‘ ¥ ­ ‘ “ ‘ ¥ ¤ “ ‘ ¥ ¦ — › ¬ ‘ ¥ ­ ” “ ¦ ž
™ ” — ­ ” ž ¤ ž § ¤ ¥ ” ¼ § ¾ ‘ “ ¤ ³
À ž ™ ” ž § “ ‘ — ” ¥ ¦ ž ‘ ¥ › § ¦ ‘ ™ ›  ž ¥ › — › © ‘ “ ¤ ž ¤ © ™ ‘ ª
¥ ” ¬ ¤ © ­ ‘ “ ‘ © ¤ © › ¥ — ” ³ Ñ ¦ ™ » ” ¥ ‘ ¦ § ” “ ¤ ¥ » ‘ ž ­ “ ¤ ¥ ¤ ž ª
§ ‘ ¬ ” ­ ‘ “ ‘ © ¤ © › ² ‘ ™ › ” ž ¤ ¥ ­ ‘ “ ‘ ­ “ ” ± © ¤ — ‘ ¥ ¤ ¥ ­ ¤ ™ › ¿ ª
™ ” ¥ ¬ ¤ ’   ä ç º ä
ç º ä å é ç º ä å
ç º ä å ó ç º ä å ç º ä è ç ¹ © ” ¥
­ “ ” ™ ¤ ¬ › — › ¤ ž § ” ¥ ­ ‘ “ ‘ © ¤ © ” ¥ • ¤ ž ¤ “ ‘ © ¤ ¥ ¤ ¥ § ¢ ž “ ¤ ª
¥ § “ › ž • › ¬ ” ¥ ‘ ‘ © • ¦ ž ‘ ¥ ™ © ‘ ¥ ¤ ¥ ¬ ¤ ­ “ ” ± © ¤ — ‘ ¥ ³ À ž ª
™ ” ž § “ ‘ — ” ¥ ¦ ž ‘ ‘ ­ “ ” Ê › — ‘ ™ ›  ž • ¤ ž ¤ “ ‘ © ¤ ž ä  ç ™ ” ª
— ” ¦ ž ‘ ¤ Ê § ¤ ž ¥ ›  ž ‘ © § “ ‘ ± ‘ È ” ¬ ¤ ä å å ç ­ ¤ “ ” ¤ ©
• “ ‘ ž ¤ ¥ ¼ ¦ ¤ “ ² ” § ¤  “ › ™ ” › ž § “ ” ¬ ¦ ™ › ¬ ” ­ ‘ “ ‘ ¤ © ™ ‘ ¥ ”
ê ë ì í î ï í ð ë ž ” ¥ ¬ › ¥ ¦ ‘ ¬ ›  ¬ ¤ ¦ ¥ ‘ “ © ” ™ ” — ” — ” ¬ ª
¤ © ” ¤ ž ž ¦ ¤ ¥ § “ ” ¤ ¥ Å ¦ ¤ © ¤ § ” ³
À ž ¤ ¥ § ¤ ­ ¦ ž § ” ¹ ¬ ¤ ‘ ™ ¦ ¤ “ ¬ ” ™ ” ž © ” — ¤ ž ª
™ › ” ž ‘ ¬ ” ‘ ž § ¤ “ › ” “ — ¤ ž § ¤ º ­ ” ¬ ¤ — ” ¥ ‘ ¿ “ — ‘ “ Å ¦ ¤
¤ ž ™ ” ž § “ ‘ “ ¼ ” “ — ‘ © › ² ‘ ™ › ” ž ¤ ¥ • ¤ ž ¤ “ ‘ © ¤ ¥ ‘ ¥ ” ™ › ‘ ¬ ” ¥
                     "  &
 ' " * + + '     . "  . *    2 4   7  7  8 
   ; *    '     . "  " 7   + +   &
  " "  7    *              8    
  '   * "        " "  2         * ;  8
"  F   G + "     I *   *    + "  7  &
  *          + + *  +    N O 8 N Q O 8
N R O 8 N R  O    *  S  *       T    *   + 
       *  ' "   2
        V ' G '   V ' "   + + *  + 
  8 '  7    *   X   " V ' +      
"  F   G + "   "   +    . "   +  
F +  T  *   " ' F "      *         *  
  I   +  " " * .   G 8 F   +  +       
 ' ;   "    '  +   '      *  2 ]   &
 * ;  * _    *   *  "   +     " "  " + *  `   &
 ' " + " " * .   G     '  " +  " +    . "
'    * + 7    *        d '    "
'    * + '      " * g  * _  X   " V '  ' &
+       * +  +  '   V ' "   " X   G   * &
  2 j '  7   "         " "   ' +   
      +    T V ' *   +     * + *    * . ' G &
+ F       * + 8  V ' *    '   7 G .  * +  V '
   . *   "  +      *    8 F  "      
7    X o   2 j T    8 ;  *    " " * g  *   
 ' +           *   +     +  "     &
      " ;  '    '     * 8 F   ' + 
+ S  *   ' ;     I *   *    + '     
   * " " 2 q V ' G         " ;   * _    '   * "
F +     *       * + + " " * .   G 2
 s 

t v w x y x  x 

y v 


{ x {


t

| }  €  } €  t } |

4          '   '    + *  *  *     '   

   +  "  X G  N R O +   + "    X    * _ 
 *  T  *    '   * " F   " "        &
 +   + *       +   ' + *  8 F  +   
      '   "  X   " +   '     *  2
„
'  +     '   ' ;     . "     
  ' "   8  ' " V ' *  + "          *    
'      X ' G 2 4     d   "    ' X *   " X  &
 *       " "             . "   + "
 *    "  2 … '      V ' "          *  
          +     "   . *       * +  2
]      . "   +   V '         
 "    ' +    *   "    +   '   +  ' 
*     g            "  d  '  *      &
" "        "    '   * "  2 4 " + *  ` 
 "   ' S  *      ‡ I * . "          
    ' ;      . "   +   2
]         "   " '  * _  + '   
 . &
"  +    *  * g  * _      '   '  * _   &
 '   * ; 8 +   + " " +  * g V ' *  +   '     * &
+ + +       * + F " " +  +   7   '  I   &
 * _  +  *  *  * g  * _  ‰   I *  * g  * _  ‹ 2 4  
 '  * _             '  * _   '   *   "
  '  * _  +   '     * +   2 ]      . &
"   +    ' +     "  * S  +    . 
 '  '  * _   '   *   " 2 Ž   '  * _   '  &
 *   " V '     *  '   _ "   o   *     '   * &
;       "  "  + "     ‘ ’ “ ” •  – 2 ]  
   . "   +    ' F  '  * _   '   *   "
  T     '      ;  *    o   *      '  &
 * ;         "  "  + "      . "  
˜  ™ ” ’ “ ” •  – 2 ]  '  * _   '   *   "       &
 *   "    *       .      " '  *   
_   *   "    ' .    . "   2 ]  +   +   * 
   "    ' .    . "    '      ' "  * _  +
   ' +         +     '  X    + * &
 * X * +  2
„
+   +   " X          ' 
 ' .    . "  2 ]     +   + " X           " &
   +    +         +   2 Ž   *   + * &
 * X * + +  + "   +  ” "   +   8 *  + * 
V ' "   " '  * _  + "  ' .    . "  ”  '  +
   .    "   " '  * _  + "  ' .    . "    &
    +     "   +   2 ]   *    + " X   
                * +      +  *  *    2
]   " '  * _  _   *    '   ' .    . "  
 .  *      '    '   * + +  *  *    ‰ ' 
  " G  *  ‹   g  +  +  + "   +  *  *  * " 2
…    "    "     +   + '  X         &
    +       '     * g . * + *    *   " ‰ "
 . " +   ‹ F     *  " *       * _   " &
;     ; " '  "  '  * _   '   *   " F "
  " G  *  _   *  2 ]  . " +        *
  "     "     +   ; " ' +   2 Ž  ; g
V ' "  . " 7  * +      '  + 8 '       * &
+  *  ;    + "  . "       *   .    "
  " G  *  _   *  2    "      8    " ;  '     . &
"  +    X    * _   *  T  *      *    
 .    "  '  * _   '   *   " 8 ; " '  "  . "
+   F + ;  " ;  "   " G  *  _   *   *  ' 
    *  2 …    "    "  T " *  *  +    * . * " &
* + + ‰  V '    G  * 2 2 2  ‹  '  *       * _ 
  . * o   V '  * + V '  ' +    .   * +
   *  + "   ' + *  + "  . " 2 œ * " X    
 G  " *   8       "     +     ' +    X &
528 Algoritmos y Técnicas de Programación Paralela
   


 
      
      "  $ &
  
 & )    ) 
"   
& 
    

 "     
2



4 5  &    "


   
 &       
  

      
   
 < =
 
5          " &   5  C

  E F 
 &

5  
J       5  "    J &
< L 
    & )    ) 
"  
        

 

2


4 5  &    "


   
 &       
  2

 $ &

 
5

      " &   5  C
    "   

     " &   
   

    5   
 
 " 2
       " &   5  C  
    < Y   Z    

   5   
    
5     \ 5  5  C  
   
    
2
"   
\   5 &     5   
 

5 &  
5    

   ) 
"   
E F _ ` a b c d f g h i j b k g  _ ` a b c d
m g d b i j b k g  h g _ ` a b c d f g h i j b k g n h g _ ` a b c d
m g d b i j b k g < =     5   
   
4 o  &     

  J &      " &   5  
 
E F  
 &


5     \ 5   
   
 J &  

    5  
2
J   s  < t 
   

    &
    "
      J s  

 &

    5   n

 $ &

   &



4 
  2
   Z 5   "

   &
  
$ &
    < =     )   x
"      "  
z
"     
   ) 
"   
E F    
5    &  
   5 &     5   
 < =        ) 
"  

 Z &      5  " 
z
"    
   
5 5  

n {       &      n      
 &   
&
   

 $ &

  < E  
"  
5      &  
 5    5  C
" Z  
       

       ) 
"   n  &     " & 2
  5  

} x ~ <
E   ) < €  5 o      x
= 5 <
fkc = max{fk−1c, fk−1c−wk
+ pk}
‚
  
L
    €  Z   5 
E   ) < L & ) 
5 &
5  
5  "  " Z     J 
= 5 <
fij = fi−1j−1 + 1 if xi = yj; o
fij = max{fij−1, fi−1j } if xi = yj
‚
  
ƒ  L
    €  Z   5 
E   ) <
‚
 "   " Z  5    
 

            …  †  n  ˆ
= 5 <
dk
ij = min{dk−1
ij , dk−1
ik + dk−1
kj }
‚
  
L
    E    Z   5 
E   ) < € &       5  5  C

   "  
"     5

= 5 <
cij = min{cik + ck+1j + ri−1rkrj}
‚
  
ƒ  L
    E    Z   5 
‚
&     x = z
"     
   ) 
"   
E F
 ‰

 ‹ Œ   ‹  ‹   ‘ ‹

’   ’

“

” • — ˜
• ˜
“ • ”

ƒ &
     
5  C
   
      5    
&
 o
   " 
  J

       E F  &    
"
      J s  
  Z   
  n $ &
 
 &  

2
"       5  "  
z  
&       
 &  &     \ 2
  < t 5    &  5  C
& "
  "   5    5 
 s    2
5    "      
  $ &

&
        C  
2
)
 s  
 5 & ) 
       &    ) 
 s      š  

  
            J "  
  
   & 5  C 

   ) 
"   
  E   J   "  5  C F  Z "  5  <
•
‚
 o

5   5  &  "
      J s  < † 
o
   " 
  
)
 s  
J &   
5
 5   
"
      J s  &         
      
5 &  2
5  
  & 5    

•
= 4  
          
 

      
5 &  2

5     & 5    
 <
•
L     
    &  "       J  
   ) 
2
"  
 œ  "    
5   
 

5 &  
5    <
•
‚
   5                  ) 
"  
J   
 <
•
 
4  )                 &
  5   
 


5 &  
5     &
 
    
J    

 2
  & 5  C <
•
L     
              
5    
  5    2
   5    E F < †  o
   " 
    C  

)

 5     
 ) 

    & 5  
 C  2
  "        " )  œ       s   5   C    "  
    5     & )    ) 
"  
    )   
E F <
•
E    )       
      5      Z      


  )       <
•
  5       
&   <
•
E     )       <
•
= \ 5 
5   <
•
Ÿ         


           "      2
 
       &  &      
4 
    <
=  
        

 $ &

        E F  " 2
   5          $ &
   

"
   
   œ 5  5 
$ &
 &


  )     s    
   5          5 2
&   
 n 5 &  
 



5        5  5  C <
XVI Jornadas de Paralelismo, JP '2005 529

   

            
  " $ " %  ( + + .  0 2 $ % +  5 0 6 0 8 : + % = > + ? @
+ 2 . 0  + 5 0 5 $ % ? +  C ? 5 $ % ? 0 . +  6 % 2  $ " $  " % G H .
 0 2 $ % 6 2 % 6 % 2 5 $ % ? 0 . 0 +  > 2 5 > 2 0 : + ? +  > 0 @
: % 0  Q 5 % " %  + T 0 . 0 5 $ U ? 6 % 2 " + : $ % : + . 0 
+ 5 0 5 $ % ? +  C ? 5 $ % ? 0 . +  W . 0 > 0 = . 0 : + Z [ +  0 = @
 > 2 0 Q : 0 5 % " % ? 0 > 0 = . 0 : + +  > 0 : %  G H . +  ( + . + @
> % 6 2 % 6 % 2 5 $ % ? 0 . 0 > 0 = . 0 W T 0 2 $ %  " ^ > % : %  6 0 2 0
2 + 5 % 2 2 + 2 . 0 : 2 0 ? > + . 0 + T 0 . 0 5 $ U ? : + . %  +  > 0 : %  G
H  > %  " ^ > % : %  6 + 2 " $ > + ? : $ C + 2 + ? > +  C % 2 " 0  : +
2 + 5 % 2 2 + 2 . 0 > 0 = . 0 d 6 % 2 f . 0  g 6 % 2 5 % . " ? 0  g 6 % 2
: $ 0 h % ? 0 . +  i W + .  0 2 $ % + . $ h + . 0 " + j % 2 ( + ? %
T $ % . + . 0  : + 6 + ? : + ? 5 $ 0  : + . 0  + 5 0 5 $ % ? +  C ? @
5 $ % ? 0 . +  G H ? + . 5 0  %  + 5 + ? 5 $ 0 . g + . " % : % : +
2 + 5 % 2 2 $ : % : + . 0 > 0 = . 0 $ ? : $ 5 0 ( + . %  +  > 0 : %  : +
. 0 f . 0 d 5 % . " ? 0 % : $ 0 h % ? 0 . 2 +  6 + 5 > $ T 0 " + ? > + i
 + 2 s ? + T 0 . 0 : %   + 5 + ? 5 $ 0 . " + ? > + g " $ + ? > 2 0  ( +
+ ? + . 5 0  % 6 0 2 0 . + . % . 0 + T 0 . 0 5 $ U ?  + 2 s 2 + 0 . $ 8 0 : 0
6 % 2 + . 5 % ? j ? > % : + 6 2 % 5 +  0 : % 2 +   $ " . > s ? + 0 @
" + ? > + G
              
u 0 5 . 0  +  v w v x 5 % ? > $ + ? + . 0 $ ? C % 2 " 0 5 $ U ? 0  % 5 $ @
0 : 0 0 ? +  > 0 : % : + Z [ G H  > 0 5 . 0  + 0 . " 0 5 + @
? 0 W 5 0 . 5 . 0 + . T 0 . % 2 U 6 > $ " % + ? + . +  > 0 : % W . 0
: + 5 $  $ U ? 0  % 5 $ 0 : 0 0 . 0 + T 0 . 0 5 $ U ? U 6 > $ " 0 G u 0
+ T 0 . 0 5 $ U ? : + ? +  > 0 : % $ " 6 . $ 5 0 + . 0 5 5 +  % 0
. 0 $ ? C % 2 " 0 5 $ U ? : + % > 2 %  +  > 0 : %  + ? . 0 > 0 = . 0 : +
Z [ G u 0 ~ + 2 2 0 " $ + ? > 0 6 2 % 6 % 2 5 $ % ? 0 ? % = j + > % : +
. 0 5 . 0  +  w  x % 5 . > % + ? 5 0 : 0 $ ?  > 0 ? 5 $ 0 : + . 0
5 . 0  +  €  # x  G u %  " ^ > % : %  % &  '   (  & + ƒ -  / W
0 1
 '   (  & + ƒ -  / : + . 0 5 . 0  +  w  x 6 + 2 " $ > + ?
% = > + ? + 2 + $ ?  + 2 > 0 2 +  > 0 : %  + ? . 0 > 0 = . 0 G
 x 3 „ ƒ  x … †  w … …  v w v x 6
† € ‡ … v
0
 €  x ˆ 8 ‰ ˆ :
 €  „ v ƒ € ‡ 8 … €  :
ƒ ‡ v # w  „ x :
>
x † ƒ … ƒ € ‡ Š :
 w  x 8
v w  x :
‰ „  ƒ † ?
@ @ B C
v € Š € … ‰ w  w ˆ w ‡ ƒ ‰ „  w   w †  w … x
D D D D
@ @
& # w  „ w „ ‡ x … v w Š €
# € ƒ Š & # w  „ w + ƒ ‡ v … v w F x - ƒ ‡ v ƒ ‡ Š x G / :
D D D D
I
:
# € ƒ Š  v w v x ? ? & # w  „ w + ƒ ‡ v … v w F x - ƒ ‡ v ƒ ‡ Š x G / 6
 v w v x … v + ‰ ˆ - … €  - v w  x / :
 v w v x v ˆ ‰ + ‰ ˆ - … €  - v w  x / :
D D D D D
… v M v w  x
D
% &  '   (  & + … v w F x N O - ƒ ‡ Š x G / :
… v
D
… x v ' Š x † ƒ … ƒ € ‡ + R / :
ƒ S + ƒ ‡ Š x G T M ‰ ˆ
D U
x ƒ F V v + … v w F x / / 6
v ˆ ‰ M v w  x
D
% &  '   (  & + … v w F x N O -
ƒ ‡ Š x G N ‰ ˆ
D U
x ƒ F V v + … v w F x / / :
ƒ S + … v
D
F x v ' # w  „ x + / X + v ˆ ‰
D
F x v ' # w  „ x + /
Z
‰ ˆ
D
‰  € S ƒ v + … v w F x / / 6
… v
D
… x v ' # w  „ x + v ˆ ‰
D
F x v ' # w  „ x + /
Z
‰ ˆ
D
‰  € S ƒ v + … v w F x / / :
… v
D
… x v ' Š x † ƒ … ƒ € ‡ + O / :
I
I
v w  x
D
0 1
 '   (  & + … v - … v w F x - ƒ ‡ Š x G / :
D D D D D
I
D D D D D
[
 ] ^ _ a  c ^ e
  g Ž

 Ž        h j k j l
H . 5 U : $ h % G  : + f ? + . 0 5 . 0  + +  > 0 : % 6 0 2 0 ? + @
 > 2 % + j + " 6 . % G ‘ + : + f ? + ?  ? 6 2 % = . + " 0 " + : $ @
0 ? > + . 0 T 0 2 $ 0 = . + ‰ ˆ g ? 0  % . 5 $ U ? " + : $ 0 ? > + . 0
T 0 2 $ 0 = . + … €  g ? 0 : + 5 $  $ U ? " + : $ 0 ? > + . 0 T 0 2 $ @
0 = . + Š W . 0 > 0 = . 0 ( + ? %  6 2 % 6 % 2 5 $ % ? 0 2 s 0 5 5 +  %
0 > % : %  . %  +  > 0 : %  : + ? +  > 2 % 6 2 % = . + " 0 " + : $ @
0 ? > + . 0 T 0 2 $ 0 = . + v w  x G H  > 0  T 0 2 $ 0 = . +  6 + : + ?
5 % ?  $ : + 2 0 2  + h + ? ^ 2 $ 5 0  g W 0 ( + : + = + 2 Q 0 ? 0 6 0 2 + @
5 + 2 6 0 2 0 5 0 . ( $ + 2 6 2 % = . + " 0 ( + ( + 2 0 " %  2 + @
 % . T + 2 G  : + " s   + : + f ? + . 0 T 0 2 $ 0 = . + # w  „ x ( +
+ ? +  > + 5 0  % 5 % ? 5 2 + > % 0 . " 0 5 + ? 0 2 s + . T 0 . % 2 : + .
= + ? + f 5 $ % " s “ $ " % G
”
0 = + : +  > 0 5 0 2 ? " ^ > % : %
530 Algoritmos y Técnicas de Programación Paralela
   
         
          !  ! $ &     '  
      *     
 
 - * /  *
 ! *   2 $     ! 5
 ! $ &      
 8 
!  !   <    *  !    *    5
   !  @ *  
     *      !       8    
D E 
   '     
 
 - *       8   I    
    L            *        !  !   ! 2 P   

 
 - * /  *
 ! *      *  ! 8       
@ V
!
  '         *  !  !   !   /    *        '      !
   Z  8     !   ! 8  
  <        !  ! ^ 
  *  !
  !    !    !  V   !  * ^    *   
_


2
      


 

 
` *  &  a   V *      !      
     * 
       
!    !               !  &      ! 8     e
! 8   *    !          !  2 D       !    8   !    5
    *      /  *
 - *

h i j   2 $ 
-   < !  *
  V <    2 m         *  o    !       5
  *  
 - *       /  *
 - * 2  8    &    '    
 *
  e      8    @   D 2 ^ ^        8    @ 
! * 5
  *   Z   
       V *      *     !    *      @

!  !   
      ! ! 
 ! *      *     '      !
  D  ! <    
 - * E  * Z  
 2
` * 
      ! &      t  u v w x y    
 *   ! 
  Z     !     *    *         *    *
   *
   
        !  &   '    ! *   '      !  ! 
   !  !     !  
 ! *     * *      !  o    ! 
  *     !        !  e        
     
  8     D E 2 P 
    *   *    *
   !  &    
 
    { | }  u ~  { u     *  !
!  !   Z     ! 
   *    *
  '     '         !  &   2 $    ! 8 o  5
 !    Z     !       !  &   *      !  ! 8    
    &         !  ! ~ w j    ~ |

{   2
_
  *  !  
 * & !
      !  ! ~ w j    ~ |

{     !       ! 
      8     D E  ! *  &      !    <    *  !  *
 
!     ! !  V    2 P           a    *   o 
 5

 - *         *    !   
!            *  !
 
     | }  u ~  {  h ~ u  € u € | ~   ^ 
  *  !   !
      !  ! ~ w j    ~ |

{     
    &      @    
V          8     D E   / !           2
_
 8 
       '      *    /  a       o 

 - *   5

  *
   e                         *  
^  e '        * 
     !  &     /    *   2
i j ‚ } w  u " $
"
  "
i j v € h i j  i j v h ~ # ‚ $ ‚  h ~ & & h ~ #   %
"
~ |  } u € x  € '
 | } w v i | j { | }  x  €  '
 u v w x { u v w x '
i ) { v ~ u h € ) +  h ~ #  ( + *  '
) + . . { u v w x '
i )
{ v ~ u h € ) +  h ~ #  ( + *  '
) + . . x  € '
 | }  u ~  { u  { | }  u ~  x  € $ { u v w x  '
{ | }  u ~ ~ w j    ~ |

{   '
{ | }  u ~ {  |

 v h  } u   '
{ | }  u ~ # u v  x | } i ‚  
{ u v w x # u v  . w €   v h # u {   2 + $
{ u v w x # u v  . w €   v h v u {    '
{ | } 4 { | }  u ~ { | } w v i | j   '
‚ | w v 6 6 { | } 6 6 u j  } '
7
8
9 ; < =
? A <  B
„ … † ‡ ˆ … ˆ ‰ Š ‹ Œ  Ž ‰  ˆ ‡ ‹  ‘ ‰ Œ  Ž ‰ 0 ‹  ‰
$ *    o    !   
-   < ! 2 m   *  &  a '  
  /  *
 - * ~ w j    ~ |

{   ^     !  o 
       
       !             Z *        8     D E 2
’
! *   *  
 - *  
 
     !  @  
 -     
 o 
   *  !      !  ! # u v  x | } i ‚     ! !  5

 ! *   ! !    ! 8 o   !  !  &     
   8  
  
!  @  
 -        a  *  ! !         ! V *   2
  *     *               !  
 - *  *        
   Z *    2
     9  E G I < 9 1 G =
• 
     | }  u ~  ! ! 
 ! *   !  !       !   5

 - *      /    *        / !     2 $   
   

! *    *        
         !  e  !     !  ! 
  '      !          a    *   o 

 - *   D E
 * 8            *       
 V

 ! *   2 $ *
   Z
 
     * 
    &       e  !   !  !   
   !  
 - *   
@ V
!   ! *   V *   ! 
!  !   8 5

          
      *
   2 $       ! 
   

! *          <    *  
! * o  *  !    !  !     
 !  
 - * 
•
 | }  u ~  {  h ~ u  € u € | ~  2 D             
   !   
!        2
•
 | }  u ~   i { v ~ i  w v u  € u € | ~  2 D   
 Z '   *        !          8     2
•
 | }  u ~     ~ i  2 D        / !     '     5
 *  !   !   !    !   *     !    2
•
 | }  u ~   u v u ~ | # u j 2 D     *  !  * !  ^   5
  ! <  *  !   ! *    !   !
    !        *
  *  
 
     
!    
 ! *        5
  *     e         *  
! *  L  - *       
XVI Jornadas de Paralelismo, JP '2005 531
                              
 $  %     &    % (
•
* +  , -  . ,  /  ( 0     4      %      & % 8
%  $      9  ( 0  % $ %    %    4      %   
$   %  $   % ?   @     %           (
C  $        $        F       & % 8
%      %    %   %  K L   %  $      
 $       9  ( P  & % %  R   % & L    &    R
$    $  % F           & % %      %  8
  %  ?            $            
      %         %       %  K  %     (
•
* +  , -  ] - *  ^ + , ( 0       %   `      $   8
    9    $     %  &   $         ( P   9  8
@ %        %         % $            8
&    % ?    %   `  %   % & L    &   
  F     & %   %      e   %  R  4     %
   $       9  $    % F      4      %    9 $ 8
 &   (
g
h i j k  m

n o j  o q  k m

r s o t

 i j
P        9    L         K       9   v 8
$    &           &    %          % ( C 
 % & $      %    & $ %    4      9  $     4  8
    %                 %   %    & $ %    4  8
    9  $  % $ %    %   %  $ %    & % %    %   8
  9  * +  , -  y
z - , . { , { * -  (
|
% & % $  % F   &  
 $    F          %   & %   %  $  % F   &     
  &            F   } R   $  % F   &    
& %  €      } ‚  0 ƒ R   $  % F   &       F   8
        % &   & L     @  ‚ „
|
C ƒ R     @ %   & %
   % ? $     %    &   %  & L   %  %  ‚  C 0 ƒ R
?   $  % F   &     $      `    9  9 $  &  $   
  &    $       9   &       ‚ † 0 0 ƒ ( P  % 
 4  & $  %    $            %              
       %    R ? $           %   % & %  4  & 8
$  %  $    &   € %  %  % $  % F   &    0 ‡ ( 0   
   $  % F   &    €   @      %     %    &   
                   ( ‡  F  %      %  $  % F 8
  &    0 ?  C 0  %          R €     %       8
%      %   & ‰ % %     %    % $ %  Š    (
„  $  % $     %         %  $  % F   &   „
|
C
?  † 0  & $ %        %  & % %      %    %
$ %    @ %      ( 0      „
|
C   & % %   @ %   
 & $   `     K       9               $    % 
 `           F    0 ‡ ? $      $  % F   8
&   † 0  % &    `     K       9        @ % 8
   $      $   ?   &                 $    % 
    €  (
P   v $    &   %  % & $     %      €      8
 %    %       Ž †  C 8
    C 0  % 
 } 
‘  @ € €  ’
0 % ’     & € ` ‚ } ” • – % $    ƒ
 %   — F  ˜ † ( „ %   % %    L   %     8
%     K ‰     C 0  ’   € • % $     % 
   † Ž     ( P       %   v $    &   %   9  %   8
 & %   % %   }  $  %     %    (
„    F    • R R — ?  &        %    & 8
$ %    4      9  ?             %    % F     
$     %  $  % F   &    0 R „
|
C R  C 0 ? † 0 0   8
 $    K  &    ( „ %    & $ %    4      9    L 
 v $     %      @   %  (
   & $ %
˜         9 

0  %     %     0 }  0 •  0
} • ( ” ” (  } }
( ” 
  
• } ( • • • — (
— } ” (  •
} ( ” —  } ( ” 
} ( ” }
—  (  —  • ( — ” — ( ” — —
( }  (
• • (


 (  ” } ( •  • (  •
 (  } • ( }
( • 
}   (    ( ” ” } (
}
(
}  ( } — }  ( } ”
|
   % •     & $ %    4      9  $    $  % F   8
&      & %  €   
N
      &   %  % F 4  % 
?
C
      $        & %  €     0 } ‚
N 
}   
C 
•   ƒ R  0 • ‚
N 
•  
C 
 —   ƒ
?  0 ‚
N 
 —  
C 
 —   ƒ (
„ %        %   % & $     %         Š      
K    4      &  % %  % @ e       › % ( „  €   8
  &     &          &    %         %   % 
  % %   %     %  (
|
% & %     $    F  R  %  $  % F 8
  &    &  ? %   &  › % % F      &  4 %        8
     %    ( 0      $  % F   &  † 0 0   % F    
  $               %      
? }  $  %   8
  %    R   %    F  %   &  4 %    %    
   €        K     %    $         (
|
% & %    
  $      & F  ‰  $    $  % F   &   $     › %   %
  % F      F               %    ‚ † 0 0 } ƒ (
532 Algoritmos y Técnicas de Programación Paralela

  

      
 

          

 

 " 


# %
'  # % # ) ' # % * )
  
" # % ) ) % * % '
%
* " % # " % " ' #
) # % "   " % "
' * % '
%  ) % ' # ) % ' 

# % )
% " % *
* % #  #
% )
' %
*
* # % # %
* " % #
)
* % ) ' " % # ) % # #

.     
       4   . 
        7   8
   


N1
9
N2
       <
> .        
   .   
  

 C
N1 
# # # D
N2 
# # # E D


 " C
N1 
# # # D
N2 
# # # E 9 

 C
N1

 # # # D
N2 
 # # # E %

  

      
 

                "   
) %   % # * "  % # )
  
" " % * %
" " % )  )
% ' 
" % # # " % # #
) % * ' % ' * %
%

# ) % # # ' % ' #

# % * % ' % '
% ) " % '  ' %
"
* # % )  % # " * % * ) )
%  % " ' *  % " " *

.    )  
       4   . 
        7   8
     
N
           O P  >
      <   Q
   C
N 
" # # E D    " C
N 
# # E 9    C
N

 # E %

  

      
 

          T   T   " T  
# % # ) * %
' " %
" *
  
" # % #
 % #
# %  " '
% # # " % # # ' " % "
) # % #
%  #  %
"
" % *  % ' ) ) % * #

# % # # " # %
" %
* #
% # *  %  * ' % " * )
* # % # # % ) * " ) % # * *
" % * ' # % ' % ' # '

.      
       4   . 
        7   8
   T  
N
             > 
   T  
C
N 
# # E D T   " C
N 
 # # E 9 T   C
N 
# # # E %
\

] _ `  b c d ] _ g c  i j
 
]  b i b j ]

     . 
         
 l .    7 4  >
8
O 
  > m n              .   
7    m  <   P 
8
          <     
  r
 s 
  u  

     v     >
 Q   > 
    >  %      .  >   
   . >  
       n        O   >  4      
  >   < m     
  y .     O  
       
    .  
   Q .  
         <     
 
r
 s 
  % }    l .    >     >  7   9  n 
  > 
9  .         
   Q s 
    >         8
 . 
     .  u     
  
   %
 
    l .
8
>   > .    9     
<               . 7
  8
>  9         
            .  >    
  .  .  
 %

 Q . > .     m       >   7  4
      >                >        . 8

      
Q     >      >  Q     9 .        8
l .    >         O   >     7          8
<     
  r
 s 
  %
 \
j

ƒ g ` d „ d g _ i ] c

.

      <         

}  ‡
     
8
>
     .     .   s l .
   % }  >  >   7  4
u  
  n    
     

} } C  } r }  E 9
    T

 >  
 


  
 9      < m  C    
Π 
      r  D  

" # # " 8 # ) ) '
8

#  8 #  9
 

" # # " 8 # ) ) # # 8

# 8 # E %
XVI Jornadas de Paralelismo, JP '2005 533
     



             !  # % ' (   !   % ,  . %  0 2 ( 
%   6 
%  (    8 : ; % ' = ( ; : ?  A ' : C D ( 8 : ' :  F
%   : 8 = % . . ' : H % 8 :   8  = ( C D (  H ( H  ; . % J : ?
=    N                 " $ & $ ( *
( , (  ( .  &     $ 4  & 6   , 6   & ,  :  "   > 
P Q Q  
 P           %   !   % ,  . %  0 2 (   . 8 : ?
; % '  J 8 0  F   % '  : ' :  F  W P ? X N 8 ( J % 8 :   = 
?   & $ (  B " $ & $ ( ( , ( $ 4 E    &  G   , 4   *
    .  [     \

 ]   ! ( . 8 ( ; A ( J  \ \ 
    # : 8 ` %   b     D  F  c % 8 0 . ' %   :  F  
8 0 ( e % J . H  ; . D 8 ( J D = :  F % ' :  ( % J = 2 = 8  ' : H
% J J % 2 :   2  % ; : H . J  F J % ; ; :  F  J  , & L ? L
     , &  $  L  P   



  \


 [  #  h (
i
D   #  A ' : A J % J 2 : ' ' D = 8 J % 8 (  A 2

 c  N  Q  &   , $ T  , & $    $ ( U ,  , $ & 6

 B , & , 6 , : Q W U T Y Z [ [  >  . % F (      8 ?
8 ( J  % ;  P Q Q  
   j  J % ' ( = X    h ; ( :  %       J l F D ( `
i
 
   % \   %   X ( ' F %    
i
 '  ; % N  c % J % ' ?
' ( '  2  % ; : H . J  F J % ; ; :  F %   % D 8  ; % 8 %
8 0 (  J 2  " $ & $ ( ( , (       .  P Q Q Q 
 ]     ( j   J  X 2  % ; : H . J  F J % ; ; :  F % = %
=  W 8 e % J ( H  ; .   (  8  N  6  j % = 8  J % : = 
(  : 8  J  " &  6 L  & 4 b  Q   J  L  B L
 & 6     g     ,   g      6 $     $ 4
     , &    \ \ \ 
  \  s H = 8 ( :  
i
   c 0 : ' ' : . =  %   i  s 
b % J 8  c N
i
     A , ( H 8 ?  J : (  8 (  W J % ; ( ?
e  J W  J . % J % ' ' ( ' A J %  H 0 %   A  D     ( H 0 ?
 : H % ' J ( .  J 8   x 
i
   P Q Q Q 

 j  : % ' : ' %    D  =   c % J  c % J % ' ' ( ' % ' F  ?
J : 8 0 ; = W  J  2  % ; : H . J  F J % ; ; :  F J ( H D J ?
J (  H ( = e : 8 0 ;  J ( 8 0 %   |  }  ( . (   (  H 2 
?   & $ (  B " $ & $ ( ( , ( $ 4 E    &  G   , 4   *
    .  P   P 

P P P   \ \ [ 
 \    : A A   = %   i   2 8 8 ( J  Q k 6  ,   $ & *
$ ( ( , ( $ ( .  &      H 0 % . 8 ( J  ] 
i
% ; A J :  F (
x  :  ( J = : 8 2 c J ( = =   \


  Q  c  b ( ' ; %    H  ; ;   = H 0 ( ; % W  J
 2  % ; : H . J  F J % ; ; :  F %   A J %  H 0 %  
A  D   % ' F  J : 8 0 ; =  ?   & $ (  B  , 
 
]  \

 P
  \
\ 
      N A % J % :  Q   , & $   q ,    &  $ 6 ,   
  G  $   &  $ ( T      t $    g " $ &  J J    ?
 % ' =  W  . ( J % 8 :   =  ( = ( % J H 0 
 ' D ; (   
 ? [   \


  P    j   % J . %   j  b ( '    :  : 8 ( = 8 % 8 ( . J  ?
H ( = = %    2  % ; : H . J  F J % ; ; :  F   J  
?   & $ (     (  , 4  $  ,  $   6      ] \


  \ ] 
  
  D ; % J    J % ; %    D . 8 %  %  
  % J 2 . : =  J  &  4  6      " $ & $ ( ( , (
      . E ,   . $ 4  $ (      B  ( .  *
&       0 ( A (  , % ; :  
i
D ; ; :  F = c D A ?
' : = 0 :  F
i
 ; . %  2  N  H    \ \ [ 
  [   h : %   #  i % 0  c % J % ' ' ( ' . J  H ( = = :  F
 W = ( J : % '  2  % ; : H . J  F J % ; ; :  F . J  F J % ; = 
N  " &  6 L  B T  "   { |  . % F ( =



\ 
 \
 
    c  h  0 ; %   ( J  X ( 8 ( J ; :  : = 8 : H %  
= 8  H 0 % = 8 : H  2  % ; : H . J  F J % ; ; :  F 
e e e  = (    = ' D  = (  c h    : = J ( 8    2  .  0 8 ; 
  ]  #  h  D % %   j   H 0 D (  8 (  X 2  % ; : H
. J  F J % ; ; :  F   8 e  ?  : ; (  = :   % ' = 2 = 8  ' : H
% J J % 2 =  J B  &  $    " &  6 ,    .  ,   , &  
P \  \

 Q [   \


   # 
i
 h D A  e  ! X c  (  ( J % ' : ` (  =  W 8 e % J (
W  J =  '  :  F = 8  H 0 % = 8 : H  2  % ; : H  . 8 : ; : ` % ?
8 :   . J  A ' ( ; =  b  ( 4 (  B ,   6  ,   ‚  ( ( ,   
P 


[ P  ! ( . 8 ( ; A ( J  \ \ 
 
 !  j : F D ( 8 %  
   A ( J 8  X 2  % ; : H . J  ?
F J % ; ; :  F   % J :  F  W . J  H ( = =  J =  ƒ  *
 , & 6  G , $ 4 E    &  G   , 4      , &   . % F ( =
 \

  \
\ 
  \ 
i
    J l F D ( `  X    ` ‰ ' ( `     ' ; ( :  % 
\     %  %     % J H l %  c % J % ' ' ( ' % ' F  ?
J : 8 0 ; = W  J .  ' 2 %  : H . J  A ' ( ; =  N  " &  6 , , 4 *
 .   B  ,
5t
h
Q  &    6 &  b  & „    
" $ & $ ( ( , ( $ 4 E    &  G   , 4 " &  6 ,    .  . % F ( =
\ [

[ Q Q   \ \ 
 P Q  #  i % 0   h :  %  
i
  (   j D ' 8 : . J  ?
H ( = = :  F  W H  ; A :  % 8  J : % ' = ( % J H 0 . J  A ' ( ; = 
  ' D ; ( 
 . % F ( = \

 Q
  \
 
534 Algoritmos y Técnicas de Programación Paralela
Aplicaciones
FSVC: Un Nuevo Codicador Escalable de Vídeo
M. F. López, V. G. Ruiz, S. G. Rodríguez, J. M. Dana, J. P. Ortiz y I. García
Departamento de Arquitectura de Computadores y Electrónica
Universidad de Almería
Resumen
FSVC (Fully Scalable Video Codec) es un
sistema de compresión escalable de vídeo ca-
paz de generar streams de vídeos comprimi-
dos con escalabilidad de calidad, temporal y
espacial. FSVC es adecuado para aplicaciones
VoD (Video-on-Demand) en las que un servi-
dor suele proveer vídeo a muchos clientes con
distintos requisitosdecaracterísticasde visua-
lización y ancho de banda. FSVC produce un
stream comprimido capaz de satisfacer estos
requisitos gracias a sus propiedades de escala-
bilidad. Los resultados experimentales obteni-
dos muestran que la eciencia de codicación
de FSVC es similar o superior a la de otros
codicadores de vídeo escalable.
1. Motivación
La codicación escalable de vídeo es una téc-
nica que permite que un stream de vídeo com-
primido sea descodicado de distintas formas.
Los clientes de vídeo reciben partes del stream
del vídeo comprimido según sus requerimien-
tos: frame-rate, resolución espacial, calidad de
imagen y/o bit-rate. El frame-rate se obtiene
por medio de la escalabilidad temporal; la es-
calabilidad espacial proporciona un conjunto
de resoluciones espaciales de las imágenes; la
mejoraprogresivadelacalidaddelaimagense
obtiene por la escalabilidad de calidad. Estos
tiposdeescalabilidadpuedencombinarseyde-
terminar un bit-rate que también puede estar
limitado por la capacidad de cómputo del des-
codicador o por el ancho de banda del canal
de transmisión. Por lo tanto, se puede gene-
ralizar la idea de escalabilidad al concepto de
escalabilidad de bit-rate.
Lacodicaciónescalableesunacaracterísti-
cafundamentalparalossistemasdealmacena-
mientoytransmisióndevídeo.Porejemplo,en
lasaplicacionesVoD,devídeopordemanda,el
computadorservidor envía unstream de vídeo
a un conjunto de clientes a través de enlaces
de transmisión de datos digitales. En muchas
situaciones la calidad, resolución y frame-rate
delasvisualizacionesquerequiereelclientede-
benadaptarsetambiénalascaracterísticasdel
descodicador y al ancho de banda de trans-
misión disponible en cada enlace. En este con-
texto, con codicación convencional de vídeo,
los requerimientos computacionales necesarios
en los servidores son proporcionales al núme-
ro y tipos de clientes puesto que o bien (1)
se crea una copia especíca del vídeo compri-
mido cumpliendo los requerimientos de cada
tipo de cliente, o bien (2) se utilizan técnicas
de transcoding para procesar el vídeo compri-
mido. La técnica (1) eleva las necesidades de
almacenamiento; la solución (2) requiere altas
capacidades de CPU y memoria que permi-
tan el procesado en tiempo real de los streams
de vídeo comprimido. La codicación escala-
ble de vídeo resuelve ambos problemas puesto
que sólo es necesario mantener una copia del
stream de vídeo almacenada en el servidor y
el preprocesamiento o transcoding se simpli-
ca.Elpreprocesamientoconsistiríasóloenuna
reordenación en la forma de transmitir los da-
toscomprimidos.Esunatareatansencillaque
puede ser realizada por el propio cliente, que
seleccionaría qué porciones del stream han de
enviarse.
En este trabajo presentamos el esquema de
un nuevo codec de vídeo escalable que hemos
denominado FSVC (Fully Scalable Video Co-
dec; Codicador de Vídeo Totalmente Esca-
lable) y mostramos la evaluación de su rendi-
miento como compresor de secuencias de vídeo
digital.
2. Descripción de FSVC
El compresor de vídeo que proponemos es
un sistema de codicación diferencial. Como
cualquier otro codec de vídeo, disminuye la re-
dundancia temporal del vídeo y la redundan-
cia espacial de cada frame de la secuencia de
vídeo. FSVC produce un stream comprimido
que es altamente escalable. El descodicador
FSVC recupera el vídeo exactamente idéntico
al original cuando recibe completamente los
datos comprimidos. En la Figura 1 se pue-
de ver el esquema de bloques funcionales de
FSVC.
La secuencia de imágenes de entrada pri-
mero se divide en GOFs (Group of Frames).
Cada GOF consta de varias imágenes consecu-
tivas y es codicado de forma independiente al
resto de GOFs. Esto permite que el descodi-
cador (1) pueda descodicar las imágenes de
cada GOF sin procesar el resto de GOFs y (2)
limite en el tiempo el error de drift en las si-
tuaciones en las que el descodicador no recibe
totalmente el vídeo comprimido.
La reducción de la redundancia temporal se
realiza con un esquema de codicación diferen-
cial MCTF (Motion Compensated Temporal
Filtering [1]) modicado. El movimiento entre
las distintas imágenes de la secuencia se mode-
liza de forma convencional: mediante vectores
que indican el movimiento de bloques cuadra-
dos (de tamaño jo) que forman las imáge-
nes. Estos vectores de movimiento los calcu-
la el módulo ME en el dominio de la imagen.
Para cada frame I[i] el módulo MC de com-
pensación del movimiento genera una imagen
predicción P[i]. MC usa los vectores de movi-
miento M[i] obtenidos por el módulo ME para
crear la mejor predicción posible que aproxima
el frame actual a codicar. El proceso de codi-
cación predictiva se lleva a cabo en el domi-
nio transformado wavelet para (1) minimizar
el desagradable efecto de blocking a bit-rates
bajos cuando esta operación se realiza en el
dominio de la imagen y para (2) eliminar el
error de drift en la escalabilidad espacial [2].
Por esto, cada frame I[i] se transforma usando
la DWT-2D antes de eliminar la redundancia
temporal. La predicción está formada por los
bloques obtenidos compensando el movimien-
to en las imágenes de referencia, que también
están en el dominio wavelet. En la determi-
nación de los bloques se usa la fase correcta
para evitar la no invariabilidad respecto al des-
plazamiento de la DWT [3]. En cada nivel de
resolución se utilizan los mismos vectores de
movimiento. La imagen a codicar y su pre-
dicción se restan, obteniendo así la secuencia
de residuos E, que tiene menor entropía que
la secuencia de imágenes originales I.
La codicación diferencial MCTF se realiza
en el dominio wavelet. El frame predicción está
compuesto de bloques wavelet de una imagen
previa en la secuencia de vídeo (bloques-P) y
por bloques de una imagen futura (bloques-N),
como se muestra en la Figura 2. Cuando no
es posible generar la predicción, se utiliza un
bloque intra (bloques-I). La Figura 2 muestra
cómo se genera la escalabilidad temporal. Por
ejemplo, el frame 5 se predice con los frames
1 y 9; el frame 3 se predice con los frames 1 y
5; y así hasta que se procesan todos los frames
del GOF. Cada bloque de un frame predicho,
puede ser predicho hacia delante (desde un fra-
me anterior) o hacia detrás (desde un frame
futuro). La elección entre predicción hacia de-
lante o hacia detrás se hace (1) minimizando
el error cuadrático medio MSE (Mean Square
Error) y (2) minimizando los errores de drift.
Los errores de drift se acumulan a lo largo de
las dependencias entre los frames predichos.
Por lo tanto, para el frame predicho 2, las pre-
dicciones hacia delante tienen mayor prioridad
que las predicciones hacia detrás porque, en el
descodicador, el frame 1 (cuyos bloques son
todos intra) será reconstruido con mayor o me-
nor calidad pero sin errores de drift, ya que es
un frame que se codica independientemente
de los demás.
Nótese que los frames de cada GOF se pre-
dicen con 2 frames intra (frames 1 y 9 de la
Figura 2). Esta característica no está permi-
tida en los conocidos estándares MPEG. Pe-
ro, para marcos de trabajo de vídeo escalable
538 Aplicaciones
Codicador
EBCOT
Descodicador
MC MC
ME
DWT-2D
I
I − P
E
M
E E
I + P
I
Inversa
DWT-2D
I I
P P
M M
Codicador
EBCOT
Codicador
Descod.
Descod.
Entrópico Entrópico
Figura 1: Diagrama de bloques de FSVC.
P
P P P P
N
P
P
P P
P
P
N
I
P P
P
P P P P
N
P
P
P P
P
P
N
I
P P
P
P P P P
N
P
P
P P
P
P
N
I
P P
N
P N
N
N N
N
P
N
I
N
N
N
N
I
N
N
P N
N
N N
N
P
N
I
N
N
N
N
I
N
N
P N
N
N N
N
P
N
I
N
N
N
N
I
N
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
Imagen
Referencia
N
N
I
I P
N
P
N
N
P
P
I P P
N N
Frame 2 Frame 3 Frame 4 Frame 5 Frame 6 Frame 7 Frame 8
I
I
I
I
I
I
I I I
I
I
I
I
I
I
I
Frame 9
I
I
I
I
I
I
I I I
I
I
I
I
I
I
I
Frame 1
Un Grupo de Frames/imágenes (GOF)
Nivel 4 de
Resolución
Temporal
Nivel 3 de
Temporal
Nivel 2 de
Resolución
Temporal
Nivel 1 de
Resolución
Temporal
Resolución
Figura 2: Ejemplo del esquema de codicación diferencial para un GOF de 8 imágenes (sólo se describe
para una subbanda de la DWT). El frame 9 está compartido con el siguiente GOF.
XVI Jornadas de Paralelismo, JP '2005 539
como el que nos ocupa, esta técnica permite
mejores reconstrucciones en el descodicador
porque los frames intra son compartidos por 2
GOFs.
Cada residuo E[i] se comprime usando el co-
dicador entrópico EBCOT [4] del estándar de
compresión de imágenes JPEG 2000. De esta
forma se genera una colección de paquetes que
forman parte del stream del vídeo comprimido.
Cada paquete es la contribución de un precin-
to P (una región espacial de la imagen) a una
capa de calidad L (un nivel de distorsión), pa-
ra una resolución espacial R, para una compo-
nente de color C y para un GOF G. El stream
de paquetes es fácilmente reordenable porque
la información que permite localizar cada pa-
quete también va incluida en el stream.
La información relativa al movimiento M
se comprime entrópicamente. Se ha utilizado
un codicador Human para eliminar la re-
dundancia estadística de los vectores de mo-
vimiento similar al de los estándares MPEG.
Estos datos han de ser descomprimidos com-
pletamente por el descodicador para poder
reconstruir el vídeo.
3. FSVC en Sistemas VoD
La mayoría de los sistemas VoD se im-
plementan usando una arquitectura cliente-
servidor. El stream de vídeo comprimido se al-
macena en el servidor y los clientes recuperan
los datos (o parte de ellos) para, descodicán-
dolos, visualizar la secuencia de vídeo. La codi-
cación escalable de vídeo es extremadamente
útil en esta clase de aplicaciones ya que, nor-
malmente, la transmisión completa del stream
de vídeo comprimido es imposible. Gracias a
las técnicas de escalabilidad, el sistema VoD
seleccionará qué paquetes han de ser trans-
mitidos en cada momento según las circuns-
tancias: características de las peticiones de los
clientes y ancho de banda disponible en los en-
laces de comunicación.
En el codec FSVC, la salida generada por el
compresor es una secuencia de paquetes que se
colocan en el stream de vídeo comprimido en
un orden determinado. El orden de transmi-
sión de los paquetes es importante porque de-
termina las características de las imágenes de
vídeo descodicadas cuando sólo una parte del
stream es recibida por el cliente. En nuestro
sistema FSVC el compresor selecciona el orden
(también llamado progresión) dependiendo de
los requerimientos de visualización:
1. La Progresión por calidad se usa si los
clientes necesitan preservar la resolución
espacial y frame-rate originales pero per-
mitiendo la variación contínua de la ca-
lidad de las imágenes que forman cada
GOF en función del bit-rate (o del ancho
de banda) disponible. Cualquier progre-
sión subordinada a GL- puede ser usada
con este propósito porque los paquetes se
organizan en el stream primero por GOF
(G) y después por capas de calidad (L).
2. La Progresión por resolución es pro-
porcionada por cualquier ordenación su-
bordinado a GR-. Usando estas progresio-
nes es posible descomprimir la secuencia
de vídeo a un nivel de resolución inferior
porque los paquetes de datos son envia-
dos por nivel de resolución dentro de cada
GOF.
3. La Progresión por frame-rate se usa
cuando la mayoría de los clientes requie-
ren visualizaciones que mantengan la re-
solución espacial del vídeo original a alta
calidad. En este caso se deberían utilizar
progresiones subordinadas a GT-.
Nótese que todas las progresiones propues-
tas son subordinadas a G-. Por lo tanto, es
sencillo acceder aleatoriamente a los GOFs de
la secuencia de vídeo porque pueden ser des-
comprimidos independientemente.
Como ya se ha explicado anteriormente, es
importante resaltar que el ordenación por de-
fecto de los paquetes puede ser modicado en
tiempo real por los clientes dependiendo de sus
propios requerimientos. Por ejemplo, si el nú-
mero de precintos usado es lo sucientemente
grande, un cliente puede recuperar los paque-
tes que mejoren (con respecto al resto de la
imagen) la calidad de una región (estática o en
movimiento) de interés (ROI Region Of Inte-
rest [5]) que aparezca en la secuencia de vídeo.
540 Aplicaciones
Tabla 1: Resumen de FSVC y RWMH: SF =
Filtros espaciales, SRL = Niveles de resolu-
ción espacial, TF = Filtros temporales, TRL
= Niveles de resolución temporal, MC-PA =
Precisión de píxel, EoR = Codicación de los
residuos, EoMI = Codicación de los vectores
de movimiento.
FSVC RWMH
SF Biortog. 9/7 Biortog. 9/7
SRL 4 1
TF Bidirecc. 1/1 IPPP...
TRL 5 -
MC Tam. bloq. jo Tam. bloq. jo
MC-PA 1/1 1/8
EoR EBCOT SPIHT
EoMI Cod. Human Cod. Human
4. Resultados experimentales
Se han realizado diversos experimentos pa-
ra testear la eciencia de la codicación esca-
lable de FSVC que hemos implementado. He-
mos empleado dos secuencias de vídeo amplia-
mente utilizadas en el campo de la compresión
de vídeo: ower garden y tempete. El formato
elegido ha sido CIF (352 x 288 píxeles) a 30
Hz de frame-rate (30 frames/sg). En los ex-
perimentos hemos comparado la eciencia de
codicación de FSVC con otro codicador de
vídeo escalable que está siendo desarrollado en
la actualidad y que se denomina RWMH (Re-
dundant Wavelet Multi-Hypothesis Cui et al.
[6]). Se presentan resultados de eciencia de
codicación y calidad visual en un escenario
de progresión por calidad. Esta progresión es
la más común en aplicaciones VoD y posee un
grano de escalabilidad muy no.
FSVC y RWMH presentan una complejidad
computacional similar. La implementación de
RWMH que han realizado los propios autores
es software de libre distribución disponible en
Internet. La Tabla 1 describe los parámetros
empleados por FSVC y RWMH para compri-
mir las secuencias de vídeo de test.
En los experimentos realizados hemos com-
primido la componente de luminancia de las
secuencias de test ower garden y tempete.
19.5
20
20.5
21
21.5
22
22.5
23
23.5
24
24.5
640
512
384
256
PSNR
[dB]
Kbps
flowergarden CIF 30-Hz
FSVC
RWMH
Figura 3: Valores medios de PSNRs para la secuen-
cia ower garden.
Las descodicaciones con ambos descompre-
sores se han realizado siguiendo una progre-
sión por calidad y, en concreto, en el caso de
FSVC, utilizando la progresión GLTRCP. Pa-
ra describir un poco mejor la conguración de
FSVC añadir que cada GOF está formado por
16 frames, por lo que se dispone de 4 niveles
de resolución temporal (4 TRLs). Cada frame
se codica usando 16 niveles de calidad y 4
niveles de resolución espacial (4 SRLs). Como
sólo codicamos la componente de luminancia,
C = 1 en GLTRPC. Se ha usado un precinto
por nivel de resolución. Por lo tanto, cada capa
de calidad está compuesta de 16×4×1×1 = 64
paquetes y cada GOF tiene 16×64 = 1024 pa-
quetes. Los primeros n paquetes de cada GOF
se descodicarán dependiendo del bit-rate dis-
ponible. Las descodicaciones se han efectua-
do a 256, 384, 512 y 640 kbps.
Las imágenes reconstruidas con FSVC han
sido obtenidas comprimiendo a alta calidad y
descodicando al bit-rate deseado. De esta for-
ma, estas reconstrucciones han de presentar
errores de drift, aunque minimizados debido
al ltrado temporal que realiza FSVC. Sin em-
bargo, el bit-rate es un parámetro que sólo se
puede seleccionar en la parte del codicador
RWMH, en el momento de la compresión; no
puede ser elegido por el descodicador. Esto
es debido a la implementación proporcionada
XVI Jornadas de Paralelismo, JP '2005 541
23
23.5
24
24.5
25
25.5
26
26.5
27
27.5
640
512
384
256
PSNR
[dB]
Kbps
tempete CIF 30-Hz
FSVC
RWMH
Figura 4: Valores medios de PSNRs para la secuen-
cia tempete.
por el autor, no a limitaciones del esquema del
codec, y causa el que las imágenes descodi-
cadas con RWMH estén articialmente libres
de errores de drift. A pesar de ello, como se
puede ver en las Figuras 3 y 4, FSVC muestra
una eciencia entre 0,5 y 1,0 dB por encima
de los valores de PSNR medio obtenidos pa-
ra RWMH. FSVC es especialmente superior a
bajos bit-rates. El mejor rendimiento que de-
muestra FSVC posiblemente es debido prin-
cipalmente a que (1) la eciencia de codica-
ción de EBCOT es superior a la de SPIHT
(que es el algoritmo codicador empleado por
RWMH) y a (2) el esquema de ltrado tempo-
ral que usa FSVC, en el cual cada frame intra
es compartido por dos GOFs.
La Figura 5 muestra una comparación vi-
sual entre las reconstrucciones efectuadas con
FSVC y RWMH. A la izquierda se pueden ver
imágenes de ower garden y tempete recons-
truidas con el descodicador FSVC a 256 y
512 kbps. A la derecha están ubicadas las ob-
tenidas con RWMH. A 256 kbps FSVC es cla-
ramente superior. A 512 kbps ambos codecs
parecen obtener calidad parecida, sin embar-
go, poniendo un poco de atención visual, algu-
nos elementos están mejor reconstruidos con
FSVC. La farola de ower garden y el tron-
co de madera vertical de tempete están mejor
detallados en las imágenes descodicadas con
FSVC.
542 Aplicaciones
FSVC RWMH
512
Kbps
256
Kbps
512
Kbps
256
Kbps
Figura 5: Comparación subjetiva visual entre FSVC y RWMH.
XVI Jornadas de Paralelismo, JP '2005 543
5. Conclusiones
FSVC está basado en el esquema de codi-
cación escalable de vídeo DWT-1D temporal
en el dominio transformado. Se han intenta-
do solucionar algunas deciencias del esque-
ma, además de añadir nuevas características
deseables. FSVC utiliza elementos de JPEG
2000 y una variación de la técnica de ltrado
temporal MCTF para eliminar la redundancia
temporal en la señal de entrada al codicador.
FSVC proporciona escalabilidad de grano no
por calidad del stream de vídeo comprimido
que genera. Estas características son ideales
para los sistemas de vídeo por demanda VoD
y streaming de vídeo por Internet.
Además, los experimentos comparativos que
hemos realizado con RWMH, uno de los co-
decs escalables de vídeo que está siendo desa-
rrollado experimentalmente en la actualidad,
demuestran que FSVC consigue mayor ecien-
cia de codicación, siendo la complejidad com-
putacional de ambos codecs similar. Tanto el
análisis objetivo como el subjetivo han mos-
trado la superioridad de FSVC.
Referencias
[1] S.-J. Choi and J.W. Woods, Motion com-
pensated 3-D subband coding of video,
IEEE Transactions of Image Processing,
1999.
[2] Y. Andreopoulos, M. Van der Schaar, A.
Munteanu, J. Barbarien, P. Schelkens and
J. Cornelis, Fully-scalable wavelet video
coding using in-band motion compensa-
ted temporal ltering, Proceedings of the
IEEE International Conference on Acous-
tics, Speech, and Signal Processing, 2003.
[3] M. J. Shensa, The discrete wavelet trans-
form: weeding the Á Trous and Mallat
algorithms, IEEE Transactions on Signal
Processing, 1992.
[4] D. Taubman, High performance scalable
image compression with EBCOT, IEEE
Transactions on Image Processing, 2000.
[5] A. Skodras, C. Christopoulos and T.
Ebrahimi, The JPEG 2000 Still Image
Compression Standard, IEEE Signal Pro-
cessing Magazine, 2001.
[6] S. Cui, I. Wang and J. E. Fowler, Mul-
tihypothesis Motion Compensation in the
Redundant Wavelet Domain, Proceedings
of the International Conference on Image
Processing, 2003.
544 Aplicaciones
On the use of parallel computing to process multichannel
imagery via extended morphological operations
Antonio Plaza, Pablo Martínez, David Valencia, Isabel García, Javier Plaza
Dept. de Arquitectura y Tecnología de Computadores
Escuela Politécnica de Cáceres, Universidad de Extremadura
Avda. de la Universidad s/n
10071 Cáceres
aplaza@unex.es
Abstract
Multichannel images are characteristic of certain
applications, such as medical imaging or remotely
sensed data analysis. In such images, each pixel is
given by a vector of values. Due to the large data
volumes often associated with multichannel
imagery, there is a need for parallel algorithms
able to process those data quickly enough for
practical use. This paper describes a parallel
implementation of a multichannel image
processing algorithm that naturally combines
spatial and spectral/temporal information. The
algorithm combines a vector-preserving approach
to extend morphological operations to
multichannel images with the watershed
transformation used in morphological processing,
It is evaluated using remotely sensed
hyperspectral data collected by the NASA’s Jet
Propulsion Laboratory Airborne Visible Infra-Red
Imaging Spectrometer (AVIRIS).
1. Introduction
Multichannel images are defined over the
common spatial definition domain. It follows that,
in multichannel image data, a vector of values
rather than a single value is associated with each
spatial location.
Many types of multichannel images exist
depending on the type of information collected for
each image pixel. For instance, color images are
multichannel images with three channels, one for
each primary color in the RGB space. Images
optically acquired in more than one spectral or
wavelength interval are called multispectral [1].
These images are characteristic in satellite
imaging and aerial reconnaissance applications.
The number of spectral channels can be extremely
high, as in the case of hyperspectral images
produced by imaging spectrometers. Finally, all
image types above can be extended to the class of
multitemporal images or image sequences, which
consist of series of images defined over the same
definition domain, but collected at more than a
single time. Examples include magnetic resonance
(MR) images in medical applications and video
sequences.
One of the most successful techniques for
image analysis in the recent literature has been
mathematical morphology [2], which relies on the
definition of a structuring element (SE) which is
translated over the image, and acts as a probe for
extracting or suppressing specific structures of the
image objects. Based on this idea, two
fundamental operators are defined in
mathematical morphology: erosion and dilation.
The application of the erosion operator to an
image yields an output image, which shows where
the SE fits the objects in the image. On the other
hand, the application of the dilation operator to an
image produces an output image, which shows
where the SE hits the objects in the image. All
other morphological operations are expressed in
terms of erosion and dilation.
For instance, the most important
morphological approach for segmenting an image
is the watershed transformation [3], which
consists of a combination of seeded region
growing and edge detection. It relies on a marker-
controlled approach that considers the image data
as imaginary topographic relief; the brighter the
intensity, the higher the corresponding elevation.
Let us assume that a drop of water falls on such a
topographic surface. The drop will flow down
along the steepest slope path until it reaches a
minimum. The set of points of the surface whose
steepest slope path reach a given minimum
constitutes the catchment basin associated with
that minimum, while the watersheds are the zones
dividing adjacent catchment basins.
Despite its encouraging results in, among
others, industrial applications, object
identification, security control, and image coding,
mathematical morphology-based techniques such
as the watershed transform have not been fully
exploited in multichannel image analysis, mainly
due to the fact that the price paid for the wealth of
spatial and spectral/temporal information in
certain applications is an enormous amount of
data to be processed [4].
Parallel processing and the new processing
power offered by commodity cluster-based
systems [5] can help to tackle large
multidimensional image data sets and to get
reasonable response times in complex image
analysis scenarios [6]. Thanks to the geographic
local organization of the pixels of an image as a 2-
D mesh, and to the regularity of most low-level
computations, mesh-based parallel architectures
have become quite popular for image analysis
applications since they allow for efficient
implementations of basic neighbor-based
primitives [7]. However, the development of
appropriate parallel analysis techniques for joint
spatial and spectral/temporal analysis has not been
fully explored yet in the literature.
This paper describes a new parallel algorithm
that allows for efficient exploitation of
multichannel image data via an extended
watershed transform. The algorithm was
specifically designed to be run on similar
computing nodes employed in a stand-alone
manner. A quantitative cost-performance
evaluation of the algorithm is provided, using
Thunderhead, a 256-processor commodity cluster
at NASA’s Goddard Space Flight Center.
2. Extended mathematical morphology
Our attention in this section focuses primarily on
the development of a mechanism to extend basic
morphological operations to multichannel imagery
[8].
A simple approach consists in applying
monochannel techniques to each image channel
separately, an approach usually referred to as
“marginal” morphology in the literature. This
approach is unacceptable in many applications
because, when morphological techniques are
applied independently to each image channel,
there is a possibility for loss or corruption of
information of the image due to the probable fact
that new pixel vectors (i.e., not present in the
original image domain) may be created as a result
of processing the channels separately. In addition,
no correlation between spectral/temporal
components is taken into account.
An alternative way to approach the problem of
multidimensional morphology is to treat the data
at each pixel as a vector [9]. Since there is no
unambiguous means of defining the minimum and
maximum values between two vectors of more
than one dimension, it is important to define an
appropriate arrangement of vectors in vector
space. In this paper, we adopt a distance-based
technique based on a cumulative distance between
one particular pixel vector ( )
y
x,
f , where ( )
y
x,
indicates the spatial coordinates, and all the pixel
vectors in the spatial neighborhood given by
structuring element B ( B -neighborhood) as:
( ) ( )
( )
∑
=
t
,
s
)
t
,
s
(
),
y
,
x
(
Dist
)
y
,
x
(
C f
f
f
B
where Dist is the spectral angle distance. As a
result, ( )
)
y
,
x
(
C f
B is given by the sum of Dist
scores between ( )
y
x,
f and every other pixel
vector in the B -neighborhood. To be able to
define the standard morphological operators in a
complete lattice framework, we need to be able to
define a supremum and an infimum given an
arbitrary set of vectors { }
p
v
v
v ,...,
,
S 2
1
= , where p
is the number of vectors in the set. This can be
done by computing
( ) ( ) ( ) ( )
{ }
p
B
B
B
B v
v
v C
,
,
C
,
C
S
C 2
1 ⋅
⋅
⋅
= and
selecting j
v such that ( )
j
B v
C is the minimum of
( )
S
CB , with p
j ≤
≤
1 . In similar fashion, we can
select k
v such that ( )
k
B v
C is the maximum of
( )
S
CB , with p
k ≤
≤
1 . Based on the simple
definitions above, the flat extended erosion of f
by B , denoted by B
Θ
f , consists of selecting of
the B -neighborhood pixel vector that produces
the minimum B
C value. On other hand, the flat
extended dilation of f by B , i.e., B
⊕
f ,
selects the B -neighborhood pixel that produces
the maximum value for B
C . The multichannel
morphological gradient at ( )
y
x,
f using B can
be simply defined as follows [10]:
( ) ( ) ( )
( )
)
y
,
x
(
),
y
,
x
(
Dist
)
y
,
x
(
G B
B
B ⊗
⊕
= f
f
f
546 Aplicaciones
3. Multichannel watershed algorithm
Our multichannel watershed segmentation
algorithm consists of three stages. First,
multidimensional morphological operations are
used to collect a set of minima according to some
measure of minima importance. Starting from the
selected minima and using the multidimensional
morphological gradient as a reference, a
multichannel watershed transformation by
flooding is then applied. Finally, watershed
regions are iteratively merged, according to a
similarity criterion, to obtain the final
segmentation.
3.1. Minima selection
The key of an accurate segmentation resides in the
first step, that is, the selection of “markers” or
minima from which the transform is started.
Following a recent work [3], we hierarchically
order all minima according to their deepness, and
then select only those above a threshold [11]. The
deepness of a basin would be the level the water
would reach, coming in through the minimum of
the basin, before the water would overflow into a
neighbor basin.
Deepness can be computed using
morphological reconstruction applied to the
multichannel gradient. Reconstruction is a special
class of morphological transformation that does
not introduce discontinuities. Given a “flat” SE
designed by B , and the multichannel gradient
( )
f
B
G of an n-dimensional image f , it can be
proven that the morphological reconstruction of
( )
f
B
G from ( ) B
B ⊗
f
G will have a watershed
transform in which the regions with deepness
lower than a certain value v have been joined to
the neighbor region with closer spectral
properties. Subsequently, the parameter v can
serve as a minima selection threshold.
3.2. Flooding
Let the set { }
k
p
p
p ,...,
,
P 2
1
= denote the set of k
minimum pixel vectors selected after
multidimensional minima selection. Similarly, let
the catchment basin associated with a minimum
pixel i
p be denoted by ( )
i
p
CB . All the points in
this catchment basin which have an altitude less
than or equal to a certain deepness score. The
catchment basins is progressively created by
simulating the flooding process. The first pixel
vectors reached by water are the points of highest
deepness score. From now on, the water either
expands the region of the catchment basin already
reached by water, or starts to flood the catchment
basin whose minima have a deepness equal to
( )
l
B
D p , where l
p is the deepest pixel in the set
of { }
j
p
−
P . This operation is repeated until
∅
=
P .
3.3. Region merging
To obtain the final segmentation, some of the
regions ( )
{ }k
i
i 1
CB =
p resulting from the watershed
can be merged to reduce the number of regions.
First, all regions are ordered into a region
adjacency graph (RAG). Each edge in the RAG is
assigned a weight, so that the weight of an edge
( )
j
i p
p ,
e is the value of ( )
j
i p
p ,
Dist . Regions
( ) ( )
j
i p
p CB
,
CB can be merged attending to
spatial properties in the case of adjacent regions,
and also according to pixel vector similarity
criteria in the case of non-adjacent regions.
4. Parallel implementation
Parallelization of watershed algorithms that
simulate flooding is not a straightforward task.
The watershed process has a very volatile
behavior, starting with a high degree of
parallelism that very rapidly diminishes to a much
lower degree of parallelism [12]. In this section,
our goal is to develop an efficient and scalable
parallel implementation of the algorithm proposed
in the previous section. Design features such as
partitioning, task replication and communication
are discussed.
4.1. Partitioning
Two types of partitioning strategies can be applied
to our problem. One may decide whether the
computation associated with the given problem
should be split into pieces (functional
decomposition), or the data on which the
XVI Jornadas de Paralelismo, JP '2005 547
computation is applied (domain decomposition).
Functional decomposition is inappropriate for
segmentation with watersheds, where a sequence
of operators are applied in a chain to the entire
image. Our parallel algorithm uses domain
decomposition, that is, the original multichannel
image f is decomposed into subimages, where
each subimage is made up of entire pixel vectors,
i.e. a single pixel vector is never split amongst
several processing elements (PEs). There are
several reasons for the above decision. First, this
is a natural approach for low-level image
processing, as many operations require the same
function to be applied to a small set of elements
around each data element present in the image
data structure. A second reason has to do with the
cost of inter-processor communication. If the
computations for each pixel vector need to
originate from several PEs, then they would
require intensive inter-processor message passing.
Figure 1. Morphological structuring element
computation split between two processors.
4.2. Task replication
An important issue in SE or kernel-based image
processing operations is that accesses to pixels
outside the domain f
D of the input image are
possible. For instance, when the SE is centered on
a pixel located in the border of the original image,
a simple border-handling strategy can be applied
to indicate that only pixels inside the input image
domain will be taken into account in the SE-based
computation. However, when such a border effect
happens in a local partition i
f
D , then additional
inter-processor communications may be required
when the structuring element computation needs
to be split amongst several different processing
nodes, as shown by Fig. 1. In the example, the
computations for the pixel vector at spatial
location ( )
3
,
5 need to originate from two
processors, and a communication overhead
involving three pixel vectors is introduced. In
order to avoid such an overhead, edge/corner
pixels are replicated in the neighboring processors
whose subdomains are thus enlarged with a so-
called extension area. It should be noted that the
task-replication strategy above enhances code
reusability, which is highly recommended in order
to build a robust parallel algorithm.
4.3. Implementation
Our implementation of the parallel multichannel
watershed algorithm uses a simple master-slave
model. The master processor reads the whole
multichannel image f and divides it into a set of
multichannel subimages i
f which are sent to
different processors. The slave processors run the
segmentation algorithm on the respective
subimages and also exchange data among
themselves for uniform segmentation. After the
segmented regions become stable, the slaves send
the output to the master, which combines all of
them in a proper way and provides the final
segmentation. If we assume that the parallel
system has p processors available, then one of
the processors is reserved to act as the master,
while each of the remaining 1
-
p processors
create a local queue i
Q with 1
-
i
1 p
≤
≤ . The
minima selection algorithm is run locally at each
processor to obtain a set of minima pixels
surrounded by non-minima, which are then used
to initialize each queue i
Q . Flooding is then
performed locally in each processor as in the
serial algorithm.
It should be noted that, due to the image
division, flooding is confined only to the local
subdomain. There may exist parts of the subimage
that cannot be reached by flooding since they are
contained in other subimages. Our approach to
deal with this problem is to first flood locally at
every deepness score in the subimage. Once the
local flooding is finished, each processor
exchanges segmentation labels of pixels in the
boundary with appropriate neighboring
548 Aplicaciones
processors. Subsequently, a processor can receive
segmentation labels corresponding to pixels in the
extended subdomain. The processor must now
“reflood” the local subdomain from those pixels, a
procedure that may introduce changes in
segmentation labels of the local subdomain.
Communication and reflooding are again repeated
until stabilization (i.e. no more changes occur).
Performance data for the parallel algorithm are
given in the following subsection.
5. Experimental results
This section reports on the effectiveness of the
proposed parallel segmentation algorithm in a
specific application, where remotely sensed
hyperspectral imagery data with hundreds of
spectral channels as collected by the by the
NASA’s Jet Propulsion Laboratory Airborne
Visible Infra-Red Imaging Spectrometer
(AVIRIS) are used to test the performance of the
algorithm in a complex remote sensing
classification scenario. The section is organized as
follows. First, we provide an overview of the
parallel computing architectures used for
evaluation purposes. Second, a detailed
computational cost-performance analysis of our
parallel algorithm is given.
5.1. Parallel computing architectures
The parallel computing architecture used in
experiments is the Thunderhead Beowulf cluster
at NASA’s Goddard Space Flight Center
(NASA/GSFC) (see Fig. 2). The Thunderhead
system can be seen as an evolution of the HIVE
(Highly Parallel Virtual Environment) project,
started in 1997 to build a commodity cluster
intended to be exploited by different users in a
wide range of scientific applications. The idea was
to have workstations distributed among many
offices and a large number of compute nodes (the
compute core) concentrated in one area.
Thunderhead is currently composed of 256
dual 2.4 Ghz Intel Xeon nodes, each with 1 Gb of
memory and 80 Gb of main memory. The total
peak performance of the system is 2457.6 Gflops.
Despite the computational power offered by
Thunderhead, the system cost was relatively cheap
(about 220K in 2001). It has been recently
reported that the cost of an SGI Origin
multicomputer with exactly the same
specifications as the Thunderhead Beowulf cluster
is more than 20 times greater than that of the
cluster. Along with the 512-processor computer
core, Thunderhead has several nodes attached to
the core with 2 Ghz optical fibre Myrinet. Our
parallel algorithm was run from one of such
nodes, called thunder1. The operating system used
at the time of experiments was Linux RedHat 8.0,
and MPICH was the message-passing library
used.
Figure 2. Thunderhead Beowulf cluster at NASA’s
Goddard Space Flight Center.
5.2. Computational cost-performance analysis
The image data set used in experiments is a 224-
band AVIRIS scene taken at a low altitude with a
3.7 meter-pixel size. The data set was collected
over an agricultural test site located in Salinas
Valley, California, and represents a challenging
segmentation problem. Fortunately, extensive
ground-truth information is available for the area,
allowing a quantitative assessment in terms of
segmentation accuracy. Fig. 3(a) shows the entire
scene and a sub-scene of the dataset (called
hereinafter Salinas A), dominated by directional
regions. Fig. 3(b) shows the 15 available ground-
truth regions, which comprise nearly half of the
entire scene. The imaged data consists of a
relatively large area (512 lines by 217 samples),
where the total size of the image exceeds 100
Mbytes.
XVI Jornadas de Paralelismo, JP '2005 549
Figure 3. (a) Spectral band at 488 nm of an AVIRIS hyperspectral image comprising several agricultural fields in
Salinas Valley, California, and a sub-scene (Salinas A), outlined by a white rectangle. (b) Land-cover ground classes.
The large data volume in the AVIRIS image
described in Fig. 3 creates the need for parallel
watershed-based analysis strategies, able to
produce segmentation results quickly enough for
practical use. In experiments, the best
segmentation results were obtained when a disk-
shaped structuring element (SE) of 15-pixel
radius, denoted by ( )
disk
15
B , was used. This is
mainly due to the relation between the SE and the
spatial properties of regions of interest in the
scene. Specifically, the usage of the SE above
resulted in a classification accuracy above 92%.
Interestingly, classification scores were even
higher for the Salinas A subscene, which contains
several lettuce fields at different weeks since
planting (4, 5, 6 and 7 weeks, respectively), and
covering the soil in different proportions. These
classes represent a very complex analysis scenario
due to the presence of different proportions of
mixing between soil and lettuce at the different
classes. Overall, the classification results above
revealed that the proposed algorithm could
achieve very accurate segmentation results in a
complex analysis scenario given by agricultural
classes with very similar spectral features.
However, the algorithm required several hours of
computation in a single-processor PC with AMD
Athlon 2.6 GHz processor and 512 Megabytes of
RAM. This created the need for a parallel
implementation.
In order to investigate the efficiency of our
parallel multichannel watershed algorithm, we
implemented the algorithm using the C++
programming language with calls to message
passing interface (MPI). The parallel code was
tested on the Thunderhead massively parallel
cluster. Table 1 shows execution times in seconds
of the parallel algorithm with the AVIRIS scene
for ( )
disk
15
B and different number of processors. As
shown by Table 1, processing times were
considerably reduced as the number of processors
was increased, although it was not required to use
a very large number of processors to obtain results
in moderate processing times. For instance, 36
processors were required to produce an accurate
segmentation result in less than ten minutes.
550 Aplicaciones
In order to further analyze the scalability of
the parallel code, Fig. 4 plots the speed-up factors
achieved by the parallel algorithm over a single-
processor run of the algorithm as a function of the
number of processors used in the parallel
computation. Results in Fig. 4 reveal that the
parallel algorithm obtained reasonably good
scalability on Thunderhead. In particular, the
achieved speed-up factors were better for large
SEs, a fact that reveals that the proposed parallel
implementation is more effective as the volume of
computations increases. It should be noted that
classification results using ( )
disk
3
B , ( )
disk
7
B and
( )
disk
11
B were always below 84% accuracy.
Processors Execution time Speed-up
1 16234 1.00
4 5026 3.23
16 1445 11.23
36 551 29.45
64 424 39.34
100 282 57.45
144 221 73.28
196 181 89.34
256 165 98.23
Table 1. Execution time (in seconds) and speed-up
achieved by the parallel watershed algorithm for
different numbers of processors.
0
30
60
90
120
4 46 88 130 172 214 256
Number of processors
Speedup
( )
disk
3
B
( )
disk
7
B
( )
disk
11
B
( )
disk
15
B
Figure 4. Speed-up factors achieved by the parallel
algorithm as a function of the number of processors.
Finally, in order to investigate load balance
[12], Fig. 5 shows the execution times for of the
parallel algorithm for each of the processors on
Thunderhead for a case study where 64 processors
were used in the parallel computation, where one
processor presents a slightly higher computational
load as compared to the other processors. This
comes at no surprise because the root processor is
in charge of data partitioning, and also combines
the partial results provided by every processor. It
can be seen, however, that load balance is much
better among the rest of the processors.
0
150
300
450
1 10 19 28 37 46 55 64
Processor
Execution
time
(seconds)
Figure 5. Execution times in seconds achieved for each
of the processors for a case study with 64 processors.
6. Conclusions and future lines
The aim of this paper has been the
development of a parallel implementation on
massively parallel computers of an innovative
technique for unsupervised classification of
multichannel image data sets, with the purpose of
obtaining results in valid response times and with
adequate reliability. For this purpose, computing
systems made up of arrays of commercial off-the-
shelf computing hardware are a cost-effective way
of exploiting this sort of parallelism in remote
sensing applications. The proposed MPI-based
parallel implementation of a morphological
watershed algorithm, tuned for multiple
dimensions, minimizes inter-processor
communication overhead, thus enhancing
processor load balance. Besides, it is independent
of the number of processors, and can be ported to
any type of distributed memory system.
Experimental results reveal that the parallel
algorithm achieved good results in terms of
segmentation accuracy, speed-up, scalability and
load balance in the context of a high-dimensional
image analysis application, dominated by large
data volumes and complex patterns of
communication and calculation.
XVI Jornadas de Paralelismo, JP '2005 551
As future work, we plan to implement the
parallel algorithm in other high performance
parallel computing architectures, such as
massively parallel computers available at the
European Center for Parallelism of Barcelona
(CEPBA) and CSC (Centro de Supercomputación
Complutense) of Madrid, Spain, and also to fully
heterogeneous networks and Grids. Our major
future goal is to integrate the algorithm in
applications with near real-time requirements,
such as detection and/or tracking of natural
disasters. Specifically, the proposed algorithm
may be of great utility to detect and monitor forest
fires, such as those that recently happened in the
Extremadura region in SW Spain. In the near
future, we will work towards the integration of the
proposed parallel watershed algorithm onto an
automated forest fire tracking system in
conjunction with Junta de Extremadura (local
government).
Acknowledgement
This research was supported by the European
Commission through the project entitled
“Generation of test images to validate the
performance of endmember extraction and
hyperspectral unmixing algorithms.” (contract no.
HPRI–1999–00057). Additional funding from
Junta de Extremadura (local government) through
2PR03A026 project is also gratefully
acknowledged. The authors would like to state
their appreciation for Professors Mateo Valero
and Francisco Tirado; without their collaboration,
the present research effort could not have been
possible. The first author would also like to
acknowledge support provided by the Spanish
Ministry in order to conduct research as
postdoctoral associate at NASA’s Goddard Space
Flight Center in Maryland.
References
[1] Green, R. O. Imaging spectroscopy and the
airborne visible/infrared imaging spectrometer
(AVIRIS). Remote Sensing of Environment,
65, 227–248, 1998.
[2] Soille, P. Morphological image analysis,
principles and applications, second edition.
Berlin: Springer, 2003.
[3] Malpica, N., Ortuño, J. E., Santos, A. A
multichannel watershed-based algorithm for
supervised texture segmentation. Pattern
Recognition Letters, 24, 1545-1554, 2003.
[4] Valencia, D., Plaza, A., Martinez, P. On the
use of cluster computing architectures for
implementation of hyperspectral analysis
algorithms. Tenth IEEE Symp. on Computers
& Communications, Cartagena, 2005.
[5] Dorband, J., Palencia, J., Ranawake, U.
Commodity computing clusters at Goddard
Space Flight Center. Journal of Space
Communication, vol. 1, no. 3, 2003.
[6] Tilton, J.C. A recursive PVM implementation
of an image segmentation algorithm with
performance results comparing the HIVE and
the Cray T3E. Proc. Symposium on Massively
Parallel Computation, Maryland, 1999.
[7] Seinstra, J., Koelma, D., Geusebroek, J.M. A
software architecture for user transparent
parallel image processing. Parallel
Computing, vol. 28, pp. 967-993, 2002.
[8] Plaza, A., Martinez, P., Perez, R., Plaza, J.
Spatial/spectral endmember extraction by
multidimensional morphological operations.
IEEE Transactions on Geoscience and Remote
Sensing, 40(9), 2025-2041, 2002.
[9] Plaza, A., Martinez, P., Perez, R., Plaza, J. A
new approach to mixed pixel classification of
hyperspectral imagery based on extended
morphological profiles. Pattern Recognition,
37, 1097-1116, 2004.
[10] Plaza, A., Martinez, P., Plaza, J., Perez, R.
Dimensionality reduction and classification of
hyperspectral image data using sequences of
extended morphological transformations.
IEEE Transactions on Geoscience and Remote
Sensing, vol. 43, no. 3, pp. 466-479, 2005.
[11] Plaza, A., Martinez, P., Perez, R., Plaza. J. A
quantitative and comparative analysis of
endmember extraction algorithms from
hyperspectral data, IEEE Transactions on
Geoscience and Remote Sensing, vol. 42, no.
3, pp. 650-663, 2004.
[12] Gil, M., Gil, C., Garcia, I. The load
unbalancing problem for region growing
image segmentation algorithms. Journal of
Parallel and Distributed Computing, vol. 63,
pp. 387-395, 2003.
552 Aplicaciones
Coprocesador consejero para la compresión de imágenes en
sistemas de observación terrestre
Antonio Guzmán Marta Beltrán
Dept.de Informática, Estadística y Telemática Dept.de Informática, Estadística y Telemática
Área de Arquitectura de Computadores Área de Arquitectura de Computadores
Universidad Rey Juan Carlos Universidad Rey Juan Carlos
ESCET ESCET
28933 Móstoles, Madrid (SPAIN) 28933 Móstoles, Madrid (SPAIN)
antonio.guzman@urjc.es marta.beltran@urjc.es
Resumen
En este trabajo se presenta el primer pro-
totipo de un coprocesador para preproce-
samiento de imágenes sobre una plataforma
reconfigurable. Este coprocesador está diseña-
do para ser incorporado en un satélite de ob-
servación terrestre con una gran frecuencia
de captura de imágenes por lo que resulta
imprescindible optimizar su rendimiento. Para
ello se han explorado todas las alternativas
de paralelismo en la arquitectura propuesta,
pero siempre utilizando técnicas de alto nivel,
ya que para la primera especificación de este
prototipo se ha utilizado un leguaje de especi-
ficación hardware de alto nivel. La principal
contribución de este trabajo es la verificación
de que es posible aplicar con exito técnicas
que tradicionalmente corresponden a diseños
software, al diseño de arquitecturas hardware.
1. Introducción
Actualmente los sistemas espaciales de obser-
vación terrestre han conseguido aumentar sus
capacidades de captura de imágenes en tér-
minos de resolución y frecuencia de muestreo.
Estas mejoras han obligado a modificar el mo-
do tradicional de operación incluyendo sis-
temas para la compresión de imágenes. Me-
diante la reducción del tamaño de la imagen,
se consigue una mejora global en el rendimien-
to de todo el sistema. Sin embargo, mantener
la calidad de la imagen transferida depende de
la elección que se haya efectuado a la hora de
realizar la compresión. En una primera clasi-
ficación se puede distinguir entre algoritmos
de compresión sin pérdidas y algoritmos con
pérdidas. En la actualidad, la solución que se
propone es la de implementar los sistemas de
forma que se decida en fase de diseño que tipo
de compresión se va a efectuar, fijando con ello
la calidad máxima de las imágenes que el sis-
tema transferirá o almacenará una vez sean
capturadas ([1] y [2]).
La compresión en sistemas de observación
terrestre debe cumplir con dos requisitos prin-
cipalmente: un aprovechamiento óptimo de los
recursos disponibles y un excelente rendimien-
to en el proceso de compresión. Además, a
cualquier sistema que vaya a empotrarse en un
satélite se le exige bajo consumo y debe estar
homologado para el espacio, es decir, debe ser
capaz de operar en un entorno muy agresivo y
a prueba de fallos, ya que son sistemas imposi-
bles de reparar después del lanzamiento. El es-
tándar JPEG2000 cumple satisfactoriamente
con todos estos requisitos alcanzando altas co-
tas de rendimiento en sus dos modos de ope-
ración, con o sin pérdidas([3] y [4]). Por otro
lado, los avances en la fabricación de FPGAs,
garantizando su resistencia a la radiación, han
conducido en los últimos años a la utilización
de hardware reconfigurable en el espacio. Al-
gunos ejemplos de sistemas de compresión de
imágenes desarrollados en FPGAs son [5] y [6]
En este artículo se propone una alteración
al modo actual de operación en la transmisión
de imágenes. A la fases establecidas de cap-
tura, compresión, almacenamiento y descarga,
se les añade una fase de preproceso, previa a
la compresión. El objetivo de esta nueva fase
es el de optimizar la utilización de los recursos
sin que por ello se deba asumir un deterioro en
la calidad de las imágenes. Para ello se estima
una medida estadística de la imagen que rela-
ciona el error cometido en la reconstrucción de
la imagen con características de la propia ima-
gen. De esta forma se puede predecir el error
que se cometería al utilizar un algoritmo de
compresión determinado, para una razón de
compresión fija.
Este artículo presenta la implementación del
primer prototipo de coprocesador capaz de
realizar esta predicción para aquellos algorit-
mos de compresión implantados en el sistema
y capaz de aconsejar cuál de ellos usar para
realizar la compresión.
El objetivo de este artículo es el de com-
probar hasta qué punto es posible la apli-
cación de técnicas de alto nivel, más propias
de desarrollos software, al diseño de de sis-
temas hardware. Para ello, en el artículo se
dan detalles específicos de la implementación
de este coprocesador sobre una FPGA y se
utiliza HandelC para alcanzar un diseño opti-
mizado. HandelC, de Celoxica Ltd.([7]),es un
lenguaje de descripción hardware de alto nivel
de abstracción que ha facilitado la evaluación
de distintas técnicas para la nueva fase de pre-
proceso propuesta, así como, la validación de
la funcionalidad de dicha fase y el estudio de
la aplicación de técnicas de alto nivel.
El resto del artículo se organiza en otras cua-
tro secciones. La sección 2 introduce la activi-
dad que será la técnica que permite justificar
la inclusión de la fase de preproceso previa a la
compresión. En la sección 3 se describe la ar-
quitectura que se plantea para conseguir el cál-
culo de la actividad y se analizan las técnicas
de optimización de alto nivel que se han apli-
cado sobre dicha arquitectura. La sección 4 re-
sume los experimentos realizados para validar
los diseños propuestos que se complementan
en la sección 5, con las conclusiones extraídas
de dichos experimentos.
2. Medida de la actividad de la ima-
gen
El propósito del coprocesador presentado en
este trabajo no es la compresión de imágenes
sino el de aconsejar al sistema de compresión
empotrado en el satélite sobre qué tipo de al-
goritmo debe ser aplicado para alcanzar una
utilización óptima de los recursos de almace-
namiento y ancho de banda consumido.
A partir de una imagen capturada por los
sensores del satélite y fijados la razón de com-
presión y el máximo error cometido durante
la reconstrucción de la imagen admisible en la
estación terrestre, el coprocesador debe ser ca-
paz de evaluar qué algoritmo de compresión,
con o sin pérdidas, es la mejor opción para sa-
tisfacer los requerimientos de almacenamiento
y consumo del ancho de banda.
Para ello el sistema propuesto toma en con-
sideración características estadísticas de las
imágenes que permiten cuantificar la compleji-
dad de las mismas. Esta complejidad se puede
evaluar a través de la medida de la actividad
de la imagen, IAM(Image Activity Measure)
propuesta en[8], [9] y [10]. La IAM indica cómo
de compleja es una imagen en términos de bor-
des, contornos y regiones activas, y tiene una
gran influencia sobre el rendimiento del proce-
so de compresión. La IAM puede ser obtenida
de la varianza de la imagen, mediante una de-
tección de bordes o del gradiente [8]. Sin em-
bargo, para este trabajo se ha seleccionado una
alternativa que propone el cálculo de la IAM
a través de los coeficientes LH,HL y HH de
la transformada discreta wavelet (DWT) de la
imagen. Así, para una imagen NxM, dicha me-
dida de la actividad se puede obtener según:
IAM =
1
M · N
·(

|Coef.SubbandaDetalle|)
(1)
La utilización de la DWT para el cálculo de la
actividad es totalmente coherente con los sis-
temas actuales de compresión, que se ajustan
al estándar JPEG2000.
554 Aplicaciones
En [11] se demuestra la relación entre la
IAM y el PSNR de las imágenes reconstruidas
a partir de una compresión basada en DWT.
La relación se resume en la siguiente ecuación:
PNSR = α · Ln(IAM) + β (2)
donde α y β son constantes dependientes de
la familia wavelet usada y de la razón de com-
presión exigida. Esta ecuación se puede ajus-
tar experimentalmente para distintas configu-
raciones de estos dos parámetros.
Así el coprocesador es capaz de obtener
el IAM de una imagen capturada y prede-
cir el PNSR para el algoritmo con perdidas
para distintas razones de compresión. Con es-
ta información se puede seleccionar la mejor
técnica de compresión buscando siempre la
optimización en la utilización de recursos y
cumpliendo con las restricciones impuestas so-
bre el error de reconstrucción.
3. Arquitectura Propuesta
El diseño que se presenta en este artículo está
completamente implementado con un lengua-
je de descripción hardware de alto nivel de-
nominado HandelC [7]. El prototipo que se
presenta en este trabajo pretende ser un sis-
tema autónomo, totalmente operativo y capaz
de aconsejar a de cualquier sistema de com-
presión de imágenes compatible con los algo-
ritmos estudiados. La descripción del sistema
se ha planteado a partir de una arquitectura
modular que ha permitido el estudio de di-
versos aspectos críticos en la implementación
del coprocesador. Cada uno de los cuatro mó-
dulos en que está basada esta arquitectura se
han modelado procurando conseguir un diseño
flexible, parametrizado y eficiente.
3.1. Módulo de Comunicaciones
El coprocesador para el cálculo de la IAM es-
tá orientado a complementar a un sistema en-
cargado de realizar la compresión de las imá-
genes. La comunicación entre ambos sistemas
se realizará a través de un bus, cuyo control
recaerá en el sistema de compresión. Este sis-
tema cederá el control del bus al coprocesador
cuando, capturada una imagen, se necesite de-
cidir que tipo de compresión debe aplicarse.
En el coprocesador, el módulo de comunica-
ciones examina el bus esperando la señal ex-
terna que indique el inicio de la obtención de
la IAM. Cuando ésta se produce, comprueba el
estado de módulo de control y, en caso de que
sea posible, se inicia el cálculo de la IAM man-
teniendo el control del bus. Cuando el módulo
de control comunique el resultado del análisis
realizado, el módulo de comunicaciones trans-
fiere la recomendación al sistema de compre-
sión y libera el bus. La utilización de HandelC
a permitido que la implementación de toda la
gestión de señales se haya simplificado.
3.2. Módulo de Control
Una vez él módulo de comunicaciones comu-
nica la orden de inicio, el módulo de con-
trol configura todas las señales necesarias para
completar todas las etapas de la DWT. Este
planteamiento corresponde con el algoritmo
típico de transformada wavelet por filas y por
columnas. Sin embargo se ha propuesto una
alteración para que al finalizar cada paso de
la transformada, de forma progresiva, se vaya
obteniendo el valor de IAM.
Para implementar la función principal del
coprocesador el módulo de control recupera la
primera fila de la imagen de la memoria y la es-
cribe en un buffer intermedio. A partir de este
momento el módulo de DWT realiza la trans-
formada unidimensional directa del vector al-
macenado en el buffer escribiendo el resultado
en el mismo buffer. El módulo de Control de-
vuelve la fila transformada desde el buffer a la
memoria. Cuando se completa la transforma-
da por filas, el módulo de Control, recupera
la primera columna de la memoria, la escribe
en el buffer intermedio y notifica al módulo
de DWT que puede comenzar la transforma-
da de este nuevo vector. Cuando la columna
está transformada, el módulo de Control cal-
cula el valor progresivo de la actividad y es-
cribe el vector en la memoria. El primer paso
de transformación termina cuando la última
de las columnas es transformada.
Cuando finaliza un paso de transformación
se evalúa si el valor acumulado de la medida
XVI Jornadas de Paralelismo, JP '2005 555
de actividad para la imagen analizada supera
un umbral determinado. En caso de que IAM
supere este umbral querrá decir que el error
después de la reconstrucción superará las es-
pecificaciones del sistema. Por ello, en este mo-
mento, el módulo de control suspende su ejecu-
ción y comunica al módulo de comunicaciones
que el algoritmo aconsejable para procesar la
imagen debe ser sin pérdidas. En caso de que la
IAM no supere el umbral establecido, se com-
prueba si el paso de transformación que se ha
realizado es el último, y si es así, la ejecución
finaliza. La recomendación en este caso es que
se puede realizar una compresión con pérdidas
ya que el error después de la reconstrucción no
superará las especificaciones del sistema.
3.3. Módulo DWT
Este módulo realiza la transformada wavelet
discreta, directa y unidimensional del vector
almacenado en el buffer intermedio y escribe
el resultado en el mismo buffer.
Sólo se ha implementado la transformada
unidimensional porque para realizar una esti-
mación progresiva de la actividad, el módulo
de control, plantea una transformada fila a fila
y columna a columna, que no permite habili-
tar técnicas de interleaving ([12] y [13]). Junto
con el vector también recibe información sobre
que paso de la transformación se está desarro-
llando para poder calcular el vector a analizar.
Para este primer prototipo se ha elegido el
algoritmo de Lifting con la familia wavelet
Daubechies 4 para obtener los coeficientes
wavelet de detalle. Sin embargo, el diseño es
altamente parametrizable permitiendo realizar
la transformada según la algoritmo Lifting con
operadores de aritmética entera o de aritméti-
ca de coma flotante. Esta característica ha per-
mitido evaluar cuál de las dos implementa-
ciones resulta más ventajosa desde el punto de
vista de la utilización de recursos hardware. El
algoritmo implementado sobre aritmética de
enteros necesita realizar una extensión simétri-
ca del vector al que se vaya a aplicar la trans-
formada. A partir de esta extensión el algo-
ritmo se compone de una fase de predicción
seguida de una de actualización (figura 1). Las
especificaciones típicas de la implementación
EXTENSION
S[-1] = S[0]
S[L] = S[L-1]
PREDICTION
for n ← 0 to middle − 1
do
S[2n + 1] = S[2n + 1] −
S[2n]+S[2n+2]
2
UPDATE
for n ← 0 to middle − 1
do
S[2n] = S[2n] +
S[2n−1]+S[2n+1]+2
2
Figura 1: Algoritmo Lifting para IDWT
software deben ser revisadas para poder sacar
provecho de los recursos hardware disponibles.
De nuevo la utilización de un lenguaje de al-
to nivel para describir el hardware ha resul-
tado de gran utilidad, permitiendo explotar el
paralelismo del algoritmo para reducir la la-
tencia de ejecución. La optimización de este
algoritmo se ha desarrollado en dos fases. La
primera implica el desenrollado de los dos bu-
cles principales de forma que se aproveche la
forma en que se realiza el acceso a los datos. A
continuación se ha analizado la dependencia de
datos entre estos dos bucles y se ha consegui-
do reducir todo el cálculo a un único bucle
en el que se efectúan en paralelo el cálculo de
cuatro coeficientes de la transformada. Para
implementar esta optimización se han inclui-
do en el módulo de aritmética los operadores
necesarios.
El algoritmo implementado sobre aritméti-
ca de punto flotante se compone de dos fases
de actualización, una de predicción y una úl-
tima de normalización (figura 2). La primera
optimización se realiza sobre los operadores de
la fase de predicción ejecutando en paralelo
dos productos y dos sumas. La segunda op-
timización corresponde a la ha sido fruto del
estudio de la posibilidad de aplicación del de-
senrollado de bucles, desarrollando ocho itera-
ciones de bucle en paralelo para las fases de
actualización y normalización, y cuatro itera-
ciones para la fase de predicción. Para poder
556 Aplicaciones
UPDATE 1
for n ← 0 to middle − 1
do
S[n] = S[n] +
√
3 · S[middle + n]
PREDICTION
S[middle] = S[middle] −
√
3
4
· S[0] −
√
3−2
4
· S[middle − 1]
for n ← 1 to middle − 1
do
S[middle + n] = S[middle + n] −
√
3
4
· S[n]−
√
3−2
4
· S[n − 1]
UPDATE 2
for n ← 0 to middle − 2
do
S[n] = S[n] − S[middle + n + 1]
S[middle − 1] = S[middle − 1] − S[middle]
NORMALIZATION
for n ← 0 to middle − 1
do
S[n] =
√
3−1
√
2
· S[n]
S[middle + n] =
√
3+1
√
2
· S[middle + n]
Figura 2: Algoritmo Lifting con familia wavelet
Daubechies 4 y aritmética float
implementar esta optimización se ha provisto
del suficiente número de operadores en el mó-
dulo de aritmética.
3.4. Módulo de Aritmética
Todas las optimizaciones y los análisis prop-
uestos para este artículo conllevan la uti-
lización de distintos tipos de operadores arit-
méticos, que en ocasiones deben ser accedidos
en paralelo. Este uso intensivo de estos recur-
sos justifica la creación de una librería eficiente
con operadores para las distintas aritméticas
empleadas en el cálculo de la actividad.
3.4.1. Integer Module
Para la implementación de la aritmética de
enteros se ha acudido a la implementación
que de los mismos proporciona la herramien-
ta HandelC, ya que cumplen con las suficientes
características de flexibilidad y alto rendimien-
to que se necesitan para el análisis que aquí se
plantea.
El módulo de enteros incorpora cuatro
sumadores/restadores de 8 bits que podrán ser
accedidos en paralelo por el módulo de DWT.
3.4.2. Módulo en coma flotante
Las operaciones en aritmética real que se pre-
cisan en la transformada real plantean unos re-
querimientos que no se satisfacen con las libre-
rías proporcionadas por Celoxica, siendo pre-
ciso implementar una solución eficiente. Por
ello se ha desarrollado una librería de ope-
radores en coma flotante, totalmente para-
metrizada generalizando el estándar IEEE754
[14]. De esta forma la representación de la in-
formación se adapta a las especificaciones del
diseño y las características de la plataforma
hardware, con un bit de signo, un exponente
de e bits y una mantisa de m bits,siendo la
longitud de la representación (L = 1+n+m)
un parámetro del sistema.
Una vez que se ha determinado L, se debe
establecer la precisión con la que operará el
sistema, es decir, cuantos bits se dedicarán a
representar el exponente y cuantos a la manti-
sa. Para determinar la longitud del exponente
se debe tener en cuenta el rango dinámico de
los coeficientes de la imagen transformada, ya
que la aritmética seleccionada debe ser capaz
de representar el valor máximo de estos coe-
ficientes. Este valor máximo se puede estimar
considerando el número máximo de pasos de
transformación (nsteps), los coeficientes de la
familia wavelet con la que se esté trabajan-
do (hi) la profundidad de color de la imagen
original en número de bits(depth):
V aluemax = 2depth
·

|hi|
nsteps
. (3)
El número de bits correspondientes al expo-
nente deben ser los suficientes para poder re-
presentar este valor. Una vez que se ha fijado
este número de bits queda también fijos los
bits correspondientes a la mantisa, que en úl-
tima instancia determina la precisión con la
que trabaja el sistema y, por tanto, el error
derivado de operar con valores reales.
El módulo de aritmética en punto flotante
incorpora ocho sumadores/restadores y ocho
multiplicadores parametrizados para efectuar
XVI Jornadas de Paralelismo, JP '2005 557
de forma eficiente las operaciones de DWT y
el cálculo de IAM en paralelo.
4. Experimentos
A pesar de haber mantenido un enfoque ge-
neral durante el diseño del coprocesador, pro-
poniendo un modelo del sistema totalmente
parametrizado e independiente de la platafor-
ma hardware, para completar la fase de imple-
mentación y poder realizar experimentos se ha
tenido que seleccionar una plataforma para el
coprocesador. La plataforma disponible para
validar el sistema ha sido una RC1000 de
Celoxica con una FPGA XC40150XV, cons-
truida sobre una tarjeta PCI de 32-bits que in-
corpora 4 bancos de memoria SRAM de 2MB
cada.
Sobre esta plataforma, las especificaciones
de diseño han sido validadas numéricamente
con un conjunto de imágenes en escala de
grises de diferentes tamaños y característi-
cas estadísticas diferentes. Los resultados de
la DWT sobre las imágenes y los valores
obtenidos para la IAM han sido satisfacto-
rios ya que las simulaciones realizadas con
HandelC coinciden exactamente con los va-
lores devueltos por la implementación en C de
los algoritmos propuestos. Una vez validada
la implementación, el objetivo del resto de los
experimentos es evaluar el diseño propuesto.
4.1. Evaluación de la aritmética utilizada
La aritmética propuesta permite establecer
comparativas sobre la utilización de recur-
sos entre la implementación propuesta para
operaciones en coma flotante y operaciones
con enteros. Los resultados se muestran en
la tabla 4.1. Esta tabla compara la imple-
mentación de los operadores en coma flotante
con los operadores equivalentes para enteros,
siendo esta equivalencia respecto a la longi-
tud de los operandos (la precisión aritmética
es muy diferente). Tanto los operadores en co-
ma flotante como los operadores para enteros
se han desarrollado con HandelC, sin aplicar
optimizaciones ni mejoras a bajo nivel, mante-
niendo así la naturaleza de prototipado de este
primer diseño. Como cabría esperar, aunque la
frecuencia de operación es muy similar entre
los dos tipos de operadores, el mayor consumo
de recursos hardware por parte de los ope-
radores de coma flotante, un menor rendimien-
to en cualquier sistema que utilice estos ope-
radores..
4.2. Rendimiento global del sistema
En la tabla 4.2 se muestran los resultados con-
seguidos tras la síntesis del prototipo de co-
procesador para valores de configuración di-
ferentes. En esta tabla se muestran la uti-
lización de recursos y los periodos mínimos
de operación para diferentes tamaños de imá-
genes y, en el caso de la implementación basa-
da en operadores de coma flotante, para dos
longitudes típicas de coeficientes, 16 y 32 bits.
Como se esperaba la selección de la longitud
los coeficientes afecta críticamente en la uti-
lización de los recursos al comparar sistemas
basados en aritmética de coma flotante. Igual-
mente crítica resulta la comparación que se
puede establecer entre sistemas con aritméti-
ca distinta. Se puede apreciar que, incluso en
el peor caso mostrado en la tabla (imágenes
de 512x512), la utilización del area en el dis-
positivo para el coprocesador con aritmética
entera supone un ahorro del un 40 % respecto
al coprocesador basado en aritmética en co-
ma flotante. Estos resultados se vuelven aún
más dramáticos si se presta atención al perío-
do mínimo de operación que es radicalmente
menor para el sistema con aritmética entera.
5. Conclusiones
En este artículo se han utilizado optimiza-
ciones de alto nivel adaptadas para el desa-
rrollo de sistemas empotrados en satélites de
observación terrestre. Se ha planteado la posi-
bilidad de realizar una compresión adaptati-
va de la imagen en función de determinadas
propiedades estadísticas de la misma. Estas
características tienen una repercusión inme-
diata en el rendimiento del proceso de com-
presión y deben ser cuantificadas para deter-
minar la técnica de compresión más adecuada
558 Aplicaciones
Suma de enteros Suma float
N
o
bits 64 32 16 8 64 32 16 8
Tot.Eq.Gates 3288 1634 930 578 14356 7584 4428 2768
Tmin(ns) 101.71 50.72 28.29 13.72 76.79 40.17 19.49 16.85
Multiplicación de enteros Multiplicación float
N
o
bits 64 32 16 8 64 32 16 8
Tot.Eq.Gates 32166 8474 2424 860 26572 9120 3148 1692
Tmin(ns) 136,67 82.59 46.61 25.96 136.67 58.07 23.90 18.25
Tabla 1: Operadores de enteros vs operadores de coma flotante
Aritmética entera Aritmética float 16 bit Aritmética float 32 bit
Tamaño Imagen Tmin(ns) Tot.Eq.Gates Tmin(ns) Tot.Eq.Gates Tmin(ns) Tot.Eq.Gates
512x512 59.156 106673 162.976 89468 172.791 173406
256x256 60.678 59286 133.945 54154 129.642 104358
128x128 54.973 33788 97.861 35900 99.976 69354
64x64 53.040 20909 74.990 26184 82.228 51146
32x32 45.977 13644 67.400 20840 84.141 41532
Tabla 2: Datos de la síntesis del coprocesador para las distintas aritméticas propuestas
para esa imagen.
Se ha propuesto el diseño de un coproce-
sador, implementado en una FPGA, para
aconsejar al sistema de compresión si debe uti-
lizar un algoritmo con o sin pérdidas. Este co-
procesador realiza la DWT de las imágenes
y mide sus actividades a partir de sus coefi-
cientes de detalle. Con esta actividad se puede
evaluar la relación IAM-PNSR para distintas
razones de compresión, con el fin de predecir
el error que se cometerá después de la recon-
strucción.
El diseño de este coprocesador es esca-
lable, parametrizable y ha sido desarrollado
con HandelC. Este lenguaje de alto nivel de
descripción hardware ha demostrado sus ven-
tajas para el prototipado general y rápido,
permitiendo la experimentación y la compara-
ción de algoritmos. Gracias a la utilización de
este lenguaje se han podido aplicar técnicas de
paralelización típicas de los sistemas software,
por ejemplo el desenrollado de bucles, a un sis-
tema hardware. Además estas técnicas se han
podido desarrollar en una etapa temprana del
proceso de diseño debido a las ventajas que
presentan este tipo de lenguajes. Los resul-
tados obtenidos resultan imprescindibles para
guiar a los diseñadores en futuras implementa-
ciones del coprocesador.
Referencias
[1] Sias Mostert and Eduard Kriegler. Im-
plementing an image processing system
for the next generation earth observation
sensors for the sunsat 2 micro-satellite
programme. In Proceedings of the 4th
IAA Symposium on Small Satellites for
Earth Observation, 2003.
[2] C. Lambert-Nebout. Use of JPEG2000
for on-board space image compression.
2000. ISO/IEC JTC 1/SC 29/WG 1 N
N1483.
[3] The JPEG2000 still image coding sys-
tem: an overview. C. christopoulos;
a. skodras and t. ebrahimi. IEEE
Transactions on Consumer Electronics,
46(4):1103–1127, 2000.
[4] D. Chai and A. Bouzerdoum. JPEG2000
image compression: an overview. In Pro-
ceedings of the Seventh Australian Intel-
XVI Jornadas de Paralelismo, JP '2005 559
ligent Information Systems Conference,
pages 237–241, 2001.
[5] Thomas W. Fry and Scott Hauck.
Hyperspectral image compression on
reconfigurable platforms. In Proceedings
of the 10th Annual Symposium on Field-
Programmable Custom Computing Ma-
chines, pages 21–260, 2002.
[6] Anwar S. Dawood; John A. Williams
and Stephen J. Visser. On-board
satellite image compression using
reconfigurable FPGA’s. In Proceedings
of the IEEE International Conference on
Field-Programmable Technology, pages
306–310, 2002.
[7] Celoxica Limited Copyright 2002.
HandelC language reference manual.
2002.
[8] Subhasis Saha and Rao Vermuri. An
analysis of the effect of image features on
lossy coding performance. IEEE Signal
Processing Letters, 7(5):104–107, 2000.
[9] M. B. Ramos and S. S. Hemani. Edge-
adptative JPEG image compression. In
Proceedings of VCIP’96, pages 1082–
1093, 1996.
[10] W. J. Kim et al. A bit allocation method
based on picture activity for still image
coding. IEEE Transactions on Image
Processing, 8:974–977, 1999.
[11] Subhasis Saha and Rao Vermuri. How do
image statistics impact lossy coding per-
formance? In Proceedings of the Interna-
tional Conference on Information Tech-
nology, Coding and Computing, pages 42–
47, 2000.
[12] R. Owens M. Vishwanath and M. J. Ir-
win. VLSI architectures for the discrete
wavelet transform. IEEE Transactions on
Circuit Shaystems, 2(42):305–316, 1995.
[13] J. S. Fridman and E. S. Manolakos.
Discrete wavelet transform: Data depen-
dence analysis and synthesis of distrib-
uted memory and control array archi-
tectures. IEEE Transactions on Signal
Processing, 45:1291–1308, 1997.
[14] B. Parhami. Computer Arithmetic: Al-
gorithms and Hardware Design. Oxford
University Press, 2000.
560 Aplicaciones
   
                  
  #       )  ,  -         2       
4
,  6 )   
8 : ; < > ? A B C : E : F < I K L M B O : F < I R T < < M W Y : Y : \ ] I M ^ M W ] K
_ ` a b c d ` f g h j k b ` l b j g m d ` n p r a j b m d p g ` s t u v ` l b g y z k l m
{ z k | c d ` f v r ` g ~ m €  ‚ ƒ „  f v r ` g ~ m
…
s k † m r ‡ ` s b ` g ‡ k z r m ‡ Š p s ` ‹ Œ m l ` c j m v c ` s
Ž   ’ “ ” • ’
– ˜ ™ š › œ  ž Ÿ    ¡ š ¢ £ ¡ ¤ Ÿ ž ¤ ž œ ¡ ¥ ¢ ¤ ¢ Ÿ ¢ ¦ ¦ ¡ ¦ › ¨ ¤ ¦ ¡ ª
¨ ¡ ˜ ™ ¢ ™ › ž ˜ ž ¬ ™ š ¡ ® ˜ › œ ž ™ Ÿ ž ¤ › ¯ ° ž ˜ ¦ › ˜ ¡ ¢ Ÿ ± › ² ³ ª
œ › ž ˜ µ ® ° ± · ¬ ž Ÿ ¸ ¦ ™ ¡ Ÿ › ˜ ¹ º ± › ¨ ¢ ¹ ¡ œ » ® ° ± › œ ¢
¤ ž  ¡ Ÿ ¬ ³ ¦ ˜ ž › œ ¡ Ÿ ¡ ¥ ³ ¯ ™ › ž ˜ ™ ¡ ¯ š ˜ › ¾ ³ ¡ › ˜ ™ š ¡ ¸ ¡ ¦ ¥
ž ¬ ¯ ž ¨ ¤ ³ ™ ¡ Ÿ £ › œ › ž ˜ » ¿ š › œ ¨ ¡ ™ š ž ¥ › œ  ¢ œ ¡ ¥ ž ˜
¢ ¤ ¢ Ÿ ™ › ¢ ¦ ¥ › ² ¡ Ÿ ¡ ˜ ™ › ¢ ¦ ¡ ¾ ³ ¢ ™ › ž ˜ µ Å ± Æ · ™ › ¹ š ™ ¦ Ç
¯ ž ³ ¤ ¦ ¡ ¥  › ™ š ¢ ¨ ¢ œ œ › £ ¡ œ ¡ ™ ž ¬ ¡ › ¹ ¡ ˜ œ Ç œ ™ ¡ ¨ œ »
± ¡ ˜ ž › œ › ˜ ¹ ¦ ¢ Ÿ ¹ ¡ µ º ± · › ¨ ¢ ¹ ¡ œ › ˜  › ž ¨ ¡ ¥ › ¯ › ˜ ¡
¢ ˜ ¥ œ ™ Ÿ ³ ¯ ™ ³ Ÿ ¢ ¦ ¯ ¡ ¦ ¦ ³ ¦ ¢ Ÿ  › ž ¦ ž ¹ Ç Â Ç ® ° ± š ¢ œ
¢ š › ¹ š ¯ ž ¨ ¤ ³ ™ ¢ ™ › ž ˜ ¢ ¦ ¯ ž œ ™ » Ï ž ˜ œ ¡ ¾ ³ ¡ ˜ ™ ¦ Ç Ð ¢ ˜
¢ ¤ ¤ Ÿ ž ¤ Ÿ › ¢ ™ ¡ ¤ ¢ Ÿ ¢ ¦ ¦ ¡ ¦ › ¨ ¤ ¦ ¡ ¨ ¡ ˜ ™ ¢ ™ › ž ˜ ž ¬ ® ° ± › œ
™ š ¡  ¡ œ ™ ¢ ¤ ¤ Ÿ ž ¢ ¯ š ™ ž Ÿ ¡ ¥ ³ ¯ ¡ › ™ œ Ÿ ³ ˜ ™ › ¨ ¡ » ¿ š › œ
 ž Ÿ   ¤ Ÿ ž ¤ ž œ ¡ œ ¢ ¤ ž Ÿ ™ ¢  ¦ ¡ ¤ ¢ Ÿ ¢ ¦ ¦ ¡ ¦ ¯ ž ¥ ¡ ³ œ › ˜ ¹
œ ¡ £ ¡ Ÿ ¢ ¦ ¤ Ÿ ž ¹ Ÿ ¢ ¨ ¨ › ˜ ¹ ¨ ž ¥ ¡ ¦ œ Ò µ Ó · œ š ¢ Ÿ ¡ ¥ ¢ ¥ ª
¥ Ÿ ¡ œ œ œ ¤ ¢ ¯ ¡ ¨ ž ¥ ¡ ¦ Ð µ Õ · ¨ ¡ œ œ ¢ ¹ ¡ ¤ ¢ œ œ › ˜ ¹ ¨ ž ¥ ¡ ¦
¢ ˜ ¥ µ º · š Ç Â Ÿ › ¥ ¨ ž ¥ ¡ ¦ » ¿ š ¡ ¤ Ÿ ž ¤ ž œ ¡ ¥ ¤ ¢ Ÿ ¢ ¦ ¦ ¡ ¦
› ¨ ¤ ¦ ¡ ¨ ¡ ˜ ™ ¢ ™ › ž ˜ š ¢ œ  ¡ ¡ ˜ ¡ £ ¢ ¦ ³ ¢ ™ ¡ ¥ ž ˜ ¢ ¯ ¦ ³ œ ª
™ ¡ Ÿ ž ¬  › ¤ Ÿ ž ¯ ¡ œ œ ž Ÿ œ » ¿ š ¡ ¡ £ ¢ ¦ ³ ¢ ™ › ž ˜ ž ¬ ™ š ¡ ¤ ¡ Ÿ ª
¬ ž Ÿ ¨ ¢ ˜ ¯ ¡ ž ¬ ® ° ± ª ¯ ž ¥ ¡ œ š ž  œ ™ š ¢ ™ ™ š ¡ ¨ ¡ œ ª
œ ¢ ¹ ¡ ¤ ¢ œ œ › ˜ ¹ ¨ ž ¥ ¡ ¦ œ ¯ ¢ ¦ ¡ œ  ¡ ™ ™ ¡ Ÿ › ˜ ™ š › œ   › ˜ ¥
ž ¬ ¤ ¦ ¢ ™ ¬ ž Ÿ ¨ œ »
Ö × Ø
’ “ Ù Ú Û • ’ Ü Ù
Ø
– ˜ ¨ ¢ ˜ Ç ¥ › œ ¯ › ¤ ¦ › ˜ ¡ œ Ð Ÿ ¢  ¥ ¢ ™ ¢ ¢ ¯ ¾ ³ › Ÿ ¡ ¥ ¬ Ÿ ž ¨
› ˜ œ ™ Ÿ ³ ¨ ¡ ˜ ™ œ ¢ Ÿ ¡ œ ³  œ ™ ¢ ˜ ™ › ¢ ¦ ¦ Ç ¯ ž Ÿ Ÿ ³ ¤ ™ ¡ ¥  Ç
˜ ž › œ ¡ ¢ ˜ ¥ œ ž ¤ š › œ ™ › ¯ ¢ ™ ¡ ¥ ¸ ¦ ™ ¡ Ÿ › ˜ ¹ ™ ¡ ¯ š ˜ › ¾ ³ ¡ œ ¢ Ÿ ¡
™ š ¡ ˜ › ˜ ¥ › œ ¤ ¡ ˜ œ ¢  ¦ ¡ ¬ ž Ÿ ¢ ¤ Ÿ ž ¤ ¡ Ÿ › ˜ ™ ¡ Ÿ ¤ Ÿ ¡ ™ ¢ ™ › ž ˜
ž Ÿ ¤ ž œ ™ ª ¤ Ÿ ž ¯ ¡ œ œ › ˜ ¹ » – ˜ ¹ ¡ ˜ ¡ Ÿ ¢ ¦ ™ ¡ Ÿ ¨ œ Ð œ ¨ ž ž ™ š ª
› ˜ ¹ ™ ¡ ¯ š ˜ › ¾ ³ ¡ œ ¯ ¢ ˜  ¡ ¯ ¦ ¢ œ œ › ¸ ¡ ¥ › ˜ ™ ž ¦ › ˜ ¡ ¢ Ÿ
¢ ˜ ¥ ˜ ž ˜ ª ¦ › ˜ ¡ ¢ Ÿ » à ™ ¢ ˜ ¥ ¢ Ÿ ¥ ¦ › ˜ ¡ ¢ Ÿ ¸ ¦ ™ ¡ Ÿ › ˜ ¹ ™ ¡ ¯ š ª
˜ › ¾ ³ ¡ œ  ¢ œ ¡ ¥ ž ˜ ¦ ž ¯ ¢ ¦ ¢ £ ¡ Ÿ ¢ ¹ ¡ œ ž Ÿ á ¢ ³ œ œ › ¢ ˜
  ¡ Ÿ ˜ ¡ ¦ œ œ ³ ¯ ¯ ¡ ¡ ¥ › ˜ Ÿ ¡ ¥ ³ ¯ › ˜ ¹ ™ š ¡ ˜ ž › œ ¡ Ð Â ³ ™ ¢ ™
¡ â ¤ ¡ ˜ œ ¡ œ ž ¬ ¤ ž ž Ÿ ¬ ¡ ¢ ™ ³ Ÿ ¡ ¤ Ÿ ¡ œ ¡ Ÿ £ ¢ ™ › ž ˜ » – ˜ ž ™ š ¡ Ÿ
 ž Ÿ ¥ œ Ð ™ š ¡ Ç ¨ ¢ Ç œ ¡ £ ¡ Ÿ ¡ ¦ Ç Â ¦
³ Ÿ ™ š ¡ ¬ ¡ ¢ ™ ³ Ÿ ¡ œ ¢ œ
™ š ¡ › Ÿ ¡ ¥ ¹ ¡ œ ¢ Ÿ ¡ ¢ ™ ™ ¡ ˜ ³ ¢ ™ ¡ ¥ » 㠞  ¡ £ ¡ Ÿ Ð ˜ ž ˜ ¦ › ˜ ª
¡ ¢ Ÿ ¸ ¦ ™ ¡ Ÿ › ˜ ¹ ™ ¡ ¯ š ˜ › ¾ ³ ¡ œ ¢ ¯ š › ¡ £ ¡  ¡ ™ ™ ¡ Ÿ ¬ ¡ ¢ ™ ³ Ÿ ¡
¤ Ÿ ¡ œ ¡ Ÿ £ ¢ ™ › ž ˜ ¢ œ ™ š ¡ Ç ™ Ÿ Ç ™ ž ¢ ¥ ¢ ¤ ™ › £ ¡ ¦ Ç ™ ³ ˜ ¡ ™ š ¡
œ ™ Ÿ ¡ ˜ ¹ ™ š ž ¬ ™ š ¡ œ ¨ ž ž ™ š › ˜ ¹ ™ ž ™ š ¡ ¦ ž ¯ ¢ ¦ œ ™ Ÿ ³ ¯ ª
™ ³ Ÿ ¡ œ ¬ ž ³ ˜ ¥ › ˜ ™ š ¡ › ¨ ¢ ¹ ¡ »
® ˜ › œ ž ™ Ÿ ž ¤ › ¯ ˜ ž ˜ ¦ › ˜ ¡ ¢ Ÿ ¥ › ² ³ œ › ž ˜ µ ® ° ± · › œ
¯ ³ Ÿ Ÿ ¡ ˜ ™ ¦ Ç ž ˜ ¡ ž ¬ ™ š ¡ ¨ ž œ ™ ¤ ž  ¡ Ÿ ¬ ³ ¦ ˜ ž › œ ¡ Ÿ ¡ ª
¥ ³ ¯ ™ › ž ˜ ™ ¡ ¯ š ˜ › ¾ ³ ¡ œ › ˜ ™ š ¡ ¸ ¡ ¦ ¥ ž ¬ ¯ ž ¨ ¤ ³ ™ ¡ Ÿ £ › ª
œ › ž ˜ å Ó æ » ¿ š › œ ™ ¡ ¯ š ˜ › ¾ ³ ¡ ™ ¢   ¡ œ › ˜ ™ ž ¢ ¯ ¯ ž ³ ˜ ™ ™ š ¡
¦ ž ¯ ¢ ¦ œ ™ Ÿ ³ ¯ ™ ³ Ÿ ¡ œ ¬ ž ³ ˜ ¥ › ˜ ™ š ¡ › ¨ ¢ ¹ ¡ ™ ž ¸ ¦ ™ ¡ Ÿ
˜ ž › œ ¡ Ð ¤ Ÿ ¡ œ ¡ Ÿ £ ¡ ¡ ¥ ¹ ¡ œ ¢ ˜ ¥ ¡ ˜ š ¢ ˜ ¯ ¡ œ ž ¨ ¡ ¬ ¡ ¢ ª
™ ³ Ÿ ¡ œ Ð ™ š ³ œ ¯ ž ˜ œ › ¥ ¡ Ÿ ¢  ¦ Ç › ˜ ¯ Ÿ ¡ ¢ œ › ˜ ¹ ™ š ¡ œ › ¹ ˜ ¢ ¦ ª
™ ž ª ˜ ž › œ ¡ Ÿ ¢ ™ › ž µ à ° è ·  › ™ š ˜ ž œ › ¹ ˜ › ¸ ¯ ¢ ˜ ™ ¾ ³ ¢ ˜ ª
™ › ™ ¢ ™ › £ ¡ ¥ › œ ™ ž Ÿ ™ › ž ˜ œ ž ¬ ™ š ¡ œ › ¹ ˜ ¢ ¦ » Å › ž ˜ ¡ ¡ Ÿ ¡ ¥ › ˜
Ó é é ê Â Ç Å ¡ Ÿ ž ˜ ¢ ¢ ˜ ¥ ë ¢ ¦ ›   å Õ æ Ð ® ° ± š ¢ œ ¹ Ÿ ž  ˜
™ ž  ¡ ¯ ž ¨ ¡ ¢  ¡ ¦ ¦ ª ¡ œ ™ ¢  ¦ › œ š ¡ ¥ ™ ž ž ¦ › ˜ ™ š ¡ ¦ ¢ œ ™
¥ ¡ ¯ ¢ ¥ ¡ å Ó Ð º Ð ì Ð í æ » ® ° ± š ¢ œ ¢ ¦ Ÿ ¡ ¢ ¥ Ç Â ¡ ¡ ˜ œ ³ ¯ ª
¯ ¡ œ œ ¬ ³ ¦ ¦ Ç ¢ ¤ ¤ ¦ › ¡ ¥ › ˜ ¥ › ² ¡ Ÿ ¡ ˜ ™ ¥ › œ ¯ › ¤ ¦ › ˜ ¡ œ Ð œ ³ ¯ š
¢ œ ¨ ¡ ¥ › ¯ › ˜ ¡ å î Ð ï Ð ð æ ž Ÿ  › ž ¦ ž ¹ Ç å é Ð Ó ê Ð Ó Ó æ Ð ¬ ž Ÿ
¥ ¡ ˜ ž › œ › ˜ ¹ ¨ ³ ¦ ™ › ¥ › ¨ ¡ ˜ œ › ž ˜ ¢ ¦ › ¨ ¢ ¹ ¡ œ » ® ° ± š ¢ œ
¢ ¯ ™ ³ ¢ ¦ ¦ Ç Â ¡ ¡ ˜ ¯ Ÿ ³ ¯ › ¢ ¦ ™ ž ¢ ¯ š › ¡ £ ¡ œ ž ¨ ¡ Ÿ ¡ ¯ ¡ ˜ ™
 Ÿ ¡ ¢   ™ š Ÿ ž ³ ¹ š œ å Ó Õ Ð Ó º Ð Ó ì Ð Ó í æ »
¿ š ¡ ¨ ¢ ™ š ¡ ¨ ¢ ™ › ¯ ¢ ¦  ¢ œ › œ ž ¬ ® ° ± › œ ¢ ¤ ¢ Ÿ ª
™ › ¢ ¦ ¥ › ² ¡ Ÿ ¡ ˜ ™ › ¢ ¦ ¡ ¾ ³ ¢ ™ › ž ˜ µ Å ± Æ · ™ › ¹ š ™ ¦ Ç ¯ ž ³ ª
¤ ¦ ¡ ¥  › ™ š ¢ ¨ ¢ œ œ › £ ¡ œ ¡ ™ ž ¬ ¡ › ¹ ¡ ˜ œ Ç œ ™ ¡ ¨ œ å Ó î æ »
® ° ± ¨ ¢ Ç ™ ³ Ÿ ˜ ž ³ ™ ™ ž  ¡ ¡ ⠙ Ÿ ¡ ¨ ¡ ¦ Ç ¡ â ¤ ¡ ˜ œ › £ ¡ Ð
¬ Ÿ ž ¨ ™ š ¡ ¯ ž ¨ ¤ ³ ™ ¢ ™ › ž ˜ ¢ ¦ ¤ ž › ˜ ™ ž ¬ £ › ¡  Ð ¥ ¡ ¤ ¡ ˜ ¥ ª
› ˜ ¹ ž ˜ ™ š ¡ œ › ó ¡ ž ¬ ™ š ¡ › ¨ ¢ ¹ ¡ œ » ¿ š ¡ Ÿ ¡ ¢ Ÿ ¡ œ ž ¨ ¡
¥ › œ ¯ › ¤ ¦ › ˜ ¡ œ  š ¡ Ÿ ¡ ™ š ¡ Ÿ ¡ ¾ ³ › Ÿ ¡ ¨ ¡ ˜ ™ œ ¨ ¢ Ç Â ¡ œ ž
š ³ ¹ ¡ ô ¨ ³ ¯ š ¨ ž Ÿ ¡ ™ š ¢ ˜ Ó á Â Ç ™ ¡ › ˜ œ › ó ¡ å Ó ï æ ô
™ š ¢ ™ ¤ ¢ Ÿ ¢ ¦ ¦ ¡ ¦ ¯ ž ¨ ¤ ³ ™ › ˜ ¹ ¤ Ÿ ž £ ¡ œ ™ ž  ¡ ¡ œ œ ¡ ˜ ™ › ¢ ¦ »
¿ š ¡ œ ™ ¢ ˜ ¥ ¢ Ÿ ¥ ˜ ³ ¨ ¡ Ÿ › ¯ ¢ ¦ œ ¯ š ¡ ¨ ¡ ¬ ž Ÿ œ ž ¦ £ › ˜ ¹
Å ± Æ œ › œ  ¢ œ ¡ ¥ ³ ¤ ž ˜ ¢ ˜ ¡ â ¤ ¦ › ¯ › ™ ¸ ˜ › ™ ¡ ¥ › ² ¡ Ÿ ª
¡ ˜ ¯ ¡ ¥ › œ ¯ Ÿ ¡ ™ › ó ¢ ™ › ž ˜ » ë ž Ÿ ¡ ¡ ö ¯ › ¡ ˜ ™ œ ¯ š ¡ ¨ ¡ œ
š ¢ £ ¡  ¡ ¡ ˜ œ ¤ ¡ ¯ › ¸ ¯ ¢ ¦ ¦ Ç ¥ ¡ œ › ¹ ˜ ¡ ¥ ¬ ž Ÿ ˜ ž ˜ ¦ › ˜ ¡ ¢ Ÿ
                    ! # % # '    # ( * ' # -  . 0
1 2 # 3    . 1 2 # . #  *  #  1   #   #  ' # < -  # - ( 
  # (    2 2 ' # ?   ' #   A # 1 * ' * 2 2 # 2  E #   G  
H     !  ' L ! # * ' #     # 1 * ' * 2 2 # 2  E * 0
    R T V W R  '    * 1 1 2  - *      #    0
   R 2 * '  #   ' # # 0  . #    * 2 ` a W c %  2  . # 
 A   . #  -  # *   '  -   ' * 2 - # 2 2  2 * ' A   2   ( 
# . * L #   #  R   #   * * ' # 3 1 2  -    . # '  0
- * 2  -  # . # R  '   #   - ' #   E *     l     -  # . #
  -  . .  2 (   #     # ' n # 2  !  # ' # p W r 
* ' #  %  2 % #   s  *  *  * -   # ?  # - #    #
1 * ' * 2 2 # 2 * 1 1 '  * -  #    *  * ' # 1 ' #  #  # *   0
-    #  # ' # . * ( A # % * 2  * A 2 # R  '   # .    

  
v
 
w
x
y
v { w | } w  v ~
y
w
y 
v
y 
x }
 v  € { v w
y
T V W * - -  . 1 2    #  *   1      - *  # #  # 0
1 ' #  # ' %   #        *   * L #     * - -   
  #   '  -   ' #  *  2  - * 2  - * 2 #   T V W   #    #
  ' #     R   #  .       * 2     # ' #   0
' # -     A *  #    # 2  - * 2   '  -   ' # #    . *  #
*  # % # ' ( 1     R   # .  2    . #    * 2  . *  # 
ƒ  - # 1   * 2 2 (  1 # * L    T V W - * A # -    0
# ' # *  * * * 1   % #  *     * n 2  # '    # -  0
 ?  #  !   -   R  ' # % # ' ( %  3 # 2    # %  2 0
 . #  * *     '  1  - a W  *     * R  -     
-  . 1   # !    # !     *  '  #  *     # 0
1 #    # 2  - * 2   '  -   ' #  ‹ Œ   l     # - 0
   1 ' #  #   2  - * 2   '  -   ' # #  # ' .  *    %  *
  '  -   ' #  #   '     # -  - # 1   R        *
      * 1 1 '  * -  -  . .  2 (   #   . *  #
1 '  - #     *  n * 2 2 (  #  *  2   R   #  . # ' 0
 - * 2  . 1 2 # . #  *    
          # $ # & ( # ) (   - . )  . - 0
l  # 2 4 6 8 9 4 8 6 : 4 : = 2 > 6     # . *   # . *   - * 2    2
  *  * 2 2  !      #    . *  #   # 2  - * 2   '  -   ' #
 * .  2    . #    * 2  . *  #  A # 
I(x)
#   #
* a W  . *  #  !  # ' #
x = (x, y, z)
    # -   ' 0
 *  # % # -   '  l  #   '  -   ' #  #   '  R
I
  *
 ( . . #  '  - 1      % #  # .  0 # n   # . *  '  3   % #
A ( Ž
J(∇I) = ∇I ∇IT
=

I2
x IxIy IxIz
IxIy I2
y IyIz
IxIz IyIz I2
z

`  c
!  # ' #
Ix = ∂I
∂x

Iy = ∂I
∂y

Iz = ∂I
∂z
* ' #   #
# '  % *   % #   R   #  . *  # !    ' #  1 # -   
x

y
*
z
 ' #  1 # -   % # 2 ( 
l  # #   # 0 * * 2 (     R   #   '  -   ' #  #   ' * 2 0
2  !  #  # ' .  *     R   # 2  - * 2   '  -   ' * 2 R # * 0
  ' #     #  . *  #    Ž
J(∇I) = [v1 v2 v3]

µ1 0 0
0 µ2 0
0 0 µ3

[v1 v2 v3]T
` ‹ c
l  #  '      * 2 #   # % # -   ' 
v1

v2

v3
1 '  0
%  #   # 1 ' # R # ' ' # 2  - * 2  '  #  *      *   #
-  ' ' #  1    #   # % * 2  # 
µ1

µ2

µ3
` *    . #
µ1 ≥ µ2 ≥ µ3
c 1 '  %  #   # * % # ' *  # -   ' *  
* 2     #  #  ' # -      l  # n '   #   # % # -   '
v1
' # 1 ' #  #     #  ' # -     R   # . * 3  .  .
% * '  * - #  l  # ' # R  ' # 
v1
' # 1 ' #  #     #  ' # - 0
    ' . * 2     # 2  - * 2 R # *   ' # `  # # C     c 
v1
v2
v3
D  F ‘ ’ “ ” G I • – — ˜ ™ š ’ ‘ – š ‘ ’ “ K • ‘ › œ M  “  F “ › ž — › — ˜  ™  ™
• K š Ÿ “ ™ š ’ ‘ – š ‘ ’ “ š “ › ™ • ’  
µ1
¡
µ2
¡
µ3
— ’ “ š Ÿ “ “  F “ › ž
¢ — ˜ ‘ “ ™  
v1
¡
v2
¡
v3
— ’ “ š Ÿ “ – • ’ ’ “ ™ £ • › œ  › F “  F “ › ž
¢ “ – š • ’ ™  
v1
 ™ š Ÿ “ œ  ’ “ – š  • › › • ’ ¤ — ˜ š • š Ÿ “ ˜ • – — ˜
™ š ’ ‘ – š ‘ ’ “  
   O # $ ) 0 R  # & T  V .   # $  $   [ 0 R - # ) 0   _
 $ [
W         * 1  (   - * 2 1 '  - #     *  # ?   2  A ' *  # 
-  - #  ' *      # ' # - #  *  * R  -     R   . # 
!       - ' # *     ' #   '  (   . *    H  . *  #
1 '  - #      #    ( % * 2  #  1 2 * (   # '  2 #  R -  0
- #  ' *     l     A  # ' % *      # 3 1 ' #   # A (
  # ` b c 8 2 b > = : f 8 g 4 b > =    Ž
It = div(D ∇I)
` a c
562 Aplicaciones
   
It = ∂I
∂t
                        
   
I
      $  &          
t
*
∇I
    
         &    *
D
    1 2         4 &  6 6  
            
div
              $ 8
      9
div(f) =
∂f
∂x
+
∂f
∂y
+
∂f
∂z
:  < = >              $       B      
                             &        8
 2       6  &  6  &  6  I K     M 2          
D
             P        2  &             2 & 8
 2        
J
9
D = [v1 v2 v3]

λ1 0 0
0 λ2 0
0 0 λ3

[v1 v2 v3]T
S U V
   
vi
                &             2 & 8
 2         I K     6 2              6 2  
λi
  P                           6     
    &          &      $            &   
vi
I
K     6 2    
λi
   \    
0
S           V
 
1
S              V I
K         *      $ $    &   6 6          
    \  $ 6  &          $  &  6 6 ^  & &          
      &                      6  &  6    2 & 8
 2            I c     1 2    6 ^ * < = >  6 8
6                    9 d         2  
 6                   ^         6 ^ $   8
      B 2          I < = >     2      2  *
B ^    *         M  &                   B ^
   &  $  B  6            2 &  2   $              
    2        &      g h * i * h h k I
        !  " ! # $ !   $ ' ( ) $ * !

           &       ^          2 $
     M 2          
D
               8
&  6 6   q   q     &   >  M 2     S q q > V  $ 8
$    &  g h k I K   $      ^  M  &     q q >   
   $                    &      I v   
                $ $ 6     6      $   8
          &           6  &  6    2 &  2   * S   
  &                  &     *
v2
  
v3
V I
K                        6         8
  6         2 &  2   *  I  I          &   
v1
*
  $                 9              6 2 
  *    6                        I c   8
  1 2    6 ^ *
λi
          2 $   9

λ1 = g(|∇I|)
λ2 = 1
λ3 = 1
S | V
  
g
B             &  6 6 ^   &        2  & 8
    *  2 &   
g(x) = 1−exp


−3.31488
(x/K)8
*    
K > 0
 &      &        $         g h k d   2 & 8
 2      
|∇I| > K
                *
           ^    &            B  6    
                   I K         *       8
   6         $                    
 &         *    &         $           
     &   I
 
 #   -  * 0 2    $ ' ( ) $ * ! " 5 5 7 * " # 
K    2  6         < = >  $ $    &      
  6 6    9
•
S h V c   $ 2                    
s + 1
I
9       ^   4  6 9
h I c   $ 2         2 &  2        
J
 & 8
&        q 1  I S h V    S ‚ V I
‚ I c   $ 2        M 2          
D
 & 8
&        q 1  I S U V    S | V I
ƒ I d  6      $      6   M        6  1 2  8
        M 2     * q 1 I S ƒ V I
•
S ‚ V :       9       $ S h V
    ( -  7 $ # " <  $ ) # 7  2 $  " 2 $ * ! * 0 2    $ ' ( @
) $ * !   ( " 2 $ * !
K     M 2      1 2      * q 1 I S ƒ V * &   B   2    8
 &  6 6 ^   6    2    P       M     &   I K      
It = ∂I
∂t
&   B    $ 6  &   B ^   q 2 6        
  M     &   $ $   4        I K      2 6     4 8
$ 6  &    &      6 6   &  6 & 2 6         2 B   1 2   
                          6 ^ 9
I(s+1)
= I(s)
+
τ ( ∂
∂x
(D11Ix) + ∂
∂x
(D12Iy) + ∂
∂x
(D13Iz)+
∂
∂y
(D21Ix) + ∂
∂y
(D22Iy) + ∂
∂y
(D23Iz)+
∂
∂z
(D31Ix) + ∂
∂z
(D32Iy) + ∂
∂z
(D33Iz))
S … V
XVI Jornadas de Paralelismo, JP '2005 563
   
τ
 
               
I(k)   

       " $  "   
tk = kτ
      
Ix

Iy

Iz
"         , "  ,    .     " $   
     2 
x

y
"

z
      2  ,  3 4 6 
" 3 3 4 
 
Dmn
          
  2    

  .
    ; <   

  
D
6 ?    "
 "    2    
 "     D   "      "  " 3     , "  ,   F
∂
∂x

∂
∂y
"

∂
∂z
G   I "    
2 
 " 3   ;   
2   6
K
    "    
" 3  D  3  2   2     .     3 , 

$    "   " 3   ;   
 " 3  R < "  
T R 6 F X G 
   " I  3  4   "
   <  \ ] ^ 6 ?    " D   < 
       "   " 3 3     
τ ≤ 0.5/Nd
    
Nd
   
<  I    .    
  
  .      I 
3   6 K
 <  2 "     "     " 3 
$   "     
   
  
" 3    I 3     
Nd = 3
6 K
   D 
     
 2 "       < 
     d   <    "
2 
   , "  ,  , " 3 <   .
τ = 0.1
6


e f e




g  



 h
i e i g j
h
j  k  
 "  $   2 " 3   "  " 3 3  3  4     I "    
2 3 <  
    .   "         4  4      2  < 3     2   
    F p q r G "     " 4     
"
2    < 
$
 3 " .            2    <
 2 "  
I   

        " I 3      I 4   "
    " $   "   

$ " 2      
   d "
 
     
   
  2    <
 2 "  
I   
   2           
" I 3      I 4   "
    "         4 \ w ]  w w ^ 6
?    "  2    2 <    <           "  " 3 3  3    
$  "   
$     3  x F ] G   "    "         " 2 
    3  F w G     " $   "   
$     3 "
 F X G
 4 I        3 6 ?    4 I        3 2   I 
 
      ,   <      3     "    "         " 2 
    3 
   
    "
     " $   "   
$     3
I   

    6
K
     d "    " I 3  2     "  I  
  
  $
  I "    
"  4 I        3    2  2 "
I 
 "
 3 "   
   "    "         " 2  "
   
    " $   "   
$     3   " d 
$ 
 " 2 2  <

  .  " <     .   2 
        "  " 3 3  3  3 " 
.    6 ?    4 I       3   
"  
 .    €  
2    <      "
 "    x q r K .         " $ 
 "   
$ I   

    "
 r    "  .    
  "         4  "  " 3 3  3    
     
    6
?    4 I       3   
"  
  I "    

.  " <     .  €  x
•
  " 2        
s
   X    " $    <  
 "   I 4    3 "
           " D      
    2  
 .   3 "  $     " $     
  

Nz
6
•
?   <   "   .  
k
   3 "
 
Is
k
   
3 4
. <
2  
 .
Is−1
k
"
   .  < 
  $  I  <   
 3 "
  
Is
k−1

Is
k−2

Is
k+1
"

Is
k+2
    
s
 
        "  

  D "

k
 
  
     3 "
 
  D 6
?          " " " 2 2    "
    " $   .  
 €   2          4   R <     
  " ,  I  

 
       " 3 3  2 " 
$ "
 2    < 
$ 
3 4  

 2    "  4  " "

     .   <   " 
$  " 2   
$ 3 
   3 "
 6 ?   .  3 3  
$  "  " 3 3  3 " 3 $      " d  

 " 2 2  <
  <
   3 
   2     x
] 6      I < 
I0 "  
$
    
Nlocal
z
 3 "
 
 3 3 I  "    $
    " 2 
  
w 6  
s = 1, ...endstep
F " G T " 2     "  
  " 3       " < D  3  "  4
 " "   < 2 <   
F I G  
k = 2, ..., (Nlocal
z − 4)/T
Is+1
k = AND(Is
k)
T
  
F 2 G K
  2  "
$  I  <
 "  4    3 "
  I  
 

  $  I  < 
    6
X 6 T
  
‡ 6 ˆ  3 3  2     " $  6
   
Nlocal
z
 
     3  2 " 3
<  I    .  
 3 "
   .     " $  
P
 
    
<  I    .

    "

T
 
    
<  I    .    2      

    

    "

I0  
        $ 
" 3
X    " $  6
K " 
 2    "  4  2 
  3    " "      
I <  
"  3  ,  3   "
   3  ,  3 "
 "    
2      3  ,  3 
     
   x
] 6 ?    " 3
<  I    .    3 "
       
  I <   "  
$
    
Nlocal
z =
Nz/P + 4
   3 "
   3 3 I  "    $
  
 " 2 
   6 ?  " ,    
2 3 <  
$     " $ 
 "   
$ 2    <
 2 "  
   
 
 €      2    
 " 2         " 3 3
   
" 3 3  2 "  .  <  "     
" 3  3 "
     3 
.  < 
  $  I  <   3 "
  x   3 "
  .   
 " 2  I  <
 "  4   $ <   w  3 3 <   "     
564 Aplicaciones
Nz planes in memory
of one node
updated planes
in one node
z axis
updated planes by one thread

    
  
  
  
     
         
       #   &          *
+ - . / 0 2 / / 5 7 7 9 ; = + 7 - . 5 / @ B 7 D / 7 F H 9 = ; 7 D
. = B B J 9 @ . - / 7 / 5 7 J F ; - / 7 ; + = J O Q = J 9 ; - O S
F T - 9 7 D U @ - B 7 D D - V 7 F - D D @ 9 V 0
W 0 2 / F O = . 7 D D = O T 7 U 7 T H 7 - . 5 / 5 O 7 - ; ` @ T T J F b
; - / 7 @ / D D J Q D 7 / = +
(Nlocal
z −4)/T
d b F T - 9 7 D
- F F T S @ 9 V / 5 7 2 f g F O = . 7 D D H ` 5 7 O 7 - d b
F T - 9 7 = + / 5 7 D / O J . / J O 7 / 7 9 D = O - 9 ; = + / 5 7
; @ j J D @ = 9 / 7 9 D = O - O 7 . = B F J / 7 ; / = J F ; - / 7
/ 5 7 . = O O 7 D F = 9 ; @ 9 V d b F T - 9 7 = + / 5 7 @ B - V 7 0
n = . - O O S = J / / 5 @ D F O = . 7 D D H / ` = - J p @ T @ - O S
; - / - D / O J . / J O 7 D 5 - U 7 Q 7 7 9 ; 7 r 9 7 ; Q S 7 - . 5
/ 5 O 7 - ; H @ 9 = O ; 7 O / = 5 = T ; Q = / 5 / 5 7 Q = J 9 ; b
- O S d b F T - 9 7 = + / 5 7 @ B - V 7 - 9 ; / 5 7 Q = J 9 ; b
- O S d b F T - 9 7 = + / 5 7 ; @ j J D @ = 9 / 7 9 D = O H Q 7 + = O 7
/ 5 7 S - O 7 B = ; @ r 7 ; Q S / 5 7 / 5 O 7 - ; 9 7 @ V 5 b
Q = J O 0
x 9 / 5 7 9 7 p / D 7 . / @ = 9 H / 5 7 ; 7 D . O @ Q 7 ; F - O - T T 7 T
. = ; 7 ` @ T T Q 7 7 U - T J - / 7 ; = 9 - . T J D / 7 O = + y z { 0
 
|

} | ~  €

€  ~ 


| ‚ |

  




~ | ~  €

€  ƒ  
x 9 / 5 @ D F - F 7 O H ` 7 7 U - T J - / 7 / 5 7 F 7 O + = O B - 9 . 7 = + -
F = O / - Q T 7 @ B F T 7 B 7 9 / - / @ = 9 = + 2 f g b . = ; 7 - D B 7 D b
D - V 7 F - D D @ 9 V . = ; 7 - 9 ; - D 5 S Q O @ ; . = ; 7 = 9 - . T J D b
/ 7 O = + y z { B J T / @ F O = . 7 D D = O D 0 n 5 7 - @ B = + / 5 @ D
7 U - T J - / @ = 9 @ D / = ; 7 / 7 O B @ 9 7 ` 5 @ . 5 B = ; 7 T 7 p F T = @ /
Q 7 D / / 5 7 y z { . T J D / 7 O D 0
n 5 7 @ B F T 7 B 7 9 / - / @ = 9 @ D . - O O @ 7 ; = J / = 9 -
. T J D / 7 O = + Q @ F O = . 7 D D = O D = + x 9 / 7 T ‰ Š ‹ 7 = 9 ‰ n z ‹
Œ 0  Ž  ‘ d ` @ / 5 W   Š 2 z H “ ” W  . - . 5 7 0
f = ; 7 D - O 7 @ 9 / 7 O . = 9 9 7 . / 7 ; U @ - W  @ V - Q @ / • / 5 b
7 O
9 7 / 9 7 / ` = O – H = 9 7 + = O ; - / - ‰ f  y ‹ - 9 ; / 5 7
= / 5 7 O + = O . = B F J / - / @ = 9 0 n 5 O 7 7 @ B - V 7 D = + ; @ + b
+ 7 O 7 9 / D @ d 7 D ‰ Œ š › p Œ š › p Œ š › H “ ” W p “ ” W p “ ” W - 9 ;
œ Ž š p œ Ž š p œ Ž š ‹ 5 - U 7 Q 7 7 9 D 7 T 7 . / 7 ; / = ; 7 U 7 T = F
/ 5 7 7 U - T J - / @ = 9 F O = . 7 D D 0
1 3 5 7 9 11 13 15
Number of processors
10
510
1010
1510
2010
2510
3010
3510
4010
4510
5010
Runtimes(s)
mpi−size:384
hybrid−size: 384
mpi−size:512
hybrid−size:512
mpi−size:786
hybrid−size:786

         
              #   
       
   
                       #   &         
    
       
     ž    ž    ž Ÿ           
   !   !   !  *
 @ V J O 7 ΠD 5 = ` D / 5 7 O J 9 / @ B 7 D = + / 5 7 B 7 D D - V 7
F - D D @ 9 V - 9 ; 5 S Q O @ ; B = ; 7 T D U 7 O D J D / 5 7 9 J B Q 7 O
= + F O = . 7 D D = O D + = O / 5 O 7 7 @ B - V 7 D = + ; @ j 7 O 7 9 / D @ d 7 D 0
f = / @ . 7 / 5 - / ` @ / 5 Q = / 5 F - O - T T 7 T B = ; 7 T D / 5 7 O J 9 b
/ @ B 7 ; 7 . O 7 - D 7 D D J Q D / - 9 / @ - T T S ` 5 7 9 / 5 7 9 J B Q 7 O
= + F O = . 7 D D = O D @ 9 . O 7 - D 7 D - 9 ; / 5 7 @ B F O = U 7 B 7 9 /
@ D Q 7 / / 7 O ` 5 7 9 / 5 7 9 J B Q 7 O = + F O = . 7 D D = O D @ D
D B - T T 7 O 0 x / . - 9 Q 7 D 7 7 9 - T D = / 5 - / + = O - T T @ B b
- V 7 D / 5 7 B 7 D D - V 7 F - D D @ 9 V B = ; 7 T V @ U 7 D Q 7 / / 7 O
O J 9 / @ B 7 D / 5 - 9 / 5 7 5 S Q O @ ; = 9 7 + = O - T T / 5 7 7 p 7 b
. J / @ = 9 D 0
f 7 p / H / 5 7 D F 7 7 ; b J F ` @ T T Q 7 - 9 - T S d 7 ; + = O D 7 U b
7 O - T @ B - V 7 D = + ; @ j 7 O 7 9 / D @ d 7 D 0  @ V J O 7 D › - 9 ; “
D 5 = ` / 5 7 D F 7 7 ; b J F U 7 O D J D / 5 7 9 J B Q 7 O = + F O = b
. 7 D D = O D H + = O @ B - V 7 D = + D @ d 7 Œ š › p Œ š › p Œ š › - 9 ;
“ ” W p “ ” W p “ ” W O 7 D F 7 . / @ U 7 T S 0 x / . - 9 Q 7 D 7 7 9 / 5 - /
/ 5 7 B 7 D D - V 7 F - D D @ 9 V B = ; 7 T V @ U 7 D Q 7 D / D F 7 7 ; b J F
/ 5 - 9 / 5 7 5 S Q O @ ; B = ; 7 T 0  = / 5 r V J O 7 D D 5 = ` / 5 - /
` @ / 5 / ` = F O = . 7 D D = O D / 5 7 O J 9 / @ B 7 @ D ; @ U @ ; 7 ; Q S
/ ` = H - 9 ; / 5 7 D F 7 7 ; J F @ D Q 7 / / 7 O ` 5 7 9 / 5 7 D @ d 7
= + / 5 7 @ B - V 7 @ 9 . O 7 - D 7 D 0
 = O / 5 7 @ B - V 7 = + D @ d 7 œ Ž š p œ Ž š p œ Ž š @ / ` - D 9 = /
XVI Jornadas de Paralelismo, JP '2005 565
1 3 5 7 9 11 13 15
Number of Processors
1
3
5
7
9
11
13
15
Speed−up
Image size: 384x384x384
mpi
hybrid
ideal

    
                      
     
 $  
     '  )                   0         

      

         5
6 8 9 9 ; = ? @ B 8 D E G B I @ K L M O P 8 Q @ 8 G T @ W G 8 Q @ 9
Q E @ B 8 B I @ I ; Y I @ D Z @ Z 8 D \ D @ ] E ; D @ Z @ G B 9 8 T B I ; 9
; Z ` Y @ a b D ` Q ; B ; 8 G ` ? ? \ c B I @ @ e ` ? E ` B ; 8 G 8 T B I @
9 6 @ @ Q O E 6 E 9 @ 9 ` 9 D @ T @ D @ G P @ B I @ 9 @ ] E @ G B ; ` ? B ; Z @ c
` Y @ G @ D ` ? Q @ k G ; B ; 8 G 8 T B I @ m 6 @ @ Q O E 6 I ` 9 = @ @ G
; G B D 8 Q E P @ Q = \ K n ? p q r s B 8 E 9 @ 8 G @ 6 ` D ` ? ? @ ? D E G O
B ; Z @ ` 9 D @ T @ D @ G P @ ; G 9 B @ ` Q 8 T B I @ 9 @ ] E @ G B ; ` ? 8 G @ a
 8 D B I @ ; Z ` Y @ 8 T 9 ; x @ z { | } z { | } z { | B I @ k D 9 B
6 ` D ` ? ? @ ? D E G B ; Z @ ; 9 W ; B I @ ; Y I B 6 D 8 P @ 9 9 8 D 9 c B I E 9 c
B I @ Y @ G @ D ` ? 9 6 @ @ Q O E 6 W ; ? ? = @ Q @ k G @ Q ` 9 T 8 ? ? 8 W 9 
speedup(8, P) =
T8
TP
€ z 
W I @ D @
T8
` G Q
TP
` D @ B I @ D E G B ; Z @ 9 T 8 D T 8 E D
` G Q
P
6 D 8 P @ 9 9 8 D 9 D @ 9 6 @ P B ; e @ ? \ a
 ; Y E D @ { 9 I 8 W 9 B I @ 9 6 @ @ Q O E 6 Q @ k G @ Q ; G @ ] a
z e @ D 9 E 9 B I @ G E Z = @ D 8 T 6 D 8 P @ 9 9 8 D 9 T 8 D B I @ Z @ 9 O
9 ` Y @ 6 ` 9 9 ; G Y ` G Q B I @ I \ = D ; Q Z 8 Q @ ? 9 a … ? @ ` D ? \ c
= 8 B I Z 8 Q @ ? 9 I ` e @ ` e @ D \ Y 8 8 Q 9 6 @ @ Q O E 6 ` G Q
9 P ` ? @ 9 W @ ? ? c @ 9 6 @ P ; ` ? ? \ T 8 D B I @ Z @ 9 9 ` Y @ 6 ` 9 9 ; G Y
Z 8 Q @ ? c W I @ D @ ` 9 B I @ I \ = D ; Q Z 8 Q @ ? 9 P ` ? @ 9 ` = ; B
? @ 9 9 c 9 ; G P @ ; B G @ @ Q 9 Z 8 D @ Z @ Z 8 D \ D @ 9 8 E D P @ 9 B 8
` ? ? 8 P ` B @ B I @ ` E } ; ? ; ` D \ Q ` B ` 9 B D E P B E D @ 9 a
b I @ P 8 Q @ ; 9 9 P ` ? ` = ? @ 8 G Z E ? B ; 6 D 8 P @ 9 9 8 D 9
D ` G Y ; G Y T D 8 Z B W 8 B 8 B W @ G B \ @ ; Y I B 6 D 8 P @ 9 9 8 D 9 a
‹ G ` Q Q ; B ; 8 G c G 8 B ; P @ B I ` B
Nz = Nx = Ny
T 8 D P 8 G 9 ; Q @ D @ Q B @ 9 B ; Z ` Y @ 9
= @ B B @ D 6 @ D T 8 D Z ` G P @
P ` G = @ 8 = B ` ; G @ Q ; T B I @ x O Q ; Z @ G 9 ; 8 G 8 T B I @ ; Z O
` Y @ e @ D ; k @ 9 
Nz >> Nx, N, y
a
1 3 5 7 9 11 13 15
Number of processors
1
3
5
7
9
11
13
15
Speed−up
Image size: 512x512x512
mpi
hybrid
ideal

    
                      
     
 $  
     '  )                   0         

      

 Ž   Ž   Ž  5
 

‘
’

“ ” • 
‘
” —
‘
˜  “ ™ “ š
 
 š  ”
‹ B P ` G = @ P 8 G P ? E Q @ Q T D 8 Z B I @ @ e ` ? E ` B ; 8 G B I ` B
B I @ I \ = D ; Q ; Z 6 ? @ Z @ G B ` B ; 8 G 8 T B I @ K L M O P 8 Q @
` ? ? 8 W 9  € œ  B 8 D @ Q E P @ 9 ; Y G ; k P ` G B ? \ B I @ D E G B ; Z @
8 e @ D ` ? ` D Y @ D ` G Y @ 8 T ; Z ` Y @ 9 9 ; x @ c 9 6 @ P ; ` ? ? \ T 8 D
; Z ` Y @ 9 8 T ? ` D Y @ 9 ; x @ 9 ` G Q € q  B 8 = @ D E G 8 G Q ; T O
T @ D @ G B n ; G Q 8 T 6 ` D ` ? ? @ ? 6 ? ` B T 8 D Z 9 a
b I @ @ e ` ? E ` B ; 8 G 9 I 8 W 9 B I ` B B I @ 6 ` D ` ? ? @ ?
K L M O P 8 Q @ ; 9 9 P ` ? ` = ? @ 8 G Z E ? B ; 6 D 8 P @ 9 9 8 D 9 D ` G Y O
; G Y T D 8 Z B W 8 B 8 B W @ G B \ @ ; Y I B 6 D 8 P @ 9 9 8 D 9 c ` 9 W @ ? ?
` 9 B I @ Z @ 9 9 ` Y @ 6 ` 9 9 ; G Y Z 8 Q @ ? ` P I ; @ e @ 9 = @ B B @ D
6 @ D T 8 D Z ` G P @ ; G P ? E 9 B @ D 9 8 T = ; 6 D 8 P @ 9 9 8 D 9 a
‹ G T E B E D @ W 8 D n 9 c ` G @ e ` ? E ` B ; 8 G 8 T B I @ K L M O
P 8 Q @ W ; ? ? = @ Q @ e @ ? 8 6 @ Q ; G ` G @ } B @ G Q @ Q D ` G Y @
8 T 6 ? ` B T 8 D Z 9 a
 


š
 ‘
’

”
p œ s  a  @ ; P n @ D B c
           ! "         
$  &    &      a b @ E = G @ D c œ Ÿ Ÿ | a
p q s   a   @ D 8 G ` ` G Q  a ¡ ` ? ; n c  m P ` ? @ 9 6 ` P @
` G Q @ Q Y @ Q @ B @ P B ; 8 G E 9 ; G Y ` G ; 9 8 B D 8 6 ; P Q ; T O
T E 9 ; 8 G c       $   "  $   "
 $ ' " * $ + "
   & ' " c e 8 ? a œ q c 6 6 a { q Ÿ ¢ { r Ÿ c œ Ÿ Ÿ £ a
p r s  a  @ ; P n @ D B c  … 8 I @ D @ G P @ O @ G I ` G P ; G Y Q ; ¤ E O
9 ; 8 G k ? B @ D ; G Y c     " / " 2    "  &  5      c
e 8 ? a r œ c 6 6 a œ œ œ ¢ œ q z c œ Ÿ Ÿ Ÿ a
566 Aplicaciones
8 10 12 14 16 18 20 22 24 26 28
Number of processors
1.0
2.0
3.0
Speed
up
mpi−image size: 768
hybrid−image size: 768
ideal

    
                  
       
 " 
     %  '                  .         
 
      
          3
4 5 6  8 : ; = > : @ B C  D E F : @ : I = : J : I F K I = ; I L N ; O Q J
R ; E I E T = E V E Q @ ; X K L : R C        
    
        C Z E V 8 [ \ C ] ] 8 ^ _ [ ` ^ [ ^ C [ b b b 8
4 c 6  8 : ; = > : @ B K I N f 8 h = F K @ @ C  i R = F : X :
T E @ = E F : @ : I = : J : I F K I = ; I L N ; O Q R ; E I o V B : @ J
; I L q ; B F E ] B ; X ; t : N @ E B K B ; E I ; I Z K @ ; K I = : C 
 
           
  #    C Z E V 8 [ w C
] ] 8 [ _ w ` [ [ x C ^ _ _ ^ 8
4 y 6 z 8 z : @ ; L C | 8
; > ; I ; R C

8
Q } V : @ C K I N & 8 i 8
 E V : R t C  ~ E I V ; I : K @ K I ; R E B @ E ] ; = o V B : @ ; I L E T
 | „ N K B K C       #               C
Z E V 8 [ [ C ] ] 8 ^ ^ [ ` ^ w ^ C [ b b ^ 8
4 \ 6 „ 8  K  V K K I N „ 8 f E V V K I N : @ C  ~ E I V ; I : K @ o V J
B : @ ; I L E T X K L I : B ; = @ : R E I K I = : B E X E L @ K X R
} ‡ L : E X : B @ ‡ J N @ ; Z : I N ; O Q R ; E I C    *    

            *       C Z E V 8 [ _ C ] ] 8 ^ 5 w `
^ c c C [ b b x 8
4 x 6

8 z F ; B K C
8 | E } ; I R E I C  8 . ‡ I = F C K I N
Š 8 & 8 F : V K I C   | „ N ; O Q R ; E I J } K R : N o V B : @ J
; I L Πi I E B : E I ] : @ T E @ X K I = : = F K @ K = B : @ ; R K J
B ; E I C        #         *           

#     *  C Z E V 8 ^ b C ] ] 8 ^ y \ ` ^ \ \ C ^ _ _ c 8
4 b 6 i 8 h 8 & @ K I L K > ; R K I N | 8 f : L : @ V C  ~ E ; R :
@ : N Q = B ; E I ; I : V : = B @ E I B E X E L @ K ] F ; = @ : = E I J
R B @ Q = B ; E I R Q R ; I L I E I V ; I : K @ K I ; R E B @ E ] ; = N ; T J
T Q R ; E I C      #  *       C Z E V 8 [ w c C ] ] 8 ^ w b `
^ c _ C ^ _ _ [ 8
4 [ _ 6 i 8 h 8 & @ K I L K > ; R C i 8 h B E R = F : > C K I N
| 8 f :
L : @ V C  K Z : V : B B @ K I R T E @ X o V B : @ ; I L
K I N I E I V ; I : K @ K I ; R E B @ E ] ; = N ; O Q R ; E I K R J
R : R R : N T E @ R ; L I K V @ : = E I R B @ Q = B ; E I ] : @ T E @ J
X K I = : E I X Q V B ; N ; X : I R ; E I K V } ; E X : N ; = K V
N K B K C       #                  # )
    C Z E V 8 5 x C ] ] 8 ^ [ w ` ^ ^ ^ C ^ _ _ [ 8
4 [ [ 6  8  8 & : @ I K I N : t K I N h 8 . ; C  i I ; X ] @ E Z : N
K V L E @ ; B F X T E @ K I ; R E B @ E ] ; = I E I V ; I : K @ N ; T J
T Q R ; E I T E @ N : I E ; R ; I L = @ ‡ E J B E X E L @ K X R C   
  #  *       C Z E V 8 [ 5 5 C ] ] 8 [ c ^ ` [ y [ C ^ _ _ w 8
4 [ ^ 6

8  : N K V ; K C „ 8 : } : @ C i 8 h 8 & @ K I L K > ; R C
• 8 ~ ; = K R B @ E C z 8 z : @ ; R = F C K I N 8  K Q X : ; R J
B : @ C   K = @ E X E V : = Q V K @ K @ = F ; B : = B Q @ : ; I : Q J
> K @ ‡ E B ; = = : V V R Z ; R Q K V ; t : N } ‡ = @ ‡ E : V : = B @ E I
B E X E L @ K ] F ‡ C   *    *  C Z E V 8 ^ b x C ] ] 8 [ ^ _ b `
[ ^ [ w C ^ _ _ ^ 8
4 [ w 6
8 z @ Q I : q K V N C Š 8 • : R K ; C • 8 D 8 ; I J
> V : @ C  8  8 f : ‡ X K I I C • 8  8  : V I K ] C
8  K Q X : ; R B : @ C K I N i 8 D 8 h B : Z : I C  ˜ F @ : : J
N ; X : I R ; E I K V R B @ Q = B Q @ : E T F : @ ] : R R ; X ] V : ™
Z ; @ Q R T @ E X = @ ‡ E J : V : = B @ E I B E X E L @ K ] F ‡ C 
 *    *  C Z E V 8 w _ ^ C ] ] 8 [ w b y ` [ w b x C ^ _ _ w 8
4 [ 5 6  8  : = > C & 8 & E @ R B : @ C  8 š = > : C  8  8
Š V ; B t > E C & 8  : V = F ; E @ C z 8 z : @ ; R = F C
8  K Q X : ; R B : @ C K I N

8  : N K V ; K C  ~ Q = V : K @
] E @ : = E X ] V : ™ R B @ Q = B Q @ : K I N N ‡ I K X ; = R
@ : Z : K V : N } ‡ = @ ‡ E : V : = B @ E I B E X E L @ K ] F ‡ C 
 *    *  C Z E V 8 w _ y C ] ] 8 [ w x \ ` [ w b _ C ^ _ _ 5 8
4 [ c 6  8 D ‡ @ > V K O C D 8 | ; R = E C  8  8 & : @ I K I N : t C
 8  8  ; X : I : t C  8 š R B : } K I C 8  K Q X : ; R J
B : @ C K I N  8 . 8 D K @ @ K R = E R K C  D @ ‡ E J : V : = B @ E I
B E X E L @ K ] F ‡ E T Z K = = ; I ; K Z ; @ Q R C  + #  *      
*     *     C Z E V 8 [ _ ^ C ] ] 8 ^ \ \ ^ ` ^ \ \ \ C
^ _ _ c 8
4 [ y 6 8 f 8 Š @ : R R C  8 Š 8 & V K I I : @ ‡ C h 8 i 8 ˜ : Q > E V J
R > ‡ C K I N 8 ˜ 8  : B B : @ V ; I L C    #  *  

 *         #     *       *      )
   8 D K X } @ ; N L :  I ; Z : @ R ; B ‡ Š @ : R R C [ b b ^ 8
4 [ \ 6  8  8 & : @ I K I N : t C  8 D K @ K t E C K I N „ 8 z K @ J
= ; K C  ˜ F @ : : J N ; X : I R ; E I K V @ : = E I R B @ Q = B ; E I E T
= : V V Q V K @ R B @ Q = B Q @ : R } ‡ : V : = B @ E I X ; = @ E R = E ] :
B E X E L @ K ] F ‡ K I N ] K @ K V V : V = E X ] Q B ; I L 8   
+  #    ,    #          C Z E V 8 y 5 C ] ] 8 ^ x c `
w _ _ C ^ _ _ 5 8
XVI Jornadas de Paralelismo, JP '2005 567
   

 
  
   
     " # %
' (   ' *
  +  
 -
.
   0 2 
'   ' * 
7   8 7

9 ;
%
9 = #  ' # ' 7  '
  *  A C 9  # ' E 7 
  ' -  
                        . # 7  G  I I 
K L  M N  O   L L  
 L  + 
 C ; '  U    # 8      9 ;
 
U   # ; 7 8
 -
  

 
    
 C '  ' - 
 ' * Y  Z ; ' #       - ; I
 = #  %  '
7 C 9 _

 # % I C   ' - a   ; K _ e ' # ' 7  '
  *  A C _
9  # ' E 7 
 9                   . # 7   O 
I I  N  M i   j O O N 
j O  e 
   9 ;   + = C ' *  %
'   7 
7    # ' _
9 ;  I 8
 a

' 8  7  
  7 E 7 
  ' -   *  I _
  .
9 % # #  ;  ' -  ' *  ;
' # ' 7  '
  *  A C _
9  # '
p C    # '                     
            . # 7  j N  I I   N N M  N G  j O O j 
j     Z ;  '   r  Z  ' - ;  ! 

7  
  ' * " 

 9 a  9   
9 9  -
I  9 9  ' -  ' * 9 ;  
*  * _
* 
9 9 9 I 
I    7 7
7  9 % # '  ' Z  r 7 C 9
_

              $      . # 7  j L  I I 
 z G M   z  j O O K 
j j    


C  ' '   r    7 7
7 I  # -   % %  ' -  '
a   ; % I   ' * # I
' % I    

        
j O O N 
j K  Z  |  +  7   Z C I
 7  '
  I
 = #  %  '

 ' 
 7 _   %
I    7 7
7 # % I C     # '    
$       $       $      . # 7  j L  ' #   
I I   L M     j O O N 
568 Aplicaciones
Implementación de dos algoritmos paralelos para la detección
automática del Plano Sagital Medio en Imágenes de Resonancia
Magnética
Iván C. Lausuch..
Escuela Superior de Enseñanzas
Técnicas.
Universidad Cardenal Herrera. CEU.
Mª Carmen Juan
Dep. Sistemas Informáticos y de la
Computación.
Universidad Politécnica de Valencia
Antonio M. Vidal
Dep. Sistemas Informáticos y de la
Computación.
Universidad Politécnica de Valencia
Resumen
Presentamos la paralelización de un algoritmo
automático para el cálculo del plano sagital medio
en imágenes de resonancia magnética. El
algoritmo calcula el factor de simetría existente
entre los dos hemisferios del cerebro. Se trata de
un algoritmo de búsqueda exhaustiva que explora
el plano sagital medio entre un conjunto de
posibles planos. Primero se calcula el centro de
masas para obtener un punto del plano y a
continuación se analiza el ángulo óptimo.
Exponemos dos soluciones, en la primera los
procesadores esclavos poseen toda la imagen, por
lo que cada procesador trabaja sobre un conjunto
de ángulos. En la segunda, la imagen se subdivide
a lo largo del eje Z entre todos los procesadores.
Para analizar el grado de simetría se han aplicado
tres funciones diferentes: diferencia de
intensidades, por centro de masas y la información
mutua.
Tras estudiar experimentalmente los dos
algoritmos concluimos que el algoritmo más
rápido corresponde a la segunda opción donde se
realiza una subdivisión del trabajo en el espacio
de la imagen. También se obtiene que utilizando 5
procesadores un speedup del 60%.
1. Introducción.
Determinar la simetría entre los dos hemisferios
del cerebro humano es una de las técnicas que se
utiliza en el análisis de imágenes cerebrales y en
especial para la detección de patologías [1]
La simetría consiste en comparar dos zonas
prácticamente idénticas para detectar anomalías.
La mayoría de aproximaciones requieren un
conocimiento de información a priori sobre el tipo
de simetría que se persigue (rotacional o bilateral).
Uno de los primeros estudios fue presentado por
Atallah [2], en este caso los objetos se debían
presentar como puntos, líneas o círculos. Reisfeld
el a. [3] consiguen la detección por simetría sin
necesidad de una previa segmentación de los
objetos. Keller [4] consigue utilizar la técnica pero
basada en análisis de Fourier. Tuzikov et al. [5]
comenta por primera vez la utilización de la
simetría en el análisis de cerebros.
Para poder calcular factores de simetría es
necesario especificar un plano que divida el
cerebro en dos mitades iguales o similares. Este
plano se conoce con el nombre de plano sagital
medio. Es el primer paso para la orientación de la
imagen cerebral para así ajustarla a algún tipo de
sistema de coordenadas cerebral (Ejm. Talairach
[6]). Puede usarse como primer paso del registro
de elementos cerebrales [7] o sirve de base para el
estudio de anomalías cerebrales [5] como ya
hemos comentado. Existen varios algoritmos
capaces de detectar el plano sagital medio en
imágenes 3D [6, 7, 8, 9 ,10 ,11]
La búsqueda de este plano requiere basarse en
el análisis por simetrías. En principio, los dos
hemisferios son similares, pero al comparar un
hemisferio con su opuesto reflejado aparecen una
gran cantidad de pequeñas diferencias que los
diferencian. Si el algoritmo trabaja con cerebros
afectados por alguna patología estos problemas se
agravan aún más. Si el registro está basado en un
cuerpo rígido, las pequeñas diferencias hacen
necesario el uso de técnicas para medir la
similitud [12], como por ejemplo la información
mutua [13,14,15].
En los próximos puntos se estudian dos
algoritmos implementados y su paralelización.
También se realiza un estudio del coste asociado a
la comunicación de datos y resultados.
2. Materiales y métodos
El objetivo perseguido en este trabajo es la
identificación del Plano Sagital Medio en
imágenes de Resonancia Magnética y la
paralelización del proceso.
El cálculo del plano sagital medio requiere
determinar 6 incógnitas. Tres corresponden a un
punto del plano sobre el que se centra el mismo y
sobre el que se realizan las rotaciones. Las tres
últimas corresponden a las rotaciones posibles en
los tres ejes o lo que es equivalente, al vector
normal del plano. Para centrar el plano se utiliza
el cálculo del centro de masas de la imagen de
resonancia magnética. Para el cálculo de la
rotación del plano hemos implementado un
algoritmo de búsqueda exhaustiva, este algoritmo
no busca en todo el dominio de rotaciones
posibles del plano sino que bajo previo
conocimiento del problema acotamos el problema
a rotaciones en Z y ángulos en el dominio
> @
ȕº
,
ȕº
 con respecto al eje y. Se ha simplificado,
considerando que las rotaciones en los ejes x e y
no son significativas Del mimo modo hemos
acotado el rango de ángulos de búsqueda para
simplificar el hecho de que las imágenes tomadas
de resonancia magnética no poseen ángulos con
respecto al eje Z de más de ȕº grados a izquierda
o a la derecha.
Para el desarrollo de estos dos algoritmos se
ha optado por una implementación basada en
Java. Del mismo modo ha sida necesaria la
creación de una interfaz para enlazar los
algoritmos desarrollados en java con el MPI. Se
ha desarrollado un módulo de comunicación MPI
implementado en lenguaje C. El programa Java y
el módulo de comunicación en C se comunican
entre si mediante tuberías del sistema operativo
Linux.
2.1. Cálculo del centro de masas
El cálculo del PSM consiste en determinar 6
incógnitas. Tres corresponden a un punto del
plano, este punto es necesario para poder aplicar
rotaciones. Estas rotaciones son las tres incógnitas
restantes.
En primer lugar, hay que calcular y localizar
el punto del plano sobre el que realizar los giros.
Las características de este punto son importantes.
En primer lugar, como en principio no se van a
realizar movimientos del punto una vez fijado, el
plano queda confinado a las posibles rotaciones
respecto a dicho punto. Esto implica que es
recomendable que el punto debe encontrarse en el
centro del cerebro. La forma de calcular este
punto es el cálculo del centro de masas de la
imagen entendiendo como masa la intensidad de
cada pixel. Dado que el cerebro es idealmente
simétrico, atendiendo a cualquier corte en Z, este
punto está justo en el centro de los dos
hemisferios. El hecho de utilizar todo el cerebro
favorece que las anomalías que provoca el
instrumento de adquisición de la muestra o alguna
patología como es un tumor, se diluyan gracias a
que estos errores y patologías corresponden a un
pequeño porcentaje del volumen cerebral total.
¦
¦
dx
<
z
dy,
<
y
dx,
<
x
z=
y=
=
x
dz
<
z
dy,
<
y
dx,
<
x
z=
y=
=
x
x
z
y
x
I
x
z
y
x
I
=
CM
0
0,
0,
0
0,
0,
]
,
,
[
*
]
,
,
[
(1)
La ecuación 1 corresponde al cálculo de la
componente x del centro de masas, donde dx, dy y
dz son los tamaños de la MRI y la función
 
z
y,
x,
I devuelve el valor de la intensidad en el
pixel  
z
y,
x, . La ecuación de las componentes x e
y es equivalente.
2.2. Cálculo del plano sagital medio.
El punto calculado es el centro del plano y a partir
del cual se realizan rotaciones. El cálculo del
vector normal del plano subyace a partir de estas
rotaciones. Aunque debiéndose realizar rotaciones
sobre los tres ejes para obtener el vector normal
570 Aplicaciones
del plano hemos simplificado el cálculo a tan solo
rotaciones respecto el eje Z. Las rotaciones en el
resto de los ejes suelen ser muy pequeñas y
además los estudios realizados sobre las muestras
han determinado que las demás rotaciones no
aportan una notable contribución al análisis de
tumores basados en simetría.
El algoritmo del cálculo del plano sagital medio se
basa en realizar una búsqueda exhaustiva del
ángulo óptimo. Para mejorar el coste temporal se
ha limitado la búsqueda a un rango de rotaciones,
y en particular > @
ȕº
,
ȕº
=
Į 
. Para determinar el
ángulo óptimo se aplica una función de simetría.
Esta función, en el contexto estudiado, es aquélla
que mide la simetría (similitud) entre los dos
hemisferios. Por tanto la rotación óptima es
aquélla que maximiza la función de similitud.
 
  ȕ
Į
ȕ
Į
f
MAX
=
Įopt d
d
 (2)
Como hemos comentado, la función de
simetría compara los dos hemisferios dada una
rotación estudiada respecto el eje Z. Un punto P1
será simétrico a P2 si se cumple la ecuación 2.
N
d
+
P
=
P
&
&
&


2
1
2 (3)
La ecuación 3 corresponde a la condición de
simetría. Donde d es la distancia de P1 al plano y
N es el vector normal del plano estudiado. Para
cuantificar el factor de simetría se ha utilizado el
sumatorio de deferencias de intensidades.
 
   
 
_ _
¦


i
H
p
p
S
I
p
I
=
Į
f
1
(4)
La ecuación 4 corresponde a la función de
simetría basada en diferencia de intensidades
donde para todos los puntos pertenecientes al
hemisferio izquierdo i
H
p
se calcula la
diferencia de intensidad  
p
I de este punto con
respecto a su punto simétrico  
 
p
S
I
correspondiente al hemisferio opuesto (Ec 5).
N
d
+
P
=
P
&
&
&


2
1
2 (5)
Otra función de similitud aplicable está basada
en las técnicas de información mutua [13,14,15].
Dicha técnica se basa en calcular el grado de
información mutua o equivalencia entre los dos
hemisferios. Se divide el cerebro en dos mitades
dado el PSM auxiliar. Se calcula la imagen
simétrica de uno de los dos hemisferios y se aplica
la función de información mutua entre estas dos
imágenes. Este algoritmo se basa en el mismo
principio de simetría del algoritmo anterior, pero
aplicando la información mutua, por lo que la
función de simetría es óptica cuando se maximiza
el grado de información mutua.
Se ha implementado un tercer algoritmo que
se basa en dividir los dos hemisferios por el PSM
auxiliar. A continuación se calculan los centros de
masas de cada uno de los dos hemisferios.
Finalmente, la función de simetría evalúa el
ángulo Į que forma el vector normal del plano y
el vector formado a partir de los dos centros de
masas como muestra la ecuación 6. El PSM que
obtenga el ángulo Į más próximo a 0 será el
óptimo.
 
normal
d
i PSM
CM
CM
arcos
=
Į ˜ (6)
La ecuación 6 corresponde a la función de
simetría basada en centros de masas. Donde
d
iCM
CM es el vector normalizado formado por
los puntos i
CM
y d
CM
.El vector normal
PSM
es
el vector normal del plano también normalizado.
2.3. Paralelización del plano sagital medio.
Se han diseñado dos estrategias en la
paralelización del algoritmo del cálculo del PSM.
La primera de ellas consiste en dividir el dominio
de búsqueda entre los distintos procesadores. Para
ello, todos los procesadores esclavos reciben toda
la imagen y cada uno de ellos se encarga de un
rango de dominio de ángulos de búsqueda. Si el
dominio total es > @
ȕº
,
ȕº
 para un procesador i, su
rango de búsqueda será:
XVI Jornadas de Paralelismo, JP '2005 571
  «
¬
ª
«
¬
ª





P
ȕ
+
i
+
ȕ
,
P
ȕ
i
+
ȕ
=
domi
2
1
2
(7)
La ecuación 7 corresponde al dominio de
búsqueda del procesador i. Siendo P el número
total de procesadores esclavos.
La segunda estrategia se basa en la división de
la propia imagen de resonancia magnética a lo
largo del eje Z entre los procesadores esclavos
como muestra la ecuación 8.
  «
¬
ª
«
¬
ª


P
N
+
i
,
P
N
i
=
dom'i 1 (8)
En este algoritmo todos los procesadores
calculan el ángulo óptimo para su parte de la
imagen remitiendo posteriormente sus resultados
al maestro para realizar el cálculo del ángulo
óptimo global.
2.4. Algoritmo paralelo basado en la división
del dominio de búsqueda
En este algoritmo los procesadores trabajan sobre
toda la imagen con lo que el coste inicial de
difusión de la información será el siguiente:
ȕ
c
datos Nt
+
t
=
t (9)
La ecuación 9 muestra el coste temporal
asociado a la difusión inicial de datos. En la
ecuación aparecen dos factores que hacen
referencia a la calidad de la comunicación. El
factor c
t corresponde al coste temporal necesario
para comunicar un mensaje entre dos máquinas.
El factor E
t corresponde al coste temporal
requerido por cada byte transmitido. En esta
ecuación, ningún factor es multiplicado por el
número de procesadores P ya que asumimos que
la distribución la hemos realizado mediante
difusión de la información. En el caso de no poder
realiza difusión la ecuación queda multiplicada
por el número de procesadores.
Una vez recopilados los datos iniciales se
procede al cálculo del centro de masas. Como
cada uno de los procesadores posee toda la
imagen, cada uno de ellos calculará el centro de
masas y éste será para todos el mismo, de esta
forma ahorramos en comunicación. El coste de
calcular el centro de masas para todo el volumen
de información es tcm
A continuación se debe realizar la búsqueda del
PSM óptimo. Para ello cada procesador obtiene un
PSM óptimo en su subdominio de búsqueda. Los
PSM óptimos junto con el error asociado de la
función aplicada para ese plano se reúnen en el
procesador maestro. Éste realizará un simple
cálculo final de selección del plano óptimo. Si el
coste de cálculo del PSM para cada ángulo es
psm
C
el coste por cada procesador es:
psm
psm C
P
iter
=
t
=
iter
Ȝ
E
2
(10)
Finalmente el maestro recoge el ángulo
óptimo de cada procesador junto con el error
obtenido. El coste de esta reunión es el siguiente:
 
ȕ
c
res T
+
T
P
=
t
2 (11)
Para finalizar calculamos el coste total del
algoritmo (Ec. 12).
res
psm
cm
datos t
+
t
+
t
+
t
=
t
    ȕ
c
cm
psm t
P
+
N
+
t
P
+
+
C
+
C
P
iter
=
t 2
1
(12)
2.5. Algoritmo paralelo basado en el dominio
de la imagen.
Este otro algoritmo se basa en dividir la imagen
entre los distintos procesadores. Por tanto el
proceso maestro debe repartir la imagen entre los
distintos procesadores. El cálculo teórico de esta
difusión de la información corresponde a la
ecuación 13.
572 Aplicaciones
ȕ
c
ȕ
c
datos t
N
+
t
P
=
t
P
N
+
t
P
=
t'

¸
¹
·
¨
©
§
(13)
En este caso la difusión es más costosa
respecto a la ecuación 13 ya que no se puede
utilizar la difusión debido a que cada procesador
recibe una parte de la imagen.
El cálculo del centro de masas también debe
ser paralelizado. Para ello se divide la ecuación 1.
Teniendo en cuenta los subdominios de la imagen
establecidos. Primero se establece una función F
para describir el dividendo y otra función G para
describir el divisor. La ecuación del centro de
masas para la componente x corresponde a la
siguiente ecuación.
 
 
¦
¦
P
=
p
=
p
x
P
=
p
=
p
x
x
x
x
p
g
p
f
=
P
F
=
CM
0
0
(14)
Se entiende la función F como el sumatorio de
funciones f(p) (ecuación 15) parciales. Del
mismo modo la función G como el sumatorio de
funciones g(p) (ecuación 16 Cada una de estas
funciones la resuelve el procesador esclavo i
correspondiente.
    x
z
y,
x,
I
=
p
f
dz'
<
dy,z
<
y
dx,
x<
=
z
=
y
=
x
p
x
¦
0
0,
0,
(15)
  ¦
dz'
<
z
dy,
<
y
dx,
<
x
z=
y=
=
x
p
x z
y
x
I
=
p
g
0
0,
0,
)
,
,
( (16)
Téngase en cuenta que la función
 
z
y,
x,
I p
devuelve la intensidad del píxel en el subdominio
de la imagen del procesador p. También hay que
tener en cuenta que dz' corresponde al tamaño
parcial de la imagen en el eje z para el procesador
p y equivale a la ecuación P
dz
=
dz' .
La función
 
p
f x multiplica las intensidades
en un punto dado por la componente x de dicho
punto. La función
 
p
fy es equivalente a
 
p
f x .
Pero la componente z se ve afectada por la
división de la imagen a lo largo del eje Z, por lo
que se le debe aplicar un desplazamiento. Esto se
resuelve en la siguiente ecuación.
    ¸
¹
·
¨
©
§


¦ P
dz
p
+
z
z
y,
x,
I
=
p
f
dz'
<
z
dy,
<
y
dx,
<
x
=
z
=
y
=
x
p
z
0
0,
0,
(17)
La función f proporciona tres resultados
     
 
p
f
,
p
f
,
p
f z
y
x y la función g devuelve solo un
resultado. En base a estos cálculos podemos
resolver el coste temporal del algoritmo del centro
de masas distribuido. También se incluye la
difusión de resultados al procesador maestro.
master
cm
ȕ
c
cm
cm C
+
t
+
t
+
P
C
=
t'
4 (18)
La ecuación 18 corresponde al coste temporal
del cálculo del centro de masas. La constante
cm
C
ya se ha comentado y corresponde al tiempo
del análisis para un ángulo de la imagen. La
constante
master
cm
C corresponde al cálculo final del
maestro. Siendo cm
master
cm C
C 

Una vez calculado el centro de masas se
procede a calcular el plano sagital medio.
El algoritmo propuesto para el cálculo del
plano sagital medio consiste en dividir el cálculo
de la similitud simétrica entre todos los
procesadores. Por tanto para cada ángulo
estudiado se resuelve la ecuación de simetría.
Utilizando como ejemplo la función de simetría
basada en diferencias de intensidades resolvemos
la paralelización de la misma. Cada procesador
(que posee un subdominio de la imagen) resuelve
la ecuación 19.
     
 
_ _
¦


p
H
i
p i
S
I
i
I
=
Į
f'
(19)
El cálculo del factor de simetría se completa
con la reunión de los datos en el procesador
maestro y calculándose el factor de simetría
utilizando la ecuación 20.
XVI Jornadas de Paralelismo, JP '2005 573
 
 
¦
P
=
p
=
p
p Į
f
=
Į
F'
0
1
(20)
En el algoritmo basado en la división de la
imagen, la comunicación intermedia es importante
ya que para cada ángulo el maestro recibe las
soluciones parciales de cada uno de los
procesadores esclavos. Por tanto asumiendo que el
algoritmo realiza una búsqueda exhaustiva a lo
largo del rango > @
ȕ
ȕ,
 con una resolución de paso
Ȝ , se calcula el número de iteraciones como
> @
Ȝ
ȕ
ȕ,
=
iter

. Como hemos comentado, cada
ángulo (iteración) requiere la reunión de las
soluciones parciales por lo que el coste temporal
es el descrito en la ecuación 21.
master
psm
ȕ
c
psm
psm C
+
t
+
t
+
P
C
iter
=
t'
¸
¸
¹
·
¨
¨
©
§
(21)
Se puede mejorar el coste de la reunión de
datos si empaquetamos todos los resultados y son
enviados al final en un único mensaje. Esto
disminuye el coste de envío del mensaje y no
afecta al coste de las operaciones finales como
muestra la ecuación 22.
master
psm
c
ȕ
psm
psm C
+
t
+
t
+
P
C
iter
=
t'
¸
¸
¹
·
¨
¨
©
§
(22)
La elección al aplicar rotaciones únicamente
sobre el eje Z es crucial con respeto a la eficiencia
del algoritmo por lo siguiente: Si aplicásemos
rotaciones sobre cualquier eje y al distribuir la
imagen dividiéndola a lo largo del eje Z, la
función de simetría  
p
S utilizaría puntos no
disponibles por el procesador que realiza dicho
cálculo. Con lo que se aumentaría drásticamente
la comunicación. La solución intuitiva sería
distribuir toda la imagen a todos los procesadores
con lo que podríamos aplicar la versión 1 del
problema.
El coste del algoritmo paralelizado se expone
en la ecuación 23.
res
psm
cm
datos +t'
+t'
+t'
t'
=
t'
    ȕ
c
master
psm
master
cm
psm
cm
t
iter
+
N
+
t
iter
+
p
C
+
C
+
P
C
iter
+
C
=
t'


2
+
+ (23)
3. Resulltados
Se han realizado un total de tres experimentos. Se
han empleado un total de 10 resonancias
magnéticas. Estas poseen un tamaño de 256x256
con 96 cortes en el eje Z (6 Mb aprox).
Se ha utilizado una red de 5 ordenadores con
las siguientes características:
x Procesador: Pentium IV 2Ghz
x RAM: 256 MBytes
x SO: Linux Debian 3.3.5-6
x Kernel: 2..4.27-386
x MPI: Lam 7.0.5
x Compilador C: gcc 3.3
x Comunicación: WIFI protocolo 802.11g.
La tabla 1 corresponde al primer experimento,
donde hemos aplicado el algoritmo basado en la
división del espacio de la imagen. El rango de
búsqueda es de -8º a 8º. Se utiliza la técnica del
cálculo del factor de simetría basado en la
diferencia de intensidades. Se realizan dos
estudios comparando distintas resoluciones de O .
Procesadores ȁ=0.1 ȁ=1
1 921,466 95,989
2 733,684 70,023
3 481,354 50,245
4 346,059 48,688
5 306,865 46,556
Tabla 1. Coste temporal (segundos) del algoritmo
basado en el dominio de la imagen.
Se puede comprobar como el aumento del
número de procesadores implica una mejora del
coste temporal. Los resultados también
demuestran que el coste de comunicación es
importante ya que el speed-up obtenido con una
resolución de paso de un grado (16 iteraciones) es
del 41%, mientras que con una resolución de paso
de la décima parte (160 iteraciones) el
574 Aplicaciones
rendimiento asciende al 60%, obteniendo del
mismo modo, un plano más preciso.
En el segundo experimento se estudia el coste
temporal del algoritmo basado en la división del
espacio de búsqueda. En este caso el rango de
búsqueda también es de -8º a 8º. Se utiliza la
técnica de simetría de diferencia de intensidades.
Procesadores Ȝ=0.1
1 887,352
2 795,795
3 573,606
4 495,325
5 471,961
Tabla 2. Coste temporal (segundos) del algoritmo
basado en el dominio de búsqueda.
En la tabla 2 se observa como el speed-up para 5
procesadores es de un 37%, mucho menor que en
el primer caso. Esto es debido a que el coste del
envío de los datos iniciales es mucho más grande
que en el primer algoritmo a causa de la
incapacidad de la red de realizar difusiones.
El tercer experimento compara la velocidad de
los algoritmos del cálculo de simetría como
muestra la figura 1.
Figura 1. Relación del coste temporal de los tres
métodos de simetría
El algoritmo basado en centro de masas, aún
siendo el más rápido, obtiene una tasa de fallos
del 30%. Mientras que los otros dos algoritmos
poseen una tasa de aciertos del 100% en los casos
estudiados. Siendo el algoritmo de diferencias de
intensidad con el mejor ratio de
efectividad/velocidad.
En las siguientes figuras se ilustran algunos de
los casos estudiados.
Figura 2. Ejemplo del cálculo del Plano Sagial Medio.
Figura 3. Ejemplo del cálculo del Plano Sagial Medio.
Figura 4. Ejemplo del cálculo del Plano Sagial Medio.
4. Conclusiones
En este artículo hemos presentado dos algoritmos
paralelizados para la búsqueda del plano sagital
medio. Este problema lo hemos resuelto con dos
0
10
20
30
40
50
60
70
80
90
100
Centos de masas Diferencias de
intensidad
Información
mutua
XVI Jornadas de Paralelismo, JP '2005 575
algoritmos de búsqueda exhaustiva y con tres
técnicas para el cálculo del grado de similitud.
Hemos comprobado como la paralelización de
los algoritmos mejoran el coste temporal del los
mismos. Concluyendo, que el algoritmo basado en
la subdivisión de la imagen se obtienen mejores
resultados, con speed-up del 60%.
La incapacidad de realizar difusiones merma
en gran medida la efectividad del primer
algoritmo provocando que este sea más lento que
el segundo.
También se comprueba como el algoritmo de
diferencias de intensidad es el mejor de los tres ya
que es un 28% más rápido que el algoritmo
basado en información mutua. Del mismo modo, y
a pesar de su tasa de fallos del 30%, el algoritmo
basado en centros de masas es un 40% más rápido
que el basado en información mutua. Éste último
puede ser utilizado para aproximar o mejorar los
resultados de los otros dos algoritmos.
Agradecimientos
Parcialmente financiado por el Ministerio de
Educación y Ciencia Español y fondos FEDER.
Proyecto TIC2003-08238-C02-02
Referencias
[1] Z. Wang, Q. Hu, K. Loe, A. Aziz, and W.L.
Nowinski. “Rapid and automatic detection of
brain tumors in MR images” Proc. of SPIE
Medical Imaging, San Diego, 2004.
[2] J.R. Atalah, “On symmetry detection” IEEE
Transaction on computers, pp. 663-66, 1985.
[3] D. Reisfeld, H. Wolfson, and Y. Yeshurun,
“Detection of interest points using symmetry”
Proc. of ICCV, Tokyo, pp 62-65, 1990
[4] T. Keller, “An algebraic approach to
symmetry detection” Proc. of ICPR,
Cambridge, 2004
[5] A.V. Tuzikov, O. Colliot, I. Bloch,
“Evaluation of the symmetry plante in 3D MR
brain images” Pattern Recognition Letters,
2003.
[6] Y. Liu, R. Collins, andW. Rothfus. Robust
midsagittal plane extraction fromnorm al and
pathological 3D neuroradiology images. IEEE
Transactions on Medical Imaging, 20(3):175–
192, 2001
[7] B. Ardekani, J. Kershaw, M. Braun, y Kanno.
Automatic detection of the mid-sagittal plane
in 3D brain images. images. IEEE
Transactions on Medical Imaging, 16(6):947
952, 1997.
[8] Tuzikov, A.V. V, Colliot, O. Bloch I,
“Evaluation of the symmetry plante in 3D MR
brain images” PRL, Nº 14, Ocober 2003, pp
2219-2233
[9] S. Prima, S. Ourselin, and N. Ayache.
Computation of the Mid-Sagittal Plane in 3D
Images of the Brain. In D. Vernon, editor,
Sixth European Conference on Computer
Vision, ECCV’2000, volume 1842-3 of
Lecture Notes in Computer Science, pages
685–701, Dublin, Irlande, 2000. Springer.
[10] C. Sun and J. Sherrah. 3-D symmetry
detection using the extended Gaussian image.
IEEE Transactions on Pattern Analysis and
Machine Intelligence, 19(2):164–168, 1997.
[11] J.-P. Thirion, S. Prima, G. Subsol, and N.
Roberts. Statistical Analysis of Normal and
Abnormal Dissymmetry in Volumetric
Medical Images. Medical Image Analysis,
4(2):111–121, 2000.
[12] J. Maintz and M. Viergever. A survey of
medical image registration. Medical Image
Analysis, 2(1):1–36, 1998.
[13] Wells, William M. Viola, Paul, Atsumi,
Hideki, Nakajima, Shin and Kikins, Ron.
Multi-modal volume registration by
maximization of mutual information, Medical
Image Analysis, vol 1, number 1. Oxford
University Press, 1996
[14] Maes, Frederik, Collignon, André,
Vandermeulen, Dirk, Marchal, Guy, and
Suetens, Paul, Multimodality Image
Registration by Maximization of Mutual
Information. Transactions on medical imagin,
vol 16, no 2, April 1997
[15] Maes, Frederik , Vandermeulen, Dirk and
Suetens, Paul. Comparative evaluation of
multiresolution optimization strategies for
multimodality image registration by
maximization of mutual information, Medical
Image Analysis, vol 3, número 4, Oxford
University Press, 1999
[16] M. Snir, S. W. Otto, S. Huss-Lederman, D.
W.Walker, and J. Dongarra. MPI - The
complete Reference. MIT Press, 1997.
576 Aplicaciones
Procesamiento de imágenes según LogGP: un estudio analítico
Pere Millán
Dept. d’Enginyeria Informàtica i Matemàtiques
Universitat Rovira i Virgili
Av. Països Catalans, 26
43007 Tarragona
pere.millan@urv.net
Eduard Montseny
Dept. d’Eng. Sistemes, Automàtica i Informàtica Industrial
Universitat Politècnica de Catalunya
Pau Gargallo, 5
08028 Barcelona
eduard.montseny@upc.edu
Resumen
En este artículo analizamos un nuevo método de
particionado de imágenes para procesamiento
paralelo en sistemas distribuidos: SSIP (Sub-Strip
Image Processing). El estudio se realiza según el
modelo paralelo LogGP y el objetivo es minimizar
el tiempo de inactividad de los procesadores, para
reducir el tiempo de ejecución respecto al método
paralelo clásico. Dicho método particiona la
imagen en franjas y envía una a cada procesador
en un solo mensaje. SSIP fragmenta en subfranjas
que se envían en varios mensajes, permitiendo un
mayor solapamiento de cálculo y comunicación.
De esta forma los procesadores inician antes el
cálculo y se reducen sustancialmente los tiempos
de espera. Presentamos las fórmulas de cálculo del
tamaño de las subfranjas y el procedimiento a
utilizar. Las simulaciones realizadas indican que
el método clásico es hasta un 70% más lento que
SSIP, y que SSIP consigue eficiencias superiores
al 95% en una gran parte de las simulaciones.
1. Introducción
El procesamiento de imágenes (especialmente las
aplicaciones industriales en tiempo real) requiere
una enorme potencia de cálculo, muy superior a la
ofrecida por los actuales PCs y estaciones de
trabajo. El procesamiento en paralelo se presenta
como la única solución para obtener la potencia de
cálculo necesaria. Alternativamente, en el pasado
se han utilizado superordenadores vectoriales o
arquitecturas específicas, pero desde hace unos
años hay un interés creciente en el procesamiento
paralelo distribuido. El uso de arquitecturas tipo
cluster se ha disparado por las altas prestaciones y
gran disponibilidad de microprocesadores y redes
de interconexión de bajo coste.
La utilización de métodos analíticos [7]
permite modelar el sistema y el algoritmo de
procesamiento de imágenes, de forma que en una
etapa inicial del diseño se conocen los factores
que determinan el rendimiento del sistema, así
como las ecuaciones que modelan las relaciones
entre los parámetros. Los diferentes sistemas se
caracterizan por unos pocos parámetros, que
incorpora el modelo. Así se puede predecir el
rendimiento en la fase de diseño y conocer como
afectan los parámetros a dicho rendimiento.
El objetivo de nuestro trabajo es conseguir
que los nodos estén el mínimo tiempo posible
inactivos, para que el procesamiento de imágenes
finalice lo antes posible. En sistemas de tiempo
real, cualquier reducción del tiempo de ejecución,
aunque sea pequeño, es deseable. Nuestro método
SSIP envía inicialmente la mínima cantidad de
datos posibles a los procesadores para que
empiecen a calcular cuanto antes, y mientras están
procesando los datos iniciales, se van enviando los
restantes, solapando comunicación y cálculo,
evitando que los nodos se queden sin datos. Este
método ya lo presentamos en [10], pero ahora
utilizamos LogGP en lugar del anterior modelo de
comunicación lineal. En este artículo analizamos
el particionado y distribución de datos, pero no la
recepción de resultados.
La principal aportación es la presentación y
análisis de SSIP que consigue mejores tiempos
por la reducción del tiempo de inactividad.
En el resto del artículo la sección 2 presenta el
procesamiento de imágenes a paralelizar y sus
parámetros. La sección 3 trata el método clásico,
su tipo de particionado de imagen y presenta el
modelo LogGP. La sección 4 aborda SSIP, las
condiciones y el cálculo de subfranjas. Los dos
métodos se comparan en la sección 5. La sección
6 concluye con un breve resumen.
2. Procesamiento de imágenes
Una imagen está formada por una matriz de
puntos (píxels). Las imágenes se almacenan en
forma de tablas bidimensionales, por filas. Los
parámetros que definen una imagen son el número
de filas(Nh), columnas(Nw) y bytes por píxel(Bi).
2.1. Descripción del procesamiento
El procesado de imágenes de bajo nivel obtiene
una imagen resultado a partir del procesado de los
píxels de una imagen origen. El tipo de procesado
que utilizamos es de tipo vecindad local mediante
el uso de ventanas. En este tipo de procesado, el
valor de cada píxel resultado se obtiene a partir
del valor del píxel de la imagen original y de
aquellos que se hallan en un entorno próximo,
dentro de la ventana: Mh filas y Mw columnas.
Nuestro estudio es aplicable en general a este
tipo de procesamiento, y no entramos en el detalle
de la operación o ventana específica que se utiliza.
La información necesaria se resume en Tpix:
tiempo necesario para calcular un píxel de la
imagen resultado. Bo es el número de bytes para
almacenar la información de cada píxel resultado.
Un problema que se plantea al trabajar con
cálculos de vecindad es el cálculo de los valores
de la frontera (los píxels de los extremos de la
imagen), ya que no se disponen de todos los píxels
necesarios para el cálculo. Hay varias alternativas.
Nosotros calculamos sólo los píxels para los que
se dispone de todos los valores. Ello provoca que
la imagen resultado sea menor que la original, ya
que no se pueden calcular los píxels de la frontera.
El tamaño de la imagen resultado es (Nh–Mh+1)
filas y (Nw–Mw+1) columnas (figura 1).
Nh
Imagen original
Imagen resultado
Ventana
Mh
Mw
Nw
Nw–Mw+1
Nh–Mh+1
Figura 1. Tamaños de imágenes y ventana
Ahora ya se puede calcular Tseq: tiempo de
procesamiento secuencial de una imagen. Dado el
tamaño de la imagen original y de la ventana,
sabemos el número de píxels del resultado, y con
el tiempo de cálculo por píxel obtenemos:
Tseq = (Nh–Mh+1)·(Nw–Mw+1)·Tpix (1)
3. Procesamiento paralelo
Para acelerar el procesamiento de la imagen, se
utiliza un sistema distribuido tipo cluster, formado
por P ordenadores conectados a través de una red
de interconexión. Suponemos que todos los nodos
tienen la misma potencia de cálculo y el cluster se
dedica en exclusiva a procesar la imagen. El
modelo de comunicación es mediante paso de
mensajes, utilizando una librería como MPI.
El tipo de paralelismo apropiado para trabajar
con procesamiento de imágenes es el paralelismo
de datos. Esta forma de paralelismo [13] divide la
imagen en trozos, y cada nodo procesa un trozo.
Para tener equilibrio de carga entre los nodos, se
les asigna a todos la misma cantidad de datos.
Usamos un esquema de funcionamiento tipo
master/slave. El procesador master (P0) dispone
de la imagen original, y es quien particiona y
distribuye cada trozo a cada procesador slave (los
P–1 procesadores restantes: P1 … PP–1). El master
no realiza ningún cálculo de resultado, se encarga
únicamente de la comunicación.
3.1. Particionado de la imagen
El particionado de la imagen se realiza de acuerdo
a su tamaño y al número de slaves. Hay que tener
en cuenta la estructura de la imagen para reducir
el coste de comunicación entre master y slaves. El
tiempo de comunicación es mínimo [4, 11, 12]
cuando los datos a transferir se hallan de forma
consecutiva en memoria (no hay que agruparlos
antes de enviarlos a través de la red). Como las
imágenes se almacenan por filas, se envía a cada
slave una franja, formada por un cierto número de
filas consecutivas de la imagen. La granularidad
(tamaño mínimo de datos) es de una fila/línea de
las imágenes.
Otro aspecto a considerar es el de los valores
de la frontera. Para calcular el resultado de los
píxels superiores e inferiores de una franja, son
578 Aplicaciones
necesarios los valores extremos superior e inferior
de la franja (según el tamaño de la ventana). Por
ello, cada franja deberá disponer de las líneas
superiores e inferiores adyacentes a dicha franja.
El particionado se realiza de forma que cada
uno de los P–1 slaves procesa el mismo número
de filas, para equilibrar la carga (figura 2). La
cantidad R de filas a calcular por cada slave es
(supondremos que el resultado es exacto):
R = (Nh–Mh+1) / (P–1) (2)
Nw
Nw–Mw+1
Franja R+Mh–1
R
Figura 2. Tamaños de franja (P = 5)
El tamaño de la franja original (kin), resultado
(kout) y el tiempo Tstrip para procesar una franja es:
kin = (R + Mh – 1) · Nw · Bi (bytes)
kout = R · (Nw – Mw + 1) · Bo
(3)
Tstrip = R · (Nw – Mw + 1) · Tpix (4)
3.2. Modelo paralelo LogGP
El funcionamiento del sistema paralelo se modela
según LogGP [1], una extensión del modelo LogP
[5]. Estos modelos abstraen las características del
sistema basándose en un reducido número de
parámetros, y son comúnmente aceptados como
modelos realistas de comunicación en programas
paralelos. Una de sus características es que
diferencian entre el tiempo utilizado en la red y el
tiempo utilizado en el ordenador, lo cual permite
solapar comunicación con cálculo.
LogP refleja los costes de comunicación de
mensajes cortos en máquinas de memoria
distribuida. Utiliza cuatro parámetros: (1) L: límite
superior de la latencia de la red; (2) o (overhead):
periodo de tiempo durante el cual el procesador
está ocupado enviando o recibiendo un mensaje
(durante este tiempo el procesador no puede
realizar otras tareas); (3) g (gap): intervalo
mínimo de tiempo entre envíos o recepciones
consecutivas (la inversa de g indica el número de
mensajes que se pueden enviar por unidad de
tiempo); (4) P: número de procesadores en el
sistema. LogGP extiende a LogP representando el
incremento de ancho de banda para mensajes
largos proporcionado por hardware especial. El
parámetro G o Gap per byte es el tiempo entre
bytes consecutivos de un mensaje, siendo 1/G el
máximo ancho de banda efectivo. Según LogGP
el envío de un mensaje de k bytes (figura 3) tarda
o + (k–1)G + L + o (g no aparece en esta ecuación,
ya que sólo se envía un mensaje).
L
g
(k-1)·G
P0
G G G G
P1
P2
o
send
G G
o
receive
o
send
Figura 3. Paso de mensajes según LogGP
Para enviar un mensaje de k bytes primero hay
o unidades de tiempo de sobrecarga de envío para
introducir el primer byte en la red. Los siguientes
bytes tardan G unidades de tiempo cada uno en
entrar. El último byte entra en o+(k–1)G. Cada
byte atraviesa la red en L unidades de tiempo. Por
tanto el último byte sale de la red en el instante
o+(k–1)G+L. Finalmente el procesador receptor
dedica o unidades de tiempo en sobrecarga, por lo
que el mensaje entero está disponible en el
procesador receptor en el instante o+(k–1)G+L+o.
Los procesadores fuente y destino están ocupados
sólo durante el tiempo o, el resto del tiempo
pueden solapar comunicación y cálculo.
3.3. Procesamiento paralelo clásico
En el procesamiento paralelo de imágenes clásico
[8] primero el master envía la franja completa de
la imagen que cada slave debe procesar, sólo
cuando los slaves han recibido la franja completa
la empiezan a procesar, y finalmente envían la
franja resultado al master (figura 4).
El procesamiento clásico solapa comunicación
y cálculo entre diferentes slaves pero, desde el
punto de vista de un slave, éste sólo puede estar
esperando datos, comunicando o procesando.
XVI Jornadas de Paralelismo, JP '2005 579
P0
P1
P2
PP-1
Latency, Gap
overhead computation
Figura 4. Esquema de procesamiento clásico
El procesamiento clásico minimiza el coste de
comunicación enviando un sólo mensaje grande
con los datos, en lugar de varios de tamaño menor,
pues al agrupar varios pequeños en uno mayor se
transmite en menos tiempo. Pero así los slaves
empiezan a procesar más tarde, prolongando la
ejecución, por el tiempo inicial inactivo.
Para calcular el tiempo total de ejecución
paralela clásica, consideraremos por separado la
sobrecarga de envío (os) y la de recepción (or), ya
que hay sistemas con valores significativamente
diferentes. También supondremos que el mensaje
resultado es más corto que el original (kin > kout).
Para cualquier slave p (1…P–1) tenemos:
Trun p = 2(os+L+or) + (p–1)·max{g, os}+
+[p(kin–1) + (kout–1)]·G + Tstrip
(5)
El tiempo total del procedimiento clásico es el
del último slave que acaba (P–1).
El cálculo del tiempo que un slave p pasa
ocioso hasta que empieza a recibir su franja es:
Tidle p=os+(p–1)[(kin-1)G+max{g,os}]+L (6)
4. Procesamiento paralelo subfranja
SSIP disminuye el tiempo inactivo de los slaves,
reduciendo la espera inicial hasta recibir los
primeros datos. La idea es al principio transferir a
todos los slaves la mínima cantidad de datos
necesaria para que empiecen a procesar. El resto
de datos se van transfiriendo mientras cada slave
procesa los datos anteriores. Así, cada slave recibe
varios mensajes hasta disponer de toda la franja
(la comunicación tarda más que en el sistema
clásico), pero empieza a procesar tras recibir el
primer mensaje, sin esperar toda la franja. Así
conseguimos solapar comunicación y cálculo no
sólo de diferentes slaves sino también de cada
slave, con envíos y cálculos múltiples (figura 5).
P0
P1
P2
PP-1
Figura 5. Esquema de procesamiento SSIP
4.1. Particionado subfranja
Para que el master pueda distribuir todos los
datos, primero debe calcular el tamaño de todas
las subfranjas. Sea D el número de subfranjas en
que se dividen las R líneas de cada franja. El
número de líneas ds de una subfranja s (s=1…D)
debe garantizar:
d1 + d2 + … + ds + … + dD = R (ds≥1) (7)
Para obtener el tamaño de las subfranjas, hay
que tener en cuenta dos condiciones, que se
enuncian como:
• Condición {1}: la primera subfranja debe ser
la más pequeña que asegure que todos los
slaves empiezan a procesar con el mínimo
retardo.
• Condición {2}: el resto de subfranjas debe
poderse distribuir con el mínimo número de
mensajes, pero teniendo en cuenta que los
slaves deben tener siempre datos a procesar.
Así pues, la cantidad de líneas de la primera
subfranja debe ser tal que asegure que todos los
slaves empiezan a procesar con el mínimo retardo
y garantizando que, cuando se haya enviado la
primera subfranja al último slave, el primero
todavía tiene datos para seguir procesando. Para la
primera subfranja, como son necesarias Mh filas
de datos para obtener una de resultados (efecto de
la ventana), el primer mensaje debe contener
(d1+Mh–1) filas y su tamaño kd1 (en bytes) es:
kd1 = (d1 + Mh – 1)·Nw·Bi (8)
El tamaño kds del resto de subfranjas es:
kds = ds·Nw·Bi (s = 2…D) (9)
El número de subfranjas debe minimizarse
para reducir el efecto de la sobrecarga (os, or) de
comunicación de cada mensaje. Esto implica que
la siguiente subfranja debe transferirse a todos los
580 Aplicaciones
slaves en un tiempo igual o inferior al tiempo de
procesado de la subfranja anterior.
Así pues, mientras el último slave procesa una
subfranja, el master debe enviar la siguiente
subfranja a todos los slaves. Esto implica que el
número de líneas de la siguiente subfranja debe
ser igual al máximo natural que verifique que el
tiempo de procesado es mayor que el tiempo de
comunicación.
Para la primera subfranja (s=1) y cualquier
slave p, la inecuación que debe satisfacerse es:
or + d1(Nw–Mw+1)Tpix ≥
≥ (P–1)·max{g, os}+
+ [(P–p–1)·(kd1–1)+ p·(kd2–1)]·G
(10)
El tiempo de sobrecarga de recepción más el
tiempo de procesado de la primera subfranja debe
ser superior o igual al tiempo de comunicación. Se
debe enviar la primera subfranja a los slaves
posteriores al actual, y la segunda subfranja a
todos los slaves anteriores y a él mismo.
Generalizando la inecuación (10) a cualquier
subfranja s (1…D) y slave p (1…P–1), obtenemos
la inecuación que se debe satisfacer:
s·or + ¦
=
s
i
i
d
1
·(Nw–Mw+1)·Tpix ≥
≥ s·(P–1)·max{g, os}+
+[(P–p–1)·(kd1–1)+
+(P–1)· ¦
=
−
s
i
i
kd
2
)
1
( +
+ p·(kds+1 –1)]·G
(11)
La inecuación (11) nos permite evaluar el
tamaño y número de subfranjas que hay que
enviar a cada slave del sistema. Observación:
tomando s = 1 en (11) se obtiene (10).
4.2. Cálculo de los tamaños de las subfranjas
El procedimiento que utilizamos para obtener las
diferentes ds es de tipo progresivo con back-
tracking. De (11) deducimos la expresión:
ds+1 ≤ f(…) (12)
(12) representa el tamaño máximo de
subfranja que se puede transmitir, en función del
tiempo disponible (sobrante) del envío y cálculo
de las subfranjas anteriores. Como para calcular
ds+1 hay que tener las ds previas, lo primero es
calcular d1. Obtenemos un límite inferior para d1
despejándola en (10) y tomando d2=1 (para que,
como mínimo, quede tiempo para enviar luego
una línea). Si el límite está entre 0 y 1, se toma
d1=1 (minimizando la espera inicial). Si el límite
es negativo o superior a R, nos encontramos en el
caso clásico, y tomamos d1 = R (D = 1).
A partir del valor de d1, se van calculando,
uno a uno, los siguientes valores. Para ello se
toma el máximo natural que satisfaga (12). Se
finaliza al completar las R líneas de la franja (y se
deduce D). Es posible que la última subfranja sea
de un tamaño menor que la indicada por (12), ya
que no quedan más líneas en la franja.
En el caso de que (12) indique algún valor
menor que 1, nos encontramos con que el tiempo
disponible para enviar la siguiente subfranja no
alcanza para que contenga una línea completa. Es
el momento de hacer back-tracking: hay que
incrementar d1 y recalcular las subfranjas, hasta
que se cumpla {2}. En el caso límite tendríamos
d1 = R (caso clásico). Así, logramos un tiempo
mejor que el clásico o, en el caso límite, igual.
5. Comparativa con el modelo clásico
Vamos a determinar la mejora obtenida con SSIP,
respecto al método clásico. Como no se considera
la recepción de los resultados (que sí incluye (5)),
el valor para comparar será el tiempo que tarda
PP–1 en procesar toda su franja.
Aplicando (5) a PP–1 y eliminando la parte de
envío del resultado, tenemos el tiempo clásico:
TendClassic = os + L + or +(P–1)(kin–1)G +
+ (P–2)·max {g, os} + Tstrip
(13)
En SSIP el tiempo para que PP–1 acabe de
procesar se calcula sabiendo que a partir del
momento que recibe la primera subfranja, iniciará
su procesado (en un tiempo Tstrip, pues dispondrá
de los datos cuando los necesite) y sólo tendrá que
esperar el or de las D subfranjas. Así, tenemos:
TendSSIP = os+L+D·or + (P–1)(kd1–1)G +
+ (P–2)·max {g, os} + Tstrip
(14)
La diferencia entre (13) y (14) nos indica la
reducción de tiempo conseguida:
Timprove = (1 – D)·or +
+ G·Nw·Bi·[(Nh–Mh+1) – d1· (P–1)]
(15)
XVI Jornadas de Paralelismo, JP '2005 581
Se puede observar que para conseguir buenas
mejoras es deseable que D sea pequeño (para
“pagar” menos or) y que d1 también tenga un valor
pequeño (para que los slaves estén inactivos
menos tiempo hasta recibir la primera subfranja).
5.1. Parámetros de la comparativa
Vamos a usar dos tipos de imagen: 640×320
(pequeña, p) y 2000×4500 (grande, g). Los
valores de Nh se ajustan a (Nh+Mh–1) para que R
sea exacto. Los píxels ocupan 1 byte (Bi=1).
Las ventanas son cuadradas, de dos tamaños y
con dos velocidades de procesamiento (tabla 1).
Tabla 1. Parámetros de la ventana de procesamiento
Ventana procesado Mh Mw Tpix
Pequeña lenta (pl) 3 3 5 µs
Pequeña rápida (pr) 3 3 0,1 µs
Grande lenta (gl) 9 9 100 µs
Grande rápida (gr) 9 9 0,5 µs
La tabla 2 muestra los tiempos secuenciales de
acuerdo a (1).
Tabla 2. Tiempo de procesamiento secuencial (Tseq)
Imagen
Ventana 640×320 2000×4500
3×3 5 µs 1,018 s 44,98 s
3×3 0,1 µs 20,352 ms 899,6 ms
9×9 100 µs 19,968 s 898,4 s
9×9 0,5 µs 99,84 ms 4,492 s
Respecto al número de procesadores (P) son 4
valores: 3, 5, 9 y 17 (2, 4, 8 y 16 slaves).
En el caso de los parámetros LogGP, se
utilizan los indicados en la tabla 3, obtenidos de la
literatura disponible [2, 3, 4, 6, 9].
Tabla 3. Parámetros LogGP utilizados (en µs)
Sistema L os or g G
Intel Paragon 6,5 1,4 2,2 7,6 0,07
Meiko CS-2 7,5 1,7 1,6 13,6 0,08
Quadrics/MPI 9,25 2,26 6,87 7,25 0,00514
Myrinet/MPI 10 8,21 2,56 7,17 0,00606
GigE/MPI 18,2 8,05 7,18 5,87 0,00874
IA-64 Cluster 13,62 5,9 5,9 14,6 0,00448
El particionado clásico de la imagen en franjas
(tabla 4) se consigue aplicando (2).
Tabla 4. Tamaños de particionado en franjas (R)
Slaves (P–1)
Imagen 2 4 8 16
640×320 320 160 80 40
2000×4500 1000 500 250 125
5.2. Resultados obtenidos
La tabla 5 (al final del artículo) presenta los
resultados obtenidos para cada sistema. Las 3
primeras columnas son el tamaño de la imagen, la
ventana y el número de procesadores utilizados.
Para cada sistema las 3 columnas iniciales son el
resultado de particionar según SSIP. Las dos
siguientes corresponden al speed-up (Tseq/Tpar)
del método clásico (SuC) y de SSIP (SuS). La
columna %T es el porcentaje de tiempo que es
más lento el método clásico que SSIP, calculado
como: 100*(Tclass–TSSIP)/ TSSIP. Aunque no se
indica, también hemos calculado la eficiencia
respecto al número de slaves (speed-up /(P–1) ).
El particionado obtenido se puede clasificar en
4 tipos (columna T de la tabla 5):
• Tipo A (D=1; d1=R): corresponde al método
clásico y no aporta ninguna mejora (0%). La
eficiencia está entre 6,81 y 46,78%, indicando
una pobre utilización del sistema, por el alto
coste de comunicación respecto al de cálculo.
El tipo A es más frecuente en los sistemas con
redes lentas (Paragon y Meiko). En los demás
sistemas son muy pocos (2 o menos) los casos
tipo A, consiguiendo SSIP mejores tiempos.
• Tipo B (D=2; d1=1; d2=R–1): se envía 1 línea
inicial y el resto en el segundo mensaje. La
mejora en tiempo es inferior al 1,9%, pero es
debido a que la eficiencia en el caso clásico es
muy alta, y hay poco margen para mejoras. La
eficiencia de SSIP es superior al 99% en todos
los casos.
• Tipo C (D>2, d1=1): la primera subfranja tiene
tamaño mínimo. La mejora alcanza casi un
35% en algún caso. La eficiencia conseguida
es superior al 97,5% para todos los casos. La
primera subfranja es mínima, reduciendo la
espera inicial. Como en el tipo B, el margen
de mejora no es demasiado elevado (eficiencia
alta en el método clásico).
• Tipo D (D>2, d1>1): es el de mayor mejora
(entre un 7 y un 70%), pero con una eficiencia
no tan buena (entre 44 y 99%). Al disponer de
582 Aplicaciones
más de 2 subfranjas se consigue un mayor
grado de solapamiento, pero al no ser mínima
la subfranja inicial, la espera inicial es mayor
y la eficiencia se resiente.
6. Conclusiones y trabajos futuros
SSIP es un nuevo método de particionado y
distribución para procesamiento paralelo de
imágenes. Aplicando SSIP se obtienen subfranjas
que reducen el tiempo inactivo de los nodos y se
logra un mayor solapamiento de comunicación y
cálculo. Las simulaciones muestran que el método
clásico es hasta un 70% más lento que SSIP.
En la actualidad estamos estudiando el envío
de las franjas resultado al master y también
deseamos validar experimentalmente SSIP.
Referencias
[1] A. Alexandrov, M. Jonescu, K.E. Schauser,
and C. Scheiman, “LogGP: Incorporating
Long Messages into the LogP Model – one
step closer towards a realistic model for
parallel computation”, Proc. 7th ACM Symp.
on Parallel Algorithms and Architectures,
Santa Barbara, California, 95-105, July 1995.
[2] S.M. Bataineh, “Toward an analytical solution
to task allocation, processor assignment, and
performance evaluation of network of
processors”, J. of Parallel and Distributed
Computing, 65(1):29-47, January 2005.
[3] C. Bell, D. Bonachea, Y. Cote, J. Duell, P.
Hargrove, P. Husbands, C. Iancu, M.
Welcome, and K. Yelick, “An Evaluation of
Current High-Performance Networks”, Int.
Parallel and Distributed Processing Symp.
IPDPS, Nice, France, April 22-26, 2003.
[4] K.W. Cameron, and R. Ge, “Predicting and
Evaluating Distributed Communication
Performance”, Proc. Supercomputing 2004
Conf., Nov. 6-12, 2004.
[5] D. Culler, R. Karp, D. Patterson, A. Sahay, K.
Schauser, E. Santos, R. Subramonian, and T.
Eicken, “LogP: Towards a Realistic Model of
Parallel Computation”, Proc. 4th ACM Symp.
on Principles and Practices of Parallel
Programming, vol 28, pp. 1-12, May 1993.
[6] D. Culler, L. Liu, R. Martin, and C.
Yoshikawa, “LogP Performance Assessment
of Fast Network Interfaces”, IEEE Micro,
February 1996.
[7] Juhasz, Z. “An Analytical Method for
Predicting the Performance of Parallel Image
Processing Operations”, The Journal of
Supercomputing, 12, 157-174 (1998).
[8] C. Lee, and M. Hamdi, “Parallel image
processing applications on a network of
workstations”, Parallel Computing,
21(1):137-160, 1995.
[9] R.P. Martin, A.M. Vahdat, D.E. Culler, and
T.E. Anderson, “Effects of communication
latency, overhead, and bandwidth in a cluster
architecture”, Proc. 24th
ISCA Int. Symp. on
Computer Architecture, Denver, 1997, 85-97.
[10] P. Millán, and E. Montseny, “On Real Time
Image Processsing on a Network of PCs”,
Proc. IEEE Int. Workshop on Computer
Architecture for Machine Perception
CAMP’05, Terrasini, Palermo, July 2005.
[11] M. Prieto, I. Llorente, and F. Tirado, “Data
Locality Exploitation in the Decomposition of
Regular Domain Problems”, IEEE Trans. on
Parallel and Distributed Systems,
11(11):1141-1149, Nov. 2000.
[12] F.J. Seinstra, and D. Koelma, “P-3PC: a
point-to-point communication model for
automatic and optimal decomposition of
regular domain problems”, IEEE Trans. on
Parallel and Distributed Systems, 13(7):758-
768, Jul. 2002.
[13] L. Uhr, “Parallel Computer Vision”,
Academic Press, 1982.
Tabla 5. Resultados obtenidos para los 6 sistemas utilizados
Intel Paragon Meiko CS-2 Quadrics/MPI
I V P D d1 T SuC SuS %T D d1 T SuC SuS %T D d1 T SuC SuS %T
p pl 3 3 1 C 1,94 2,00 2,81 3 1 C 1,94 2,00 3,21 2 1 B 2,00 2,00 0,20
p pr 3 6 192 D 0,83 1,08 30,29 4 249 D 0,76 0,88 15,75 4 1 C 1,81 1,99 10,05
p gl 3 2 1 B 2,00 2,00 0,14 2 1 B 2,00 2,00 0,16 2 1 B 2,00 2,00 0,01
p gr 3 6 2 D 1,54 1,98 28,25 7 2 D 1,50 1,98 32,24 3 1 C 1,96 2,00 2,07
g pl 3 3 1 C 1,95 2,00 2,80 3 1 C 1,94 2,00 3,20 3 1 C 2,00 2,00 0,21
g pr 3 9 575 D 0,83 1,11 32,92 5 754 D 0,77 0,90 17,82 5 1 C 1,81 2,00 10,26
XVI Jornadas de Paralelismo, JP '2005 583
g gl 3 3 1 C 2,00 2,00 0,14 3 1 C 2,00 2,00 0,16 2 1 B 2,00 2,00 0,01
g gr 3 6 2 D 1,56 1,99 27,91 7 2 D 1,51 1,99 31,89 3 1 C 1,96 2,00 2,06
p pl 5 3 1 C 3,78 4,00 5,59 3 1 C 3,75 3,99 6,39 2 1 B 3,98 4,00 0,41
p pr 5 1 160 A 1,04 1,04 0,00 1 160 A 0,94 0,94 0,00 5 2 D 3,29 3,93 19,53
p gl 5 2 1 B 3,99 4,00 0,29 2 1 B 3,99 4,00 0,33 2 1 B 4,00 4,00 0,02
p gr 5 7 7 D 2,49 3,79 51,98 14 9 D 2,37 3,73 57,68 3 1 C 3,82 3,98 4,12
g pl 5 4 1 C 3,79 4,00 5,59 4 1 C 3,76 4,00 6,39 3 1 C 3,98 4,00 0,41
g pr 5 1 500 A 1,05 1,05 0,00 1 500 A 0,95 0,95 0,00 5 1 C 3,31 3,99 20,48
g gl 5 3 1 C 3,99 4,00 0,28 3 1 C 3,99 4,00 0,32 2 1 B 4,00 4,00 0,02
g gr 5 8 7 D 2,55 3,93 54,40 11 8 D 2,42 3,92 61,81 3 1 C 3,84 4,00 4,11
p pl 9 3 1 C 7,17 7,96 11,07 4 1 C 7,06 7,95 12,64 2 1 B 7,93 7,99 0,81
p pr 9 1 80 A 1,18 1,18 0,00 1 80 A 1,05 1,05 0,00 6 4 D 5,51 7,46 35,42
p gl 9 2 1 B 7,95 7,99 0,57 2 1 B 7,94 7,99 0,65 2 1 B 8,00 8,00 0,04
p gr 9 1 80 A 3,53 3,53 0,00 1 80 A 3,26 3,26 0,00 3 2 D 7,28 7,86 7,98
g pl 9 4 1 C 7,19 7,99 11,14 4 1 C 7,09 7,99 12,73 3 1 C 7,93 8,00 0,82
g pr 9 1 250 A 1,20 1,20 0,00 1 250 A 1,07 1,07 0,00 7 2 D 5,65 7,94 40,47
g gl 9 3 1 C 7,95 8,00 0,56 3 1 C 7,95 8,00 0,64 2 1 B 8,00 8,00 0,04
g gr 9 1 250 A 3,71 3,71 0,00 1 250 A 3,44 3,44 0,00 4 1 C 7,37 7,98 8,18
p pl 17 4 1 C 12,92 15,70 21,56 4 1 C 12,56 15,64 24,55 2 1 B 15,70 15,95 1,60
p pr 17 1 40 A 1,24 1,24 0,00 1 40 A 1,09 1,09 0,00 3 23 D 8,13 9,83 20,94
p gl 17 2 1 B 15,78 15,96 1,12 2 1 B 15,75 15,95 1,28 2 1 B 15,98 16,00 0,08
p gr 17 1 40 A 4,24 4,24 0,00 1 40 A 3,82 3,82 0,00 3 3 D 13,08 14,97 14,39
g pl 17 5 1 C 13,03 15,91 22,11 5 1 C 12,70 15,90 25,25 3 1 C 15,74 15,99 1,63
g pr 17 1 125 A 1,29 1,29 0,00 1 125 A 1,14 1,14 0,00 9 9 D 8,70 14,87 70,89
g gl 17 3 1 C 15,81 15,99 1,11 3 1 C 15,78 15,99 1,27 2 1 B 15,99 16,00 0,08
g gr 17 1 125 A 4,72 4,72 0,00 1 125 A 4,29 4,29 0,00 4 2 D 13,61 15,78 15,99
Myrinet/MPI GigE/MPI IA-64 Cluster
I V P D d1 T SuC SuS %T D d1 T SuC SuS %T D d1 T SuC SuS %T
p pl 3 2 1 B 1,99 2,00 0,24 3 1 C 1,99 2,00 0,35 2 1 B 2,00 2,00 0,18
p pr 3 5 1 C 1,78 1,99 12,00 5 1 C 1,69 1,98 17,11 5 1 C 1,83 1,99 8,69
p gl 3 2 1 B 2,00 2,00 0,01 2 1 B 2,00 2,00 0,02 2 1 B 2,00 2,00 0,01
p gr 3 3 1 C 1,95 2,00 2,46 3 1 C 1,93 2,00 3,54 3 1 C 1,96 2,00 1,81
g pl 3 3 1 C 2,00 2,00 0,24 3 1 C 1,99 2,00 0,35 3 1 C 2,00 2,00 0,18
g pr 3 5 1 C 1,78 2,00 12,11 5 1 C 1,70 2,00 17,45 4 1 C 1,84 2,00 8,95
g gl 3 2 1 B 2,00 2,00 0,01 2 1 B 2,00 2,00 0,02 2 1 B 2,00 2,00 0,01
g gr 3 3 1 C 1,95 2,00 2,43 4 1 C 1,93 2,00 3,50 3 1 C 1,96 2,00 1,79
p pl 5 2 1 B 3,98 4,00 0,48 3 1 C 3,97 4,00 0,69 2 1 B 3,98 4,00 0,36
p pr 5 5 2 D 3,18 3,93 23,49 5 3 D 2,93 3,89 33,03 4 3 D 3,34 3,91 16,96
p gl 5 2 1 B 4,00 4,00 0,02 2 1 B 4,00 4,00 0,04 2 1 B 4,00 4,00 0,02
p gr 5 3 1 C 3,79 3,98 4,90 3 1 C 3,71 3,97 7,02 3 1 C 3,84 3,98 3,59
g pl 5 3 1 C 3,98 4,00 0,48 3 1 C 3,97 4,00 0,70 3 1 C 3,99 4,00 0,36
g pr 5 6 1 C 3,22 3,99 24,16 8 1 C 2,96 3,99 34,79 5 1 C 3,39 3,99 17,86
g gl 5 2 1 B 4,00 4,00 0,02 2 1 B 4,00 4,00 0,03 2 1 B 4,00 4,00 0,02
g gr 5 4 1 C 3,81 4,00 4,84 4 1 C 3,73 3,99 6,98 3 1 C 3,86 4,00 3,58
p pl 9 2 1 B 7,92 7,99 0,96 3 1 C 7,88 7,99 1,38 2 1 B 7,93 7,99 0,71
p pr 9 5 6 D 5,23 7,38 41,28 6 10 D 4,55 6,93 52,08 5 7 D 5,63 7,27 29,07
p gl 9 2 1 B 8,00 8,00 0,05 2 1 B 7,99 8,00 0,07 2 1 B 8,00 8,00 0,04
p gr 9 3 2 D 7,17 7,85 9,47 3 2 D 6,87 7,80 13,51 3 2 D 7,33 7,84 6,93
g pl 9 3 1 C 7,92 8,00 0,97 3 1 C 7,89 8,00 1,39 3 1 C 7,94 8,00 0,71
g pr 9 8 2 D 5,37 7,93 47,69 11 4 D 4,69 7,86 67,54 6 2 D 5,87 7,94 35,29
g gl 9 2 1 B 8,00 8,00 0,05 2 1 B 7,99 8,00 0,07 2 1 B 8,00 8,00 0,04
g gr 9 4 1 C 7,27 7,97 9,64 4 2 D 6,99 7,95 13,81 4 1 C 7,45 7,98 7,13
p pl 17 2 1 B 15,64 15,94 1,89 3 1 C 15,50 15,92 2,71 2 1 B 15,70 15,92 1,39
p pr 17 1 40 A 7,49 7,49 0,00 1 40 A 6,16 6,16 0,00 2 28 D 8,21 9,21 12,19
p gl 17 2 1 B 15,98 15,99 0,10 2 1 B 15,97 15,99 0,14 2 1 B 15,98 15,99 0,07
p gr 17 3 3 D 12,68 14,83 16,98 3 5 D 11,69 14,28 22,20 4 3 D 13,16 14,78 12,30
g pl 17 3 1 C 15,69 15,99 1,92 3 1 C 15,56 15,99 2,77 3 1 C 15,77 15,99 1,42
g pr 17 8 31 D 8,05 12,71 57,92 1 125 A 6,60 6,60 0,00 10 6 D 9,23 15,22 64,86
g gl 17 2 1 B 15,98 16,00 0,10 2 1 B 15,98 16,00 0,14 2 1 B 15,99 16,00 0,07
g gr 17 4 2 D 13,25 15,75 18,81 5 3 D 12,32 15,61 26,66 4 2 D 13,87 15,80 13,95
584 Aplicaciones
Evaluación de Clusters aplicados a imagen médica
Juan Díaz García, Pedro Prieto Gómez, Manuel Peña Taveras,
Rafael Ávila Bermúdez, Víctor Potenciano Enciso
Hospital Universitario Virgen de las Nieves, Granada.
e-mail: Juan.diaz.sspa@juntadeandalucia.es
Resumen
Pretendemos evaluar la potencialidad de los
diferentes tipos de clusters, bajo entorno de
Software Libre, aplicados a la gestión de procesos
tipo DICOM de gestión de las imágenes médicas;
en un entorno de alta disponibilidad y
escalabilidad con almacenamiento distribuido.
Buscando responder si soluciones en
Software Libre soportan nuevos retos y ámbitos
de aplicación, bajo las recomendaciones del
Parlamento de Andalucía de Diciembre de 2002,
así como la orientación de la Administración
Pública Sanitaria, aplicándose al desarrollo de un
entorno complejo de aplicaciones médicas en un
entorno real.
Queremos estudiar las prestaciones de un
Cluster de procesadores de bajo coste, las
funciones de alta disponibilidad, rendimiento de la
escalabilidad, buscando la mejor combinación
para definir el Servidor Virtual Linux que mejor
gestione las librerías DICOM para su
funcionamiento en Cluster, así como los
problemas de integración con los equipos Dicom
en las diversas modalidades de imágenes médicas,
poniendo a prueba las prestaciones de alta
disponibilidad como criterio fundamental para su
aplicación en entornos críticos.
1. Introducción
Los clusters, constituidos por estaciones de
trabajo de bajo coste o computadores personales
interconectados, aparecen cada vez más como una
alternativa muy común para configurar
plataformas de cómputo de altas prestaciones. En
entornos muy diversos, no solamente en los
dedicados a actividades científicas y de ingeniería,
sino también en empresas muy diversas, tanto del
ámbito industrial como del comercial, así como en
el ámbito sanitario, es posible encontrar
computadores conectados en red. Mediante este
tipo de arquitecturas paralelas es posible
configurar sistemas con unos niveles potenciales
de cómputo, disponibilidad, y escalabilidad,
próximos a los que proporcionan otras
arquitecturas de altas prestaciones más costosas,
contribuyendo por tanto a aumentar la incidencia
y el interés en el procesamiento paralelo en un
entorno socio-económico más amplio.
La idea de utilizar computadores
interconectados como una forma económica de
disponer de paralelismo se remonta a los años 60
con los sistemas HASP y JES de IBM . Mediante
este tipo de plataformas se puede disfrutar de las
ventajas propias de un sistema paralelo y
distribuido en cuanto a:
Prestaciones. El trabajo cooperativo de varios
procesadores permite mejorar las prestaciones de
uno sólo (se midan como tiempo de respuesta,
tareas por unidad de tiempo, etc.).
Disponibilidad. Es posible distribuir el trabajo
entre los procesadores de manera que se
sustituyan los procesadores defectuosos.
Mejora gradual. Se puede ampliar la
capacidad del cluster sustituyendo el hardware de
los nodos, o de la red por otro más reciente, con
mejores características.
Escalabilidad. Es posible mejorar las
prestaciones incrementando el número de nodos
de la máquina. La escalabilidad es mayor a
medida que el incremento de prestaciones
mantiene la proporción con el incremento de
recursos.
Precio/prestaciones. Al configurarse a partir
de elementos disponibles comercialmente con
relaciones precio/prestaciones individuales muy
buenas, cabe esperar también unas relaciones
precio/prestaciones bajas en el sistema completo.
No obstante, el aumento de la importancia de
los clusters de computadores como entorno de
computación paralela se está alcanzando, por una
parte, gracias a tres razones tecnológicas como
son la amplia disponibilidad de microprocesadores
de prestaciones elevadas, redes de conexión de
alta velocidad, y herramientas y bibliotecas
estándar para la computación paralela:
Los microprocesadores de altas prestaciones.
A pesar de que se han planteado algunas
cuestiones respecto a la validez de la ley de
Moore, el ritmo de mejora de la tecnología de
semiconductores va a seguir traduciéndose en
aumento de la capacidad de los
microprocesadores, que continuarán alcanzando
los niveles de prestaciones ofrecidos por
computadores de altas prestaciones. Precisamente,
este ritmo de incremento de prestaciones de los
microprocesadores está haciendo que,
prácticamente, no existan computadores de altas
prestaciones que no sean un agregado de
microprocesadores, y que más que hablar de
supercomputadores haya que hablar de
supercomputación.
Las redes de comunicación estándar de alta
velocidad. Desde comienzos de los 90, a partir del
uso comercial de la fibra óptica, y gracias a la
convergencia entre las redes de área local y los
sistemas de interconexión utilizados en los
procesadores masivamente paralelos, las
tecnologías de comunicación están avanzando
rápidamente hacia la configuración de redes a
partir de elementos estandarizados y disponibles
comercialmente (COTS, Common Off-The Shelf).
Así, se han introducido redes como Fast y Gigabit
Ethernet, ATM (Asynchronous Transmission
Mode), Myrinet, SCI (Scalable Coherent
Interface), Infiniband, etc., que han permitido
pasar desde los 10 Mbits/s a los cientos de
Mbytes/s y a los Gbytes/s.
Las herramientas estándar para la
computación distribuida y paralela. Las
necesidades que plantean las aplicaciones
distribuidas y las paralelas han hecho que estén
disponibles una serie de herramientas para la
gestión de los clusters y para el desarrollo de
programas paralelos que, como en el caso de MPI,
o PVM se han convertido en estándares de facto.
Por otra parte, hay una razón para el interés en
los clusters que proviene del incremento
importante en el mercado de aplicaciones que
necesitan prestaciones de cómputo y
disponibilidad elevadas. Existen muchas
aplicaciones que se basan en el uso de servidores,
cuya fiabilidad es esencial para proporcionar un
servicio constante. Como ejemplos se pueden citar
los servidores que proporcionan información de
cotizaciones, cuentas bancarias, control de
inventarios, comercio electrónico, etc. En la
mayoría de los casos, se trata de aplicaciones que
han surgido al amparo de Internet y en las que la
globalización que Internet permite obliga a
mantener un servicio ininterrumpido.
Precisamente cuando la proliferación de PCs ha
ocasionado una descentralización de la capacidad
de cómputo, y acceder a un equipo con una
potencia de cálculo nada despreciable es
relativamente sencillo, es cuando la importancia
de los servidores crece dado que la utilidad de un
PC aumenta por la posibilidad de acceder a
información y servicios, intercambiar con otros
usuarios correo, ficheros, etc. En este sentido, los
clusters parecen constituir la mejor solución para
configurar servidores con disponibilidad elevada a
bajos precios, dado que utilizan hardware
estándar, a diferencia de otros sistemas tolerantes
a fallos previos.
2. El Entorno Sanitario
Un cluster orientado a aplicaciones sanitarias
requiere una serie de condiciones muy
importantes que afectan a su configuración:
Alta disponibilidad. El sistema debe garantizar
un funcionamiento permanente (24/7) ofreciendo
un servicio ininterrumpido. Esto implica disponer
de elementos vitales redundantes, sistemas de
verificación de funcionamiento correcto,
posibilidad de modificación/ampliación del
sistema manteniendo los servicios activos.
Fácil administración. Mediante herramientas
que detecten los cambios del sistema, la
modificación del número de nodos disponibles u
ofrecer una imagen única del sistema.
Correcta gestión de copias de seguridad de
datos. Debido a los volúmenes de datos que se
pueden manejar, resulta vital garantizar copias de
los mismos.
Escalabilidad heterogénea. Aprovechar
recursos e ir incorporando elementos más
modernos con mayor capacidad de forma
progresiva al sistema global.
586 Aplicaciones
Redes de alta velocidad. Tanto entre los
nodos internos como para ofrecer intercambio
rápidos de información con los clientes.
Así pues, parece ser una buena
alternativa a las plataformas de supercomputación
tradicionales, de propósito más bien específico y
características dependientes ('propietary') del
fabricante, orientarse hacia estos sistemas
constituidos por varios PCs o estaciones de trabajo
(monoprocesadores o SMPs), más baratos y
eficientes en diferentes aplicaciones. Existen
bastantes pruebas del interés suscitado por los
clusters. Por una parte, hay una clara proliferación
de este tipo de plataformas no sólo en
Universidades y Centros de Investigación, sino
además en el ámbito de aplicaciones eficientes.
Por otra parte, asociaciones como la prestigiosa
IEEE tienen un grupo de trabajo dedicado
específicamente a la computación en clusters
('Task Force on Cluster Computing') en cuya
página Web (http://www.dgs.monash.edu.au/
~rajkumar/tfcc/) se puede encontrar información
acerca de diversos proyectos y congresos
relacionados con el tema y una revisión de los
tópicos que abarca el estudio de los clusters de
computadores. Para dar una idea de la actualidad
de este tema, basta considerar que, desde 1999, se
celebra un congreso de IEEE específico sobre
'Cluster Computing', y se vienen celebrando del
orden de siete congresos anuales relacionados con
dicho campo.
Uno de los principales atractivos de los
clusters es que se construyen a partir de elementos
hardware estándar (procesadores, memorias,
tarjetas de red, etc.) de bajo precio, redes de altas
prestaciones (Fast y Gigabit Ethernet, ATM,
Myrinet, Infiniband, etc.), y componentes
software estándares tales como los sistemas
operativos UNIX, LINUX, etc. Junto a estos
elementos que se pueden considerar básicos, hay
otros elementos que también debieran estar
presentes en un cluster. Uno de estos servicios
adicionales está constituido por una
infraestructura que permita alta disponibilidad del
sistema y proporcione una imagen del sistema
como un todo (Single System Image, SSI). Se
trata de una capa intermedia (middleware), con
elementos hardware (para la memoria distribuida
compartida, DSM, y para diversas técnicas
propias de los SMPs), software (capa de
pegamento o parte del núcleo del SO), y de
aplicaciones (sistemas de ejecución, 'run-time
systems', software de planificación y gestión,
etc.). También es conveniente disponer de
entornos y herramientas de programación, y de
aplicaciones tanto secuenciales como paralelas y
distribuidas.
Como se ha indicado, el uso de clusters
permite utilizar varias CPUs para el
procesamiento paralelo. Sin embargo, siguen
existiendo cuestiones abiertas, entre las que la
mejora del software y el hardware para conseguir
una comunicación más eficiente tiene un interés
especial.
Actualmente el “HOSPITAL
UNIVERSITARIO VIRGEN DE LAS NIEVES ”
posee un sistema de gestión radiológico (RIS) y
una serie de dispositivos radiológicos (TAC,
RMN, Telemandos Digitales, etc) que cumple la
normativa internacional “DICOM” (Digital
Imaging and Communications in Medicine) de
intercambio de imágenes médicas.
El sistema RIS se encuentra distribuido en
todos los centros que componen dicho hospital,
siendo estos el Hospital de Medico - Quirúrgico,
Hospital Materno Infantil y Hospital de
Traumatología. Dichos centros se encuentra
enlazados mediante una red de fibra óptica, que
permite una red de tipo WAN, con segmentos
específicos para el área radiológica.
El Sistema de Información Radiológico (RIS)
posee un complejo sistemas de información que
cubre las áreas Asistencial y Administrativa
dentro del Departamento de Radiología, integrado
con el Sistema de Información Hospitalario (HIS)
de todo el hospital, facilitando el flujo entre los
sistemas.
Mediante DICOM se define la semántica y
sintaxis de las Imágenes Digitales, mensajes de
intercambio y los requerimientos de conformidad
para su implementación. Permitiendo el
intercambio de Imágenes Medicas y datos
asociados, creando un entorno abierto entre
proveedores y facilitando la interoperabilidad.
La normativa DICOM establece la necesidad
de integración del sistema RIS/HIS y los
XVI Jornadas de Paralelismo, JP '2005 587
dispositivos radiológicos y otras fuentes de
imágenes para asegurar una información
coherente, un funcionamiento correcto y la
explotación de las nuevas prestaciones de los
equipos.
El sistema de gestión de la información RIS-
PACS es imprescindible para el buen
funcionamiento de un Servicio de Radiología y su
integración posterior en la historia clínica
electrónica. Los profesionales de la sanidad no
dudan de la necesidad de acceder a la información
clínica y de imagen de una forma rápida y
eficiente para mejorar el trabajo de los radiólogos
y de todos aquellos médicos que lo necesiten.
3. Objetivos
Evaluar las prestaciones de un Cluster de
procesadores de bajo coste para sistemas de alto
rendimiento.
Evaluar las funciones de alta disponibilidad en
modo Servidor Virtual Linux, según la
arquitectura más eficiente para evitar puntos
únicos de fallo.
Crear los test de carga para medir la
escalabilidad del sistema y balanceo de carga.
Evaluar el comportamiento de las Librerías
DICOM para su funcionamiento en Cluster.
Evaluar los problemas de integración con los
equipos Dicom del centro en cada modalidad.
4. Desarrollo
En este proyecto evaluamos diferentes
aspectos desde un sistema real, limitado solo por
ser un proyecto de investigación con financiación
limitada, que condiciona los recursos disponibles
para su construcción y prestaciones.
Dichas limitaciones no afectan al desarrollo
del Cluster y funcionalidad que se quiere evaluar,
solo afectaría al rendimiento y capacidad de
almacenamiento y por tanto a cuantos equipos
Dicom se pueden integrar y el límite de imágenes
a almacenar.
Figura 1. Modelo de funcionamiento
Evaluaremos un modelo complejo de alta
disponibilidad de los servidores, en un Sistema
operativo LINUX, para desarrollar un Cluster de
varios equipos que permite el funcionamiento
ininterrumpido y escalable.
Integrándolo con las diferentes modalidades
más importantes del hospital, como son TAC,
RMN, CR, M. Nuclear. Que sirven para evaluar la
integración DICOM en varios entornos.
Así como la integración del Dicom - Ris desde
la planificación de exploraciones - Worklist -
hasta la integración de las imágenes.
Dada la complejidad de las tareas todos los
elementos del proyecto deben de colaborar en las
siguientes fases, para asegurar una integración de
óptima.
• Desarrollo del Cluster con la configuración
que asegure la alta disponibilidad, la escalabilidad
y con un sistemas de comunicaciones de altas
prestaciones.
• Desarrollo del Sistema de ficheros que soporte
las librerías Dicom en modo distribuido.
• Implantación de las librerias Dicom.
-Implantación de los servicios Dicom soportados
por cada uno de los equipos, Estandarización de
codificaciones, almacenamiento, identificadores,
etc.
-Modificación y adecuación de funciones para
soporta los servicios no estándar.
-Adaptación flujos de trabajo y procesos de los
equipos para adaptarse a las nuevas
funcionalidades.
588 Aplicaciones
-Integración con el Historia Clínica Electrónica y
el Sistema de Información Radiológico del
Hospital.
Soporte de Integración de los Servicios
DICOM: Implementación del Servicio Basic
Worklist Management - Dicom. Implementación
del Servicio Patient Management -
Dicom.Implementación del Servicio Study
Management - Dicom. Implementación del
Servicio Verification - Dicom. Implementación
del Servicio Storage Media. Implementación del
Servicio Query/Retrieve.
• Integración equipos Dicom - PACS .
-Elección de Modalidades y equipos pilotos.
-Verificación de los Documentos
"Conformance Statement".
-Validación de Objetos, Clases y Servicios.
-Validación UIDs.
-Test de Verificación - Dicom Association.
5. Conclusiones
Nos encontramos actualmente en la fase de
evaluación y monitorización de los diferentes
parámetros definidos por nuestros objetivos, entre
ellos la evaluación de la arquitectura y
disponibilidad hasta con un 50% de fallos de los
recursos y componentes del sistema, simulando
los comportamientos de respuestas y
funcionamiento en condiciones de
funcionamientos y recuperación de fallos. La
valoración de la gestión de peticiones y reparto de
carga entre nodos, los rendimientos de los
sistemas de ficheros virtuales, y el
comportamiento de la escalabilidad, etc.
Así como la evaluación de las funcionalidades
DICOM, y sus rendimientos para validar el
entorno con equipos y procesos reales.
Los primeros resultados del diseño de
topología y arquitectura se orientan a modelos tipo
SSI (Single System Image) siendo el que tiene una
mejor potencialidad y simplicidad, no tenemos la
necesidad de descomponer las peticiones de
proceso, ya que el entorno de trabajo genera un
gran número de peticiones concurrentes y
homogéneas.
Como interfaz del sistema con el resto de
equipos de imagen Dicom, se plantea un modelo
de Servidor Virtual, que responde como única IP
para todo el conjunto del Cluster, utilizando el
balanceo por enrutamiento directo para la gestión
de las peticiones, otras alternativas como
traslación de direcciones o encapsulado mediante
tunneling, no se han mostrado suficientemente
eficientes.
Estamos estudiando los mecanismos de
planificación de balanceo de carga, en el marco de
las funciones Dicom, teniendo en cuenta no solo
el orden de llegada de las peticiones, procesos
activos por nodos, nodos con menos conexiones
activas, sino las cargas generadas por el tamaño de
los objetos Dicom devueltos, con una variabilidad
de cientos de bytes a cientos de Megabytes.
Otro elemento importante es la gestión del
sistema de ficheros soportados por el cluster,
buscando un modelo distribuido, de alto
rendimiento, escalabilidad, seguridad y tolerante a
fallos.
Siendo todos estos elementos los que
conforman las características que garantizan la
mayor disponibilidad posible, criterio de máximo
interés en el ámbito sanitario. Asegurando no
tener puntos únicos de fallos y minimizando los
efectos en el rendimiento y escalabilidad del
sistema.
Referencias
[1] A. Geissbuhler, C. Lovis, A. Lamb, S.
pahni, Experience with an XML/http-
based ederative approach to develop a
hospital-wide clinical information
system, Medinfo 2001, IOS Press,
Amsterdam, 2001.
[2] B. Revet, DICOM Cookbook for
implementations in modalities, technical
report Philips medical systems, 1997.
[3] D. McG. Squire, H. Müller, W. Müller, S.
Marchand-Maillet and T. Pun, Design and
evaluation of a content-based image retrieval
system, Chapter 7, Design and Management
of Multimedia Information Systems:
Opportunities and Challenges, Idea Group
XVI Jornadas de Paralelismo, JP '2005 589
Publishing, S. M. Rahman, editor, pp. 125-
151, 2001.
[4] F. Gagliardi, B. Jones, M. Reale, S. Burke,
European Datagrid project: Experiences of
deploying a large scale testbed for e-science
applications, Performance 2002, pp. 480-
500, 2002.
[5] Gregory Pfister. In Search of Clusters.
Prentice-Hall, 2 Ed., 1998.
[6] H. Müller, W. Müller, DMcG. Squire, Z
Pecenovic, S. Marchand-Maillet and T. Pun,
An Open Framework for Distributed
Multimedia Retrieval, Computer Assisted
Information Retrieval (RIAO), volume 1,
pp.701-712, Paris, 2000.
[7] High Performance Cluster Computing:
Architectures and Systems, Vol 1 Rajkumar
Buyya (editor), ISBN 0-13-013784-7, Prentice
Hall PTR, NJ, USA, 1999.
[8] I. Foster, C. Kesselman, Steven Tuecke, The
Anatomy of the Grid – Enabling scalable
virtual organisations, International Journal
onSupercomputer Applications, 2001.
[9] Liu BJ, Huang HK, Cao F, Zhou MZ, Zhang J,
Mogel G. Informatics in radiology (infoRAD):
A complete continuous-availability PACS
archive server. Radiographics. Jul-
Aug;24(4):1203-9, 2004.
[10] P. Ruch, R. Baud, A. Geissbuhler, Evaluating
and reducing the effect of data corruption
when applying bag of words approaches to
medical records, International Journal
ofMedical Informatics 67, pp. 75-83, 2002.
[11] Platero, C., Versbiet, K., Úbeda, A.,
Trillo,A., Gosalvez, J., Bartolomé, J., XXI
Jornadas de Automática, ISBN: 84-699-3163-
6, Sevilla, septiembre 2000.
[12] Wendt, G., Peppler, W., Challenges and
Limitations of Clinical Image Distribution in
an Enterprise Wide PACS Environment – A
Two Year Evaluation of Multiple Approaches
at the University of Wisconsin, Journal of
Digital Imaging,, Supplement to Volume 16,
2003.
[13] Wendt, G., Peppler, W., Edwards, W., PACS
Disaster Recovery Procedures - Evaluation in
a Clinical Environment, Journal of Digital
Imaging,, 112-113, Vol. 15, Suppl 1, 2002.
[14] Varios autores: “Cluster Computing White
Paper”. IEEE Task Force on Cluster
computing, Diciembre 2000.
590 Aplicaciones
Paralelización del codificador H.264 con estimación de
movimiento adaptativa en clusters de PCs1
A. Rodríguez*
, M. Pérez*
, A. González*
, J. Peinado*
, J.C. Fernández+
*
Universidad Politecnica de Valencia, Dept. de Informática de Sistemas y Computadores
+
Universidad Jaume I, Dpt. d'Enginyeria i Ciència dels Computadors
1
Este trabajo ha sido financiado por el proyecto de la
Generalitat Valenciana GV04B-507
Resumen
La codificación de vídeo es de primordial
importancia para la mayoría de aplicaciones
multimedia, en especial las que manejan flujos de
vídeo de alta calidad. El más reciente de los
estándares de codificación de vídeo es el H.264
AVC, el cual ha incorporado novedosas mejoras
que lo hacen especialmente eficiente para un
rango amplio de aplicaciones. En particular, el
H.264 AVC utiliza el esquema clásico basado en
tratamiento de la señal y la codificación de
residuos con compensación de movimiento. La
novedad es el incremento de complejidad de los
bloques operativos y por tanto el incremento
considerable de computación. La utilización de
clusters tiene como objetivo la reducción del
tiempo de codificación con niveles de latencia que
permitan a aplicaciones como la videoconferencia
o la difusión de vídeo codificado trabajar con
formatos de alta resolución y tasa de cuadros
(HDTV, D-Cinema, ec.). En el presente trabajo se
presenta un estudio sobre la paralelización del
codificador H.264, proponiendo un mecanismo
para realizar la estimación de movimiento de
forma adaptativa que aplique toda la potencia de
estimación del codificador sólo cuando sea
realmente necesario.
1. Introducción
Actualmente hay múltiples aplicaciones en las que
la codificación de vídeo es necesaria, algunos
ejemplos son los teléfonos móviles de última
generación, la difusión de vídeo en Internet y la
televisión de alta definición. La información de
vídeo se caracteriza por requerir grandes
cantidades de bits con los consiguientes
requerimientos de ancho de banda y de espacio
para su transmisión y almacenamiento. Los
codificadores de vídeo reducen drásticamente
estos requerimientos introduciendo una cierta
perdida de calidad en la señal de vídeo
reconstruida. Aplicando las técnicas de
compresión de forma adecuada dicha perdida
puede controlarse de forma que sea aceptable en
el contexto de la aplicación.
Los primeros codificadores de vídeo como
MPEG [1][2] se basaron en las técnicas digitales
de procesamiento de la señal (transformación,
cuantificación y codificación de entropía).
Actualmente, codificadores como MPEG-4 [9]
utilizan otras técnicas más novedosas de
segmentación y codificación de objetos.
El codificador H.264 AVC [3] (MPEG-4 parte
10) sigue el modelo clásico pero llevando al límite
la sofisticación de cada uno de los elementos. Esto
se traduce en una mayor efectividad en la
compresión, o sea mayores tasas de compresión, y
menor error perceptual, pero con unas exigencias
de computación mucho mayores.
Con respecto a esto último, se sabe que una de
las etapas más costosas del codificador H.264 es
la estimación de movimiento que se lleva a cabo
para cada uno de los cuadros de vídeo que se
codifican como INTER (más de un 90% de los
cuadros de una secuencia de vídeo). En la
configuración del codificador H.264 se puede
determinar el nivel de precisión con el que se
quiere buscar el movimiento resultante en un
cuadro. Por ello, pensamos que en determinadas
situaciones no es necesario emplear demasiados
ciclos de CPU para codificar el movimiento de
una forma tan precisa, asumiendo la posible
pérdida de calidad y eficiencia. Por todo ello,
planteamos un esquema de estimación de
movimiento adaptativa a nivel de grupo de
cuadros (GOP) en donde se busca un compromiso
entre la perdida de rendimiento del codificador y
la reducción del tiempo de codificación.
Por otro lado, la posibilidad de disponer de
entornos de alta productividad y la codificación en
tiempo real en los contextos de aplicación más
exigentes como la televisión de alta definición,
obliga a utilizar plataformas con gran potencia de
cálculo. Una alternativa posible son los clusters
que ofrecen prestaciones escalables a bajo coste y
con una gran flexibilidad.
El objetivo del presente trabajo es conseguir
implementaciones del codificador H.264 AVC
sobre clusters que sean escalables y eficientes, de
forma que se puedan encontrar configuraciones de
cluster adecuadas para las exigencias de las
aplicaciones de codificación de vídeo más
extremas.
La organización del presente trabajo es la
siguiente: En la sección 2 planteamos el
mecanismo de estimación de movimiento
adaptativa, justificando su interés. En la sección 3,
se presentan los esquemas de paralelización a
nivel de GOPs. En la sección 4, mostramos
algunos resultados de rendimiento de las versiones
propuestas y, finalmente, en la sección 5
exponemos las conclusiones del trabajo y
planteamos algunas acciones que se pretenden
llevar cabo en esta línea.
2. Estimación de movimiento adaptativa
Con el objeto de reducir el coste computacional de
la estimación de movimiento del codificador
H.264 AVC, se propone realizar la estimación de
movimiento de forma adaptativa en base a una
función de coste discreta que maximice la relación
entre el rendimiento del codificador (calidad y
tasa de bits) y el tiempo de codificación. Esta
función de coste deberá determinar que nivel de
precisión tiene que emplear el codificador para
identificar el movimiento en el GOP actual.
A priori, el codificador H.264 permite definir
la precisión del mecanismo de estimación de
movimiento a través de un conjunto de parámetros
de configuración. Ajustando el valor de dichos
parámetros podemos definir varios niveles de
precisión. En particular, y para este trabajo, hemos
definido tres niveles diferentes. El primero define
la máxima precisión posible (opción por defecto
del codificador, le llamamos E0), el segundo nivel
ofrece una precisión intermedia usando una
búsqueda con tamaños de bloque de 16x16, 16x8,
8x16 y 8x8 (le llamamos E1), mientras que el
tercer nivel sólo utiliza el tamaño de bloque de
16x16 (le llamamos E2).
Foreman_Cif
0
1
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Figura 1. Selección adaptativa de los niveles de
estimación de movimiento (E0,E1 y E2).
En la figura 1, podemos observar el nivel de
precisión seleccionado para cada GOP en las
secuencias Foreman (CIF@30fps) y Stockholm
(HDTV@30fps). Esto se ha realizado de forma
manual simulando una función de coste de tres
niveles para cada GOP (a este esquema lo
llamamos EA). Lo anterior da como resultado
importantes reducciones del coste temporal del
algoritmo, con respecto a la codificación estándar
con estimación de movimiento exhaustiva (E0).
Con el objeto de observar cuanto tiempo de
cómputo puede recortar la estimación de
movimiento adaptativa, realizamos un
experimento codificando las dos secuencias de
vídeo mencionadas anteriormente, con la versión
secuencial JM 7.6 [11] del codec H.264 AVC.
En la figura 2, se muestra la reducción del
coste temporal de los GOPs codificados con los
niveles de estimación definidos: E1, E2 y EA. La
función de coste de EA busca reducir al mínimo
el tiempo de codificación, manteniendo al máximo
la calidad, sin incrementar demasiado el tamaño
Stockholm1280x720
0
1
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
592 Aplicaciones
del bitstream, como se puede observar en las
figuras 3 y 4.
En el esquema adaptativo (EA) la pérdida de
calidad provocada corresponde a centésimas de
decibelio. Esta pérdida de calidad la podemos
considerar despreciable, siendo este un factor
prioritario a la hora de codificar video de alta
calidad.
Figura 2. Porcentaje de reducción del tiempo de
codificación respecto de E0.
Figura 3. Porcentaje de reducción del PSNR
Figura 4. Porcentaje de incremento del bitrate respecto
de E0.
En cuanto al tamaño del bitstream generado,
se observa un incremento medio que ronda el 3%
para la estimación de movimiento adaptativa
(EA). Este incremento de tamaño es menos
apreciable en secuencias de alta resolución
(secuencia Stockholm), siendo este el precio que
asumimos como contrapartida cuando empleamos
estimación de movimiento adaptativa.
Por tanto, podemos decir que utilizar un
esquema de estimación de movimiento adaptativo
es más que interesante ya que la calidad
perceptual del video decodificado no se ve
alterada, mientras que incrementamos ligeramente
el tamaño del bistream. Este incremento del
bitrate no será determinante para un gran abanico
de aplicaciones (difusión de TV digital en
formatos HDTV, videoconferencia de alta calidad,
etc.), en las que el retardo del codificador es un
parámetro crítico y se debe mantener la calidad de
la señal al máximo.
3. Esquemas de paralelización
En la literatura se pueden encontrar múltiples
versiones paralelas de codificadores de video,
particularmente MPEG-1[2][5][8] y MPEG-2
[1][6]. Las implementaciones paralelas del
codificador H.264 que presentamos se han basado
en el código JM 7.6 disponible de forma libre [11]
utilizando MPI [7].
Figura 5. Esquema de distribución por GOPs y
tipos de mensajes
…
Encod
Encod Encod
Distrib
Gop# o -1
Nodo 0
Nodo 1 Nodo N
nGop?, -2 o Pred
0
5
10
15
20
25
30
ForemanCif StockHolm1280
%
E1 E2 E-A
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
ForemanCif StockHolm1280
%
E1 E2 E-A
0
2
4
6
8
10
ForemanCif StockHolm1280
%
E1 E2 E-A
XVI Jornadas de Paralelismo, JP '2005 593
El paralelismo se consigue descomponiendo la
secuencia de vídeo en bloques de 15 cuadros
consecutivos (GOPs), de forma que cada bloque
sigue un patrón de codificación del tipo
IBBPBBP…PBBI [10]. La codificación de cada
GOP es una tarea totalmente independiente, por lo
que los nodos no requieren comunicación alguna
con los demás para codificar su GOP.
El video a codificar se encuentra en un
sistema de ficheros compartido, al que todos los
nodos pueden acceder para leer los GOPs. De la
misma forma, el bistream resultante de codificar
cada GOP es almacenado en ficheros
adecuadamente identificados para el ensamblado
final en un único bitstream. Este proceso se realiza
cuando el último nodo ha terminado de codificar
su GOP.
En la figura 5 se muestra un diagrama que
ilustra el funcionamiento del codificador paralelo
con descomposición de datos a nivel de GOP. En
la parte superior se encuentra el proceso 0 que
inicia el lanzamiento del programa y
posteriormente ejecuta dos subprocesos:
distribuidor (Distrib) y codificador (Encod).
Los mensajes que intercambia el proceso
distribuidor con los procesos de codificación son
los siguientes:
x n_Gop?: Terminación del proceso de
codificación del GOP actual y solicitud de un
nuevo GOP.
x Gop#: Indica el numero de GOP a codificar.
x -1: No hay más GOPs a codificar.
x Pred: Corresponde con el informe de
predicción del tiempo estimado para finalizar
el GOP en curso del proceso codificador. Este
valor solo es usado por el esquema de
distribución por estimación de coste.
x -2: Confirma la terminación de la codificación
en un determinado nodo. Este mensaje es
necesario porque al final se tienen que integrar
todos los GOPs codificados en un solo fichero
de salida.
Experimentalmente hemos observado que el
tiempo de codificación de los GOPs tiene una
variación muy pequeña, de forma que las
características de la secuencia de vídeo no parecen
condicionar mucho el tiempo de codificación.
Esto es así en el codificador original, lógicamente
se pueden aplicar optimizaciones que hagan que la
cantidad de cómputo, en particular en la
estimación y compensación de movimiento, se
adapte a las características de la secuencia en cada
GOP (nivel de detalle, contornos, cantidad de
movimiento, etc).
La escasa variación del tiempo de codificación
a nivel de GOP sugiere que no será complicado
obtener algoritmos paralelos con buen equilibrio
de la carga, que utilicen la codificación de un
GOP como tarea básica.
Sin embargo, al utilizar el mecanismo de
estimación de movimiento adaptativa, se
introduce un desbalanceo en la carga del
codificador, haciendo que existan diferencias de
coste computacional significativas entre los GOPs
de una secuencia de vídeo. En este caso, el
esquema de asignación de GOPs a procesadores
puede jugar un papel importante en cuanto al
rendimiento del codificador paralelo se refiere.
Para poder estudiar este fenómeno,
proponemos utilizar dos esquemas de asignación
de GOPs: asignación por demanda y asignación
por estimación de coste.
3.1 Asignación por demanda.
Este esquema asigna de forma consecutiva un
GOP a cada nodo en la primera ronda de
asignación. Cuando un nodo finaliza la
codificación del GOP actual, lo indica al proceso
distribuidor solicitando la asignación de un nuevo
GOP (ver figura 5). El proceso distribuidor
atiende la petición del nodo asignándole el primer
GOP pendiente de codificar. Este proceso
continúa hasta que no quedan más GOPs, en cuyo
caso el proceso distribuidor notifica esta situación
a los nodos para que finalicen la ejecución.
La asignación por demanda va procesando los
GOPs en el orden de aparición en el bistream a
codificar. A continuación se muestra el algoritmo
del proceso distribuidor para la asignación por
demanda:
x Asigna a los procesadores su primer GOP
x Repetir hasta fin de secuencia
o Espera mensaje n_Gop?
o Envía Gop# del siguiente GOP al
procesador
x Para cada procesador
o Espera mensaje n_Gop?
o Envía -1 al procesador
x Ensambla los GOPs codificados en un
fichero único
594 Aplicaciones
3.2 Asignación por estimación de coste.
Cuando utilizamos la asignación por estimación
de coste se trata de asignar GOPs de forma que se
tenga en cuenta el balanceo de carga que el
sistema lleva hasta el momento. Además se tendrá
en cuenta la correlación del coste temporal en los
frames/GOPs consecutivos.
Para ello se propone cubrir diferentes zonas de
la secuencia de vídeo. Así, la asignación inicial de
GOPs a procesadores estaría distribuida a lo largo
de toda la secuencia.
0 1 2 3 4 5 6 7 8 9 10 11
P0,1 P1,1 P3,1
P2,1
Supongamos una secuencia de 12 GOPs para
cuatro nodos. Al nodo 0 se le asigna el primer
GOP, al nodo 1 el GOP #3 y así sucesivamente.
El proceso distribuidor deberá recoger
informes de previsión de coste de los GOPs que se
están codificando en todos los nodos, con el
objeto de hacer una planificación que intente
mejorar dinámicamente el balanceo de carga de
todos los procesadores.
Cuando los nodos, en la codificación del GOP
asignado, disponen de una buena predicción2
,
envían al proceso distribuidor un informe de
estimación de coste, indicando cuanto tiempo les
falta para terminar de codificar el GOP en curso.
El proceso distribuidor recoge los informes de
los nodos antes de que finalice el GOP más ligero
y realiza una planificación de asignación, de
forma que el GOP previsiblemente más pesado (el
vecino del GOP más pesado de los que se están
procesando actualmente) se asigne al nodo que ha
procesado el GOP mas ligero y viceversa.
Siguiendo esta política, tratamos de distribuir
los GOPs entre los procesadores, en función de las
previsiones de coste de los que se están
codificando actualmente, suponiendo que si un
GOP es ligero el vecino también lo será. A
continuación se muestra el pseudo-código de este
mecanismo para el proceso distribuidor:
x Asigna a cada procesador su primer GOP
(ver sección 3.2)
x Calcula el número de ciclos de asignación
de GOPs (Nciclos)
2
Experimentalmente se han obtenido buenas
estimaciones cuando se ha procesado el 80% del GOP.
x Para cada ciclo C = 1..Nciclos-1
o Para cada procesador P = 0..Nproc-1
o Espera mensaje Pred (predicción de P)
o Si es la primera predicción recibida
lanza timer (tout = prediccion)
o Si no Si predicción < tout relanza el
timer (tout = prediccion)
o Si el timer no ha vencido
o Detener el timer
o Lanzar planificación (ver sección 3.2)
x Para cada procesador P
o Espera mensaje Pred (el último)
o Envía -1 (no hay mas GOPs)
o Espera -2 (fin de proceso de P)
x Ensamblar GOPs codificados en fichero
único
El pseudo-código del manejador del timer es
el siguiente:
x Lanza planificación (ver sección 3.2)
x Para cada procesador P = 0..Nproc-1
o Envía mensaje Gop# con el ID de GOP
asignado
4. Resultados obtenidos
La evaluación de los algoritmos propuestos se ha
realizado sobre dos secuencias de vídeo: Foreman
(CIF) y Stockholm (HDTV). Los experimentos se
han realizado sobre un cluster compuesto por
cuatro nodos biprocesadores con Opteron 246 a
2GHz, con 1 GByte de memoria por nodo,
interconectados por una red Gigabit Ethernet con
agregación de dos enlaces por nodo y un switch
3Com. El sistema operativo es Linux SuSE 9.1 y
el entorno MPI es MPICH-2. Los codificadores
paralelos se basan en dos esquemas de asignación
de GOPs y en dos esquemas de estimación de
movimiento:
x Esquemas de asignación de GOPs:
x Asignación por demanda.
x Asignación por estimación de coste.
x Esquemas de estimación de movimiento:
x Estimación exhaustiva
x Estimación adaptativa
Los tiempos de referencia son los obtenidos
por el codificador con asignación por demanda y
estimación de movimiento exhaustiva. Las figuras
6 y 7 muestran el porcentaje de reducción del
tiempo de codificación de los codificadores
paralelos con estimación de movimiento
adaptativa, en el caso de asignación de GOPs por
demanda y por estimación de coste, sobre 24
GOPs de las dos secuencias de vídeo
mencionadas.
XVI Jornadas de Paralelismo, JP '2005 595
1
2
3
4
5
6
7
8
9
10
11
2 proc 4 proc 8 proc
%
relativo
Estimación de coste Demanda
Figura 6. Reducción del tiempo de ejecución para
la secuencia Stockholm
1
3
5
7
9
11
13
2 proc 4 proc 8 proc
%
relativo
Estimación de coste Demanda
Figura 7. Reducción del tiempo de ejecución para
la secuencia Foreman
Los resultados obtenidos muestran como los
codificadores H264 paralelos, con estimación de
movimiento adaptativa, reducen el tiempo de
codificación. En el caso de la asignación de GOPs
por estimación de coste las mejoras están entorno
a un 10%, siempre por encima de la asignación
por demanda cuando se tienen menos de 8 GOPs
por procesador.
Los speedups para los codificadores paralelos
basados en estimación de movimiento adaptativa
se muestran en las figuras 8 y 9. Se observa una
mejora para el caso de la asignación de GOPs por
estimación de coste, tal y como se esperaba.
Aunque la magnitud de la mejora, en las
secuencias consideradas, es relativamente
pequeña.
1
2
3
4
5
6
7
8
1 2 4 8
Estimación de coste Demanda
Figura 8. Speed-ups para la estimación adaptativa
para la secuencia Stockholm
1
2
3
4
5
6
7
8
1 2 3 4
Estimación de coste Demanda
Figura 9. Speed-ups para la estimación adaptativa
para la secuencia Foreman
5. Conclusiones y trabajos futuros
Se han obtenido mejoras apreciables con los
algoritmos propuestos que combinan la estimación
de movimiento adaptativa y el control del
equilibrio de la carga basada en la estimación de
coste, todo ello a nivel de GOP. Es de suponer que
este esquema dará mejores resultados al introducir
optimizaciones en el codificador que den lugar a
una mayor variación del tiempo de codificación en
función de las características de cada GOP.
Los esquemas propuestos, en particular la
asignación por estimación de coste, no serán
adecuados si la latencia es un parámetro de
importancia ya que necesitan que una buena parte
de la secuencia de vídeo esté disponible. Sin
embargo, sí serán adecuados para la codificación
de video almacenado o para aplicaciones en las
que el valor de latencia admisible sea elevado.
Como trabajos futuros nos planteamos dos
líneas de trabajo complementarias:
596 Aplicaciones
x La evaluación del esquema de asignación por
estimación de coste introduciendo nuevas
optimizaciones.
x La paralelización de la codificación de cada
GOP a varios niveles:
1. Descomposición en subcuadros.
2. Paralelización de los bucles de cómputo más
intensivos.
3. Paralelización SIMD de las operaciones
replicadas.
Referencias
[1] Akramullah, S.M., Ahmad, I., Liou, M.L.:
Performance of a Software-Based MPEG-2
Video Encoder on Parallel and Data
Distributed Computing Systems. IEEE
Transactions on Circuits and Systems for
Video Technology, vol. 7. (1997) 687-695
[2] Gong, K.L.: Parallel MPEG-1 video encoding.
MS thesis, Department of EECS, University
of California at Berkeley, Issued as Technical
Report, May (1994)
[3] ITU-T: H.26L Test Model Long Project
(TML-8), July (2001)
[4] Kralevich, N.: The NOW Split-C MPEG
Encoder. Internal Report Final Project CS267,
University of California at Berkeley. Issued as
Technical Report
[5] Martínez, L.F.: An Efficient ISO/MPEG-1
Layer II Encoder using Parallel Processing
Techniques. Proyecto de investigaci\'on de la
Universidad de Miami, Florida (1995)
[6] Olivares, T., Quiles, F., Cuenca, P., Orozco-
Barbosa, L., Ahmad, I.: Study of Data
Distribution Techniques for the
Implementation of an MPEG-2 Video
Encoder. Proceedings of the IASTED
International Conference Parallel and
Distributed Computing and Systems, MIT
Boston (1999)
[7] Pacheco, P.S.: Parallel Programming with
MPI, Morgan Kaufman Publishers, Inc
[8] Shen, K., Rowe, L.A., Delp, E.J.: A Parallel
Implementation of an MPEG-1 Encoder:
Faster then Real Time!. Conference on Digital
Video Compression on Personal Computers:
Algorithms and Technologies, San Jose-
California (1995) 407-418
[9] A.Hamosfakidis, Y.Paker, J. Cosmas “A study
of Concurrency in MPEG-4 Video Encoder”,
ICMCS’ 98, Austin, Texas, USA. June 1998
[10] A. Rodriguez, A. González, M.P.
Malumbres.: Performance evaluation of
parallel MPEG-4 video coding algorithms on
clusters of workstations. Parelec 04.
[11] http://iphome.hhi.de/suehring/tml/
XVI Jornadas de Paralelismo, JP '2005 597
Paralelización de técnicas de compensación local de movimiento
mediante OpenMP
J.M. Palomares Muñoz, D. Sánchez Salido, J. Olivares Bueno, E. Sáez Peña
Área de Arquitectura y Tecnología de Computadores
Depto. Electrotecnia y Electrónica
Escuela Politécnica Superior
Univ. de Córdoba
14071 Córdoba
jmpalomares@uco.es, olivares@uco.es
Resumen
La compensación local de movimiento es un
método que se utiliza ampliamente para cons-
truir mapas de vectores de desplazamiento. Es-
tos vectores contienen el desplazamiento de
los bloques que componen una imagen, entre
dos fotogramas de un vídeo. En este artículo
se realiza un estudio de un conjunto de téc-
nicas de compensación local de movimiento,
implementándolas secuencialmente y paraleli-
zándose las más complejas mediante OpenMP.
Se muestran unos experimentos en los que se
comparan las técnicas sin paralelizar con las
paralelizadas y se calcula el aumento de rendi-
miento. Para todos los métodos paralelizados,
como era de esperar, se han obtenido mejores
rendimientos que las versiones secuenciales de
los algoritmos.
1. Introducción
El procesamiento de imágenes y de vídeo es
una tarea repetitiva que se ejecuta sobre una
gran cantidad de datos, a los cuales se suele ac-
ceder en modo de “sólo lectura”, de este modo,
nos encontramos ante un conjunto de tareas
que son altamente paralelizables. Una de las
tareas que habitualmente se realiza al proce-
sar vídeo digital es la compensación del movi-
miento, que puede ser local o global (también
llamado de cámara) [1]. Mediante esta tarea se
consigue reducir la cantidad de datos necesa-
rios para la codificación de un vídeo. Nos cen-
traremos en la compensación del movimiento
local, que hoy por hoy es la única técnica que
está masivamente implementada en VLSI[2] y
utilizada en prácticamente todos los estánda-
res de compresión de vídeo[3, 4]. Este proce-
samiento se basa en la estimación del movi-
miento local utilizando block matching, en el
que se van realizando sucesivas comparaciones
de trozos de la imagen original, “buscándose”
la situación de los mismos en imágenes tem-
poralmente posteriores (o anteriores) a la uti-
lizada como referente. El resultado final de la
compensación de movimiento de un fotograma
de referencia con respecto a otro distinto será
un mapa de vectores de desplazamiento y un
mapa de errores de aproximación.
Existen diversas técnicas para realizar esa bús-
queda del movimiento del bloque de referencia
dentro de la imagen de destino. La técnica que
garantiza el resultado con el menor error cua-
drático medio entre la imagen original y la ge-
nerada a partir de la compensación local de
movimiento calculada, aunque la más costo-
sa computacionalmente hablando, es la técni-
ca de búsqueda exhaustiva o full–search, sin
embargo, existen otras técnicas que reducen
el costo computacional obteniendo resultados
similares en términos de calidad de la imagen
generada. En cualquier caso, todas las técnicas
de búsqueda lo que realizan es una estrategia
de selección de las posiciones donde se debe
colocar el bloque de referencia en la imagen de
destino para comprobar, mediante block mat-
ching, el grado de similitud.
El trabajo que se presenta en este artículo es
consecuencia del proyecto fin de carrera [5] de
un alumno en la titulación de Ingeniero Téc-
nico en Informática de Sistemas cursada en la
Universidad de Córdoba. En dicha titulación,
los alumnos tienen contacto con algunas asig-
naturas que tratan con el paralelismo, prin-
cipalmente “Arquitecturas Paralelas”, y tam-
bién, aunque en menor grado, “Ampliación de
Sistemas Operativos”. Ambas asignaturas uti-
lizan en sus prácticas el concepto de multi-
computador de memoria distribuida con comu-
nicación por paso de mensajes utilizando el sis-
tema PVM[7] para que el alumnado haga uso
del paralelismo. Los alumnos cuando finalizan
la carrera no han tenido contacto con otro sis-
tema, así pues, este proyecto se tomaba como
el primer contacto real de un alumno a pun-
to de finalizar la titulación con un sistema de
paralelización diferente a PVM.
2. Algunas librerías y sistemas de
paralelismo
Este breve epígrafe no pretende ser un exhau-
sitivo recorrido por todas las librerías y sis-
temas de paralelismo, puesto que existe una
gran cantidad de ellas, sino, que se debe tomar
como un pequeño resumen de los sistemas y li-
brerías más ampliamente utilizados, entre las
que cabe destacar:
Pthreads [6] Significa “Hebras POSIX”. Esta
librería está basada en las hebras POSIX
y está enfocada hacia los modelos de para-
lelización por memoria compartida. Pro-
porciona un conjunto muy completo de
funciones de bajo nivel para la creación
de hebras, sincronización de las mismas,
creación y manejo de semáforos, etc. Sin
embargo, los mayores inconvenientes es-
triban en que la interfaz de esta librería es
compleja, que el programador requiere un
gran control sobre la paralelización a muy
bajo nivel y que se restrige su uso a má-
quinas multiprocesador, ya que no existen
herramientas para el manejo de los siste-
mas en multicomputadores.
PVM [7] Es el acrónimo de Parallel Virtual
Machine. PVM es un sistema software que
permite a una red heterogénea de ordena-
dores comportarse como un único orde-
nador paralelo. La paralelización se reali-
za mediante paso de mensajes. Debe exis-
tir un proceso demonio que se encargue
del control de los diversos procesos en las
distintas máquinas, realizando de manera
transparente al usuario toda la comunica-
ción efectiva entre los distintos procesos,
así como toda la inicialización, sincroniza-
ción, terminación, etc. de los procesos. La
gran ventaja que plantea PVM es su he-
terogeneidad, sin embargo, esto se garan-
tiza, en general, a costa de menores ren-
dimientos.
MPI [8] Es el acrónimo de Message–Passing
Interface. MPI se definió como un están-
dar portable que trabaja bajo el supues-
to de memoria distribuida y comunicación
explícita por paso de mensajes. MPI de-
fine la sintaxis y la semántica de un con-
junto de rutinas de librería para la crea-
ción de aplicaciones paralelas en C y For-
tran. Existen muchas implementaciones
de MPI, tanto públicas como comercia-
les. No requiere la existencia de ningún
proceso demonio que controle la ejecución
en diversas máquinas. La funcionalidad
que ofrece MPI es similar a la de PVM,
aunque eso sí, con un mayor número de
funciones. Se puede ejecutar en sistemas
heterogéneos siempre y cuando el propio
programador se encargue de manejar las
diferencias entre los distintos sistemas.
OpenMP [9] Significa Multiproceso abierto.
Al contrario que las demás, este sistema se
basa en un compilador especial que acepta
una serie de directivas de precompilación
en las que se les indica las zonas de código
que se van a paralelizar, generándose las
hebras que se hayan indicado y maneján-
dose la sincronización entre las mismas.
OpenMP está orientada a máquinas mul-
tiprocesadoras con memoria compartida.
600 Aplicaciones
La principal ventaja es su facilidad de uso
y la facilidad que presenta para su esca-
labilidad. Su mayor desventaja es, igual
que con Pthreads, que no está orientada
a la paralelización entre máquinas multi-
computadoras.
3. Técnicas de compensación de
movimiento
Análogamente a lo descrito en el epígrafe ante-
rior, en la presente sección no se pretende dar
una relación pormenorizada de todas las técni-
cas existentes, nos centraremos en describir el
funcionamiento de un conjunto de técnicas[2],
ampliamente utilizadas y aceptadas.
Búsqueda completa Se realiza un barrido
completo de todas las posiciones dentro
de la ventana de búsqueda. La búsqueda
se suele realizar linealmente de izquierda
a derecha y de arriba a abajo, comenzan-
do por la esquina superior izquierda de
la ventana de búsqueda. Sin embargo, se
puede hacer en espiral, comenzando des-
de el centro de la ventana de búsqueda y
con un umbral de parada, de manera que
para la búsqueda al encontrar el primer
desplazamiento que proporcione un error
en el block matching menor que el um-
bral indicado. Mediante este mecanismo
se puede reducir enormemente el tiempo
de procesamiento al descartarse muchos
desplazamientos.
Búsqueda direccional Esta técnica es una
evolución de la anterior, en la que primero
se busca el mejor desplazamiento horizon-
tal, para posteriormente, centrado el blo-
que sobre ese desplazamiento horizontal,
buscar el mejor desplazamiento vertical (o
viceversa).
Búsqueda N–pasos Este método se basa en
presuponer que el error de aproximación
del block matching es una función suave,
no abrupta y, por tanto, plantea realizar
una búsqueda en los 8 píxeles que se en-
cuentran a una cierta distancia de despla-
zamiento del centro, seleccionando como
nuevo centro el desplazamiento que haya
producido menor error de aproximación.
Esta búsqueda se repite reduciendo el pa-
so a la mitad. En función de la distancia
de desplazamiento original, en N iteracio-
nes se encontrará el desplazamiento que
menor error de aproximación proporcio-
na.
Búsqueda jerárquica Todos los métodos
anteriores no proporcionan heterogenei-
dad en los mapas de vectores de despla-
zamiento debido a que todos los desplaza-
mientos se calculan de manera indepen-
diente, sin tener en cuenta el desplaza-
miento de los vectores adyacentes. Esto
puede producir mapas de vectores de des-
plazamiento no uniforme. Para evitarlo,
esta técnica construye una pirámide de
imágenes reducidas, tanto de la imagen
de referencia como de la imagen de des-
tino. Utilizando esta pirámide, y comen-
zando con las imágenes más pequeñas, se
realiza la compensación de movimiento,
propagando el vector de desplazamiento
obtenido en el nivel superior a los vec-
tores equivalentes existentes en el nivel
inmediatamente inferior, donde se refina
el vector con pequeños desplazamientos.
Mediante esta técnica se obtienen mapas
de vectores muy homogéneos.
4. Métodos de paralelización de
OpenMP
OpenMP propone muchos mecanismos para
realizar la paralelización. En OpenMP se pue-
den lanzar fácilmente varias hebras, que se eje-
cutarán concurrentemente y en paralelo (hasta
agotar el número de procesadores disponibles).
Sin embargo, habrá que buscar algún mecanis-
mo para garantizar la exclusión mutua y la sin-
cronización. Para esto, se ha considerado tres
tipos de paralelizaciones posibles:
atomic La ejecución de una instrucción se rea-
liza de manera atómica. De manera que
en la ejecución de una instrucción englo-
bada como atomic, no se van a encontrar
XVI Jornadas de Paralelismo, JP '2005 601
Tipo Implementación N. Hebras Tiempo Ganancia
Secuencial
1 0.5185596 1.0
OpenMP
atomic 1 7.80802 0.066
atomic 2 22.3505 0.023
omp_lock_t 1 13.40554 0.039
omp_lock_t 2 53.77336 0.010
reduction 1 0.5098016 1.017
reduction 2 0.2570702 2.017
Cuadro 1: Tiempos de procesamiento de diversas implementaciones.
en un momento determinado dos hebras
a la vez.
omp_lock_t Otro mecanismo clásico para con-
trolar la sincronización y mantener la ex-
clusividad en las secciones críticas es me-
diante el uso de semáforos, que es lo que
se realiza utilizando está directiva.
reduction Mediante esta técnica, se divide
automáticamente la carga de trabajo en-
tre las hebras disponibles y luego acumula
los resultados individuales en un único re-
sultado final.
Para poder decidirse por uno de los métodos
que tiene OpenMP se ha realizado un experi-
mento que consiste en paralelizar un bucle que
acumula la diferencia de cada par de elemen-
tos de dos vectores con igual tamaño (que es lo
que, básicamente, realiza el algoritmo de block
matching). Los vectores tienen un tamaño de
67108864 elementos (64 MB). Los tiempos de
procesamiento consumidos por cada método se
muestran en la Tabla 1, así como la ganancia
de velocidad con respecto al tiempo de refe-
rencia del algoritmo secuencial.
Contra todo pronóstico, los métodos de
atomic y omp_lock_t empeoran significativa-
mente el rendimiento al aumentar el número
de hebras. Para el caso de atomic, parece que
no es el método más adecuado para paralelizar
un bucle. Para omp_lock_t tampoco, pero en
éste hay una peculiaridad: prácticamente todo
el tiempo empleado en ejecutar la función es
tiempo de sistema, es decir, llamadas al siste-
ma que se realizan en modo protegido. Esto
es así porque el uso de semáforos requiere de
muchas llamadas con más privilegios que los
de usuario (de ahí las llamadas al sistema).
Por este motivo, el método de omp_lock_t se-
rá rentable siempre y cuando la carga que su-
pongan las instrucciones que están protegidas
por los semáforos, sea mucho mayor que la que
supone las llamadas al sistema. Como demues-
tran el resultado de las pruebas, que se mues-
tran en la Tabla 1, el mejor método de paraleli-
zación es el de OpenMP mediante reduction.
5. Resultados experimentales
Se han programado utilizando el lenguaje C
todos los métodos en su versión secuencial,
mientras que se han paralelizado solo los dos
métodos más complejos, a saber, el de búsque-
da en N–pasos y el de búsqueda Jerárquica.
Para la implementación paralela, primero se
ha aplicado sobre las versiones secuenciales un
perfilado y se ha observado donde se encontra-
ban los cuellos de botella. Se ha comprobado
que en los bucles es donde se pierde la mayor
cantidad del tiempo de procesamiento (apro-
ximadamente un 60 % del tiempo total) por lo
que se decidió paralelizar los bucles mediante
el método reduction de OpenMP.
En la Tabla 2 se muestran los tiempos (en seg.)
de los distintos métodos en su formato secuen-
cial, en su versión paralela y la ganancia del
método paralelo con respecto del secuencial.
Los experimentos han consistido en la com-
pensación de movimiento de dos fotogramas
consecutivos de tamaño 352 × 240 en tonos de
602 Aplicaciones
Vídeo terminator2 hall_monitor
Método Secuencial Paralelo Ganancia Secuencial Paralelo Ganancia
Búsqueda completa: 0.738215 — — 0.464876 — —
Búsqueda direccional: 0.108282 — — 0.080365 — —
Búsqueda N–pasos: 0.012383 0.012091 1.024 0.008825 0.007507 1.176
Búsqueda jerárquica: 0.019203 0.014678 1.308 0.015997 0.010093 1.585
Cuadro 2: Tiempos de procesamiento para dos vídeos diferentes de los diversos métodos y ganancia
de velocidad.
a) b)
c) d)
Figura 1: Resultado de la compensación local de movimiento según métodos de búsqueda. En gris claro
los vectores de desplazamiento. a) Búsqueda completa. b) Búsqueda direccional. c) Búsqueda N–pasos. d)
Búsqueda Jerárquica.
gris, pertenecientes a dos vídeos. El primero
pertenece a una escena de la película “Termi-
nator 2”, es un vídeo con movimiento local (en
algunas zonas bastante acusado, mientras que
en otras es bastante estático) y movimiento de
cámara suave. La segunda escena es un vídeo
de investigación, fácilmente descargable desde
Internet, llamado “hall_monitor”, que se ca-
racteriza por no tener movimiento de cámara
en absoluto y un movimiento local muy restri-
gido. La máquina sobre la que se han ejecuta-
do todos los experimentos es un biprocesador
Pentium III a 1133 Mhz con 1 GB de memoria
compartida y disco duro Ultra–SCSI160 de 80
GB. Al ejecutarse sobre un biprocesador, los
métodos paralelos se han lanzado con dos he-
bras.
Analizando los tiempos de procesamiento y la
ganancia de velocidad, mostrados en la Tabla
2, se puede asegurar que el aumento de ren-
dimiento es en uno de los casos (para la bús-
queda jerárquica), dependiendo del vídeo, de
un 30 % o de un 58,5 %, aunque teóricamen-
te podría aumentar hasta un 100 % (el doble)
al pasar la ejecución de un procesador a dos
procesadores. Para la búsqueda con N–pasos,
XVI Jornadas de Paralelismo, JP '2005 603
el aumento es mucho menor, de un 2,5 % o
17,6 % según el vídeo. Esta reducción de la ga-
nancia real frente a la teórica viene dada por
la simplicidad de las instrucciones a ejecutar,
es decir, el la sobrecarga u overhead que intro-
duce la ejecución de instrucciones de OpenMP
es mayor que la ejecución de las instrucciones
simples. La no disposición de máquinas multi-
procesadoras de memoria compartida con un
número de procesadores mayor a 2, nos ha re-
ducido la posibilidad de explorar la ejecución
con un mayor número de hebras.
Se observa una gran diferencia de resulta-
dos en función del vídeo, llegando a obtener
el doble de velocidad en el caso del vídeo
“hall_monitor”. Esto es debido a que este ví-
deo no tiene movimiento de cámara y, por tan-
to, para muchos bloques no hay hacer búsque-
da, ya que el desplazamiento ideal es (0, 0) y
en el primer block matching se obtiene un error
por debajo del umbral de parada, siendo en
muchos casos nulo.
6. Trabajo futuro
A pesar del aumento de rendimiento, se obser-
va que este aumento no llega a la teórica ga-
nancia de velocidad. Para poder aumentar el
rendimiento, realizaremos un proceso de perfi-
lado sobre las versiones paralelizadas, detec-
tando los nuevos cuellos de botella, aunque
sospechamos que éste se encuentra en la po-
lítica de selección del posicionamiento del blo-
que de referencia en la imagen de destino para
el cálculo del block matching, por lo que un
cambio en dicho módulo podría producir sig-
nificativas mejoras. Por falta de tiempo, este
extremo aún no ha podido confirmarse.
También pensamos paralelizar el resto de téc-
nicas de búsqueda propuestas (búsqueda com-
pleta y búsqueda direccional). Se contempla
la posibilidad de tratar con otros modelos de
movimiento, ya que este trabajo solo tiene en
cuenta al modelo de movimiento traslacional,
podríamos incluir el modelo de desplazamien-
to traslacional y rotacional, o bien, el modelo
de movimiento afín, que es mucho más general.
7. Conclusiones
Se ha presentado un trabajo realizado por un
alumno como proyecto fin de carrera, en el
cual se ha enfrentado a un conjunto de algo-
ritmos totalmente novedosos para él y ha te-
nido que implementarlos tanto en su versión
secuencial como paralelizarlos utilizando tan-
to una filosofía de paralelización nueva (mul-
tiprocesador con memoria distribuida frente
a multicomputadoras con memoria distribui-
da y paso de mensajes) como una herramienta
(OpenMP frente a PVM) con la que antes no
se había enfrentado previamente. Los resulta-
dos han demostrado que el mejor mecanismo
que proporciona OpenMP para la paraleliza-
ción de bucles que contienen instrucciones sen-
cillas es el método reduction.
Los resultados obtenidos paralelizando según
las distintas técnicas han mostrado el eleva-
do consumo en tiempos de procesamiento de
los métodos atomic y omp_lock_t. Esta últi-
ma técnica se destaca porque necesita muchas
llamadas privilegiadas, lo que se traduce en un
consumo en tiempo de sistema elevados.
También se han realizado unos experimentos,
en los cuales se muestra que la versión paralela
es más rápida que su homónima secuencial. Sin
embargo, se han conseguido resultados que se
encuentran lejos del límite teórico de ganancia
de velocidad, probablemente porque aunque se
hace el doble de rápido el block matching, al
encontrarse dos procesadores en lugar de uno
ejecutando el código, el algoritmo de selección
del posicionamiento del bloque de referencia en
la imagen de destino actúa como freno y cue-
llo de botella, impidiendo el aumento del ren-
dimiento. En cualquier caso, un aumento del
rendimiento de aproximadamente el 58,5 %, o
del 30 % dependiendo del movimiento del ví-
deo, para el método de búsqueda jerárquica es
una mejora bastante significativa.
Agradecimientos
Este trabajo ha sido desarrollado en los labo-
ratorios del área de Arquitectura y Tecnología
de Computadoras del Departamento de Elec-
trotecnia y Electrónica de la Universidad de
Córdoba, España.
604 Aplicaciones
Referencias
[1] Gottesfeld Brown, A. A survey of Image
Registration Techniques ACM Computing
Surveys, 24, (4). 1992. pp. 325–376.
[2] Bovik, A. (Editor) Handbook of Image and
Video Processing Academic Press. 2000.
pp. 220–222.
[3] ISO/IEC JTC 1. International Standard
ISO/IEC 11172: Information Technology
— Coding of Moving Pictures and Asso-
ciated Audio for Digital Storage Media up
to about 1,5 Mbit/s (MPEG-1). ISO. 1992
[4] UIT-T. Norma Internacional ISO/IEC
13818-2 Recomendación UIT-T H.262:
Tecnología de la Información — Codifica-
ción Genérica de Imágenes en Movimiento
e Información de Audio Asociada: Vídeo.
(MPEG-2). UIT. 1996
[5] Sánchez Salido, D. Librería de Compensa-
ción Global de Movimiento de Cámara y
Compensación Local de Movimiento. Es-
cuela Politécnica Superior. Univ. de Cór-
doba. España. 2003.
[6] Butenhof, D. Programming with
POSIX c
Threads. Addison–Wesley Prof.
1997.
[7] Geist, A.; Beguelin, A.; Dongarra, J.;
Jiang, W.; Manchek, R.; Sunderam, V.
PVM 3 User’s Guide and Reference Ma-
nual. Oak Ridge National Laboratory. Oak
Ridge, Tennessee, USA. 1994.
[8] Pacheco, P. Parallel Programming with
MPI. Morgan Kaufmann Pub. 1996.
[9] Chandra, R.; Menon, R.; Dagum, L.; Kohr,
D.; McDonald, J. Parallel Programming in
OpenMP. Morgan Kaufman Pub. 2000.
XVI Jornadas de Paralelismo, JP '2005 605
   
               "        ' ( )       .    0 
      "   ' 4  "  '  0 9 ) 0 ;  > ;  ?
@ B C D F G I D L G N G P D Q R T B U W L Y [ G ^ ` a Q R c B U a L W G P W e W g g W P W L D i R
@ B ^ j P L [ l ` D Q C D F G R o B ^ j P L [ l ` D Q q D P L a W G D i
r s t v x z v { s | z ~  s €  z v  ‚  z „ … v † ‡ ˆ ‰ ˆ Š ‹ ~ { t  z v … „ Ž |
€ ˆ  ˆ  ˆ ‡ ˆ ‡ | “ ~ x { – z „ … v
˜ | „ ™ s x  „  v   s › v › v œ  | v
€  ž Ÿ   ¡ ¢ › v › v œ  | v †  s | s x „ “ s ˆ €  t v ¤ v
¥
… ¦ s ~ | §  v { v x z „ | § œ { „ x v |  v § … v  „ v | ~ § © x t s  x „ « ¬  ¦ ¦ ˆ s 
® ¯ ° ± ² ¯ ³
´ µ ¶ · ¸ ¶ ¸ ¹ º » º ¼ ½ · ¶ ¾ ¹ ½ ¾ ½ µ ¶ µ ¿ ½ · º À Á ½ ¹ Â ¸ Ã ½ · ¾ º Ä
¹ º À ¶ À ½ · ¾ º ¹ º À º ¹ ¶ · ½ À Å Æ Â Ç µ ¿ ¶ À ¾ ¹ ½ » À ¶ Ã º ¿ ¶ À É Ç Ä
¿ Â Á ½ É ½ ¹ ¹ ¶ Æ ¸ ½ ¹ ¿ ¶ ´ ¹ ¹ ½ ¹ ¶ · Ë Ì Ã » º · ¾ ¹ ½ ¾ Å ¶ · ¸ º ·
¶ · ¸ Í µ » º · º ¿ º · ¶ µ ¸ Ï Æ µ Â Æ º · º À Á ½ ¹ Ð ¸ Ã Â Æ º · ¶ Ñ º Æ Ä
¸ º · Ë Ì ¿ ¶ Ã Í · Ò · ¶ ¾ ¹ ¶ · ¶ µ ¸ º µ À ½ · ¹ ¶ · Å À ¸ º ¿ ½ · Æ ½ Ã Ä
¾ Å ¸ º Æ Â ½ µ º À ¶ · ½ » ¸ ¶ µ Â ¿ ½ · ¾ º ¹ º Â Ã ¾ À ¶ Ã ¶ µ ¸ º Æ Â ½ µ ¶ ·
¿ ¶ À ½ · Ã Â · Ã ½ · Æ ½ µ À º · Ö ¶ ¹ ¹ º Ã Â ¶ µ ¸ º · × ¾ ¶ µ Ø Ú
Û
Ø Ú Ü ¶ µ Å µ º × ¹ Â Á Â µ Þ ß à à Ë
á â ä
³ å æ ç è ± é é ê ë ³
Ì À º Ö ½ ¹ º ¿ ¶ ¸ ¹ º µ · Ã Â ¸ Â ¹ Å µ Ã ¶ µ · º ¼ ¶ ¶ µ Æ Ç ¿ Â Ä
Á ½ » Â µ º ¹ Â ½ ¾ Å ¶ ¿ ¶ µ º ¾ º ¹ ¶ Æ ¶ ¹ Â µ ¸ ¶ ¹ í ¶ ¹ ¶ µ Æ Â º · î Å ¶
¶ ï Â ¸ ¶ µ î Å ¶ Ï · ¸ ¶ · ¶ º ¹ ¶ Æ Â » Â ¿ ½ ¶ Ñ º Æ ¸ º Ã ¶ µ ¸ ¶ ¸ º À
Û
Æ ½ Ã ½ í Å ¶ ¶ µ ï Â º ¿ ½ Ë É Å º µ ¿ ½ · ¶ ¿ ¶ ¸ ¶ Æ ¸ º Å µ ¶ ¹ ¹ ½ ¹ Ò
Å µ º ¾ ½ · Â » À ¶ · ½ À Å Æ Â Ç µ ¶ · î Å ¶ ¶ À ¹ ¶ Æ ¶ ¾ ¸ ½ ¹ · ½ À Â Æ Â Ä
¸ ¶ º À ¶ Ã Â · ½ ¹ À º ¹ ¶ ¾ ¶ ¸ Â Æ Â Ç µ ¿ ¶ À » À ½ î Å ¶ ¿ ¶ ¿ º ¸ ½ ·
¸ ¹ º µ · Ã Â ¸ Â ¿ ½ Ë ð Â µ ¶ Ã » º ¹ Á ½ Ò ¶ Ñ Â · ¸ ¶ µ º ¾ À Â Æ º Æ Â ½ µ ¶ ·
¶ µ À º · î Å ¶ µ ½ ¶ · ¾ ½ · Â » À ¶ ¾ ¶ ¿ Â ¹ À º ¹ ¶ ¸ ¹ º µ · Ã Â · Â Ç µ
¿ ¶ À ½ · ¿ º ¸ ½ · Ò ¹ ¶ · Å À ¸ º ¾ ½ Æ ½ ¶ ò Æ Â ¶ µ ¸ ¶ ½ Â µ Æ À Å · ½
· Å ¾ ½ µ ¶ Å µ º À ¸ ½ Á º · ¸ ½ ¶ Æ ½ µ Ç Ã Â Æ ½ Ò ¾ ½ ¹ À ½ î Å ¶ ¶ À
à ¶ µ · º ¼ ¶ ¿ ¶ » ¶ · ¶ ¹ ó ô õ õ ö ÷ ø ù ô ¶ µ ¶ À ¿ ¶ · ¸  µ ½ Ë ´ · ¶ µ
¶ · ¸ º · · Â ¸ Å º Æ Â ½ µ ¶ · Æ Å º µ ¿ ½ · ¶ Å ¸ Â À Â ú º µ À ½ · ¿ ¶ µ ½ Ä
à  µ º ¿ ½ · ó û ù ø ÷ ô ü ó ô õ õ ö ó ý ô õ ö ü ù ö ö õ õ ô õ ö ü þ ÿ


ÿ õ õ ô õ
ô õ õ ö ó ý ø  ÷
ô ù ö
  Ò   Ë ´ Ñ Â · ¸ ¶ µ Ã Å Æ Ö ½ ·
¸ Â ¾ ½ · ¿ ¶ Æ Ç ¿ Â Á ½ · Æ ½ ¹ ¹ ¶ Æ ¸ ½ ¹ ¶ · ¿ ¶ ¶ ¹ ¹ ½ ¹ ¶ ·  Æ Ç ¿ Â Ä
Á ½ · ¿ ¶ » À ½ î Å ¶ þ À Â µ ¶ º À ¶ · ½ Æ Ð Æ À Â Æ ½ ·
Ò Æ Ç ¿ Â Á ½ · ¿ ¶
Æ ½ µ ï ½ À Å Æ Â Ç µ Ò ¶ ¸ Æ Ë ´ · ¸ ¶ ¸ ¹ º » º ¼ ½ · ¶ Æ ¶ µ ¸ ¹ º ¹ Í ¶ µ
¶ À ¶ · ¸ Å ¿ Â ½ ¿ ¶ À ½ · Æ Ç ¿ Â Á ½ · ¿ ¶ » À ½ î Å ¶ Ë
 º ¿ º À º Æ ½ Ã ¾ À ¶ ¼ Â ¿ º ¿ ¿ ¶ À ¾ ¹ ½ » À ¶ Ã º Ò À º Ã º
Û
½ Ä
¹ Ð º ¿ ¶ À ½ · ¸ ¹ º » º ¼ ½ · ¶ µ À º À Â ¸ ¶ ¹ º ¸ Å ¹ º ¾ ¹ ½ ¾ ½ µ ¶ µ · Å
¹ ¶ · ½
À Å Æ Â Ç µ º ¾ À Â Æ º µ ¿ ½ ¸ Ï Æ µ Â Æ º · Ö ¶ Å ¹ Ð · ¸ Â Æ º ·   Ò   Ë
 º ¾ ¹ ½ ¾ Å ¶ · ¸ º î Å ¶ Ö º Æ ¶ Ã ½ · ¶ · À º ¹ ¶ · ½ À Å Æ Â Ç µ ¿ ¶ À
¾ ¹ ½ » À ¶ Ã º Ã ¶ ¿ Â º µ ¸ ¶ ¸ Ï Æ µ Â Æ º · ¶ Ñ º Æ ¸ º · Ë ð ¶ Ö º µ
¿ ¶ · º ¹ ¹ ½ À À º ¿ ½ º ¾ À Â Æ º Æ Â ½ µ ¶ · É   » º · º ¿ º · ¶ µ À º
¸ Ï Æ µ Â Æ º ¿ ¶  º Ã Â ò Æ º Æ Â Ç µ
Û
Ì Æ ½ ¸ º Æ Â Ç µ Ò ¹ ¶ º À Â ú º µ Ä
¿ ½ Å µ º » · î Å ¶ ¿ º ¶ µ ¾ ¹ ½ í Å µ ¿ Â ¿ º ¿ Ë Ú º ¹ º Ã ¶ ¼ ½ Ä
¹ º ¹ ¶ À ¹ ¶ µ ¿ Â Ã Â ¶ µ ¸ ½ ¿ ¶ À º · Ã Â · Ã º · · ¶ Ö º ¾ ¹ ½ Æ ¶ ¿ Â Ä
¿ ½ º · Å ¾ º ¹ º À ¶ À Â ú º Æ Â Ç µ Å ¸ Â À Â ú º µ ¿ ½ ¸ º µ ¸ ½ ¶ À ¾ º ¹ º Ä
¿ Â Á Ã º ¿ ¶ ¾ º · ½ ¿ ¶ Ã ¶ µ · º ¼ ¶ · Æ ½ Ã ½ ¶ À ¿ ¶ Ã ¶ Ã ½ Ä
¹ Â º Æ ½ Ã ¾ º ¹ ¸ Â ¿ º Ë ´ À ¶ · î Å ¶ Ã º ¿ ¶ ¾ º · ½ ¿ ¶ Ã ¶ µ Ä
· º ¼ ¶ · · ¶ Ö º Â Ã ¾ À ¶ Ã ¶ µ ¸ º ¿ ½ ¿ Â ¹ ¶ Æ ¸ º Ã ¶ µ ¸ ¶ Æ ½ µ À º
Ö ¶ ¹ ¹ º Ã Â ¶ µ ¸ º Ø Ú Ü  !  Ë ð Â µ ¶ Ã » º ¹ Á ½ Ò ¶ À ¿ ¶ · º ¹ ¹ ½ Ä
À À ½ ¿ ¶ À º º ¾ ¹ ½ Ñ Â Ã º Æ Â Ç µ ¿ ¶ Ã ¶ Ã ½ ¹ Â º Æ ½ Ã ¾ º ¹ ¸ Â Ä
¿ º · ¶ Ö º ¹ ¶ º À Â ú º ¿ ½ Æ ½ µ À º À Â » ¹ ¶ ¹ Ð º ¿ ¶ ¶ · î Å ¶ À ¶ ¸ ½ ·
" $ & & ( $
 * Ò +  ¶ µ À Å Á º ¹ ¿ ¶ Å ¸ Â À Â ú º ¹ ¿ Â ¹ ¶ Æ ¸ º Ã ¶ µ ¸ ¶
× ¾ ¶ µ Ø Ú  ß  Ë  º À Â » ¹ ¶ ¹ Ð º
" $ & & ( $
¾ ¹ ½ ¾ ½ ¹ Æ Â ½ µ º
¶ · î Å ¶ À ¶ ¸ ½ · º À Á ½ ¹ Ð ¸ Ã Â Æ ½ · ¾ º ¹ º À º ¹ ¶ · ½ À Å Æ Â Ç µ ¿ ¶
¾ ¹ ½ » À ¶ Ã º · ¿ ¶ ½ ¾ ¸ Â Ã Â ú º Æ Â Ç µ Æ ½ Ã » Â µ º ¸ ½ ¹ Â º
Û
¿ ¶
¶ À À ½ · · ¶ Ö º Å ¸ Â À Â ú º ¿ ½
" $ & & ( $ 0 0 ( 1 (
Ë
´ À Æ ½ µ ¸ ¶ µ Â ¿ ½ ¿ ¶ À º ¹ ¸ Ð Æ Å À ½ · ¶ Ö º ½ ¹ Á º µ Â ú º ¿ ½
¿ ¶ À º · Â Á Å Â ¶ µ ¸ ¶ í ½ ¹ Ã º  ´ µ À º · ¶ Æ Æ Â Ç µ * · ¶ ¿ ¶ Ä
ò µ ¶ ¶ À ¾ ¹ ½ » À ¶ Ã º ¿ ¶ Æ Ç ¿ Â Á ½ · ¿ ¶ » À ½ î Å ¶ î Å ¶ · ¶
¾ ¹ ¶ ¸ ¶ µ ¿ ¶ ¹ ¶ · ½ À ï ¶ ¹ Ë  º · Æ ½ µ · Â ¿ ¶ ¹ º Æ Â ½ µ ¶ · ¿ ¶ Â Ã Ä
¾ À ¶ Ã ¶ µ ¸ º Æ Â Ç µ Æ ½ Ã Å µ ¶ · º À º · ¿ ½ · ¾ ¹ ½ ¾ Å ¶ · ¸ º · · ¶
¿ ¶ · Æ ¹ Â » ¶ µ ¶ µ À º · ¶ Æ Æ Â Ç µ Þ Ë  º · ¶ Æ Æ Â Ç µ  ¶ · ¸ Í ¿ ¶ Ä
¿ Â Æ º ¿ º º À º ¶ Ñ ¾ À Â Æ º Æ Â Ç µ ¿ ¶ À º Â Ã ¾ À ¶ Ã ¶ µ ¸ º Æ Â Ç µ
Å · º µ ¿ ½ × ¾ ¶ µ Ø Ú Ò Ã Â ¶ µ ¸ ¹ º · î Å ¶ À º Â Ã ¾ À ¶ Ã ¶ µ ¸ º Ä
Æ Â Ç µ Æ ½ µ Ø Ú Ü · ¶ ¿ ¶ · Æ ¹ Â » ¶ ¶ µ À º · ¶ Æ Æ Â Ç µ  Ë  ½ ·
¹ ¶ · Å À ¸ º ¿ ½ · Æ ½ Ã ¾ Å ¸ º Æ Â ½ µ º À ¶ · · ¶ ¾ ¹ ¶ · ¶ µ ¸ º µ ¶ µ À º
· ¶ Æ Æ Â Ç µ + Ë 8 Â µ º À Ã ¶ µ ¸ ¶ Ò ¶ µ À º · ¶ Æ Æ Â Ç µ  · ¶ ¶ µ Å Ä
à ¶ ¹ º µ À º · Æ ½ µ Æ À Å ·  ½ µ ¶ ·
Û
¶ À ¸ ¹ º » º ¼ ½ í Å ¸ Å ¹ ½ Ë


            
  
  
A = {a1, a2, ..., ar}
        "  % 
r
 &  )
*   "  , - . % 0  2        "  ,  &  %    * 0   7 9   

  : ; = ? :  @ A ? B D =
E
 ,  ,  &  *   "  , I    =  = I
? :  @ A ? B D = -
   M % 0 N  %  Q &  R   7 )  7 0 
C
,  Q 7 
A
 ,  
,  Q       "    W   X  % 
An Z  &       "  % 
"  %  , &  ,   %    , %  &   N 0 "  % ^  
n
,  Q 7 
A
-
. &  ,  &  *   "  , % 
C
,  &  , %    * 0       b  I
? :  @ A ? B D = Z @ = ? : " = b ? I d
E

n
 =  D B ; $ ? ? :  @ A 
? B D = - . &   *  7 
M
%  h  &  Q 7  ,    &  M % 0 N 
C
Z  , "   , d &    7 % 0   & 0 %  % %  & ,  Q       "  , 
&  & &  *  ;    ' = ? :  @ A ? B D = -   , *   ,    , , 
m  7 *     *  ,       0  , %   , "  ,
M
h  &  Q 7  , -
  %    * 0   ? B I ;   @ B  ? : (    B  D   " 7 
%  , ,       0  ,
vi
E
vj
 &   *  7  %  Q 0 " ,   R  
,  % 0 m  7    0   -   ? B I ;   @ B     B   ? :  @ A ? B 
D = d %    "  %  h  7
d(C)
d  , &  % 0 , "    0  %  -  * )
* 0  N * 9 , h  R   /    " 7  &  , % 0 , " 0  "  , h  &  Q 7  ,
%  &  M % 0 N  
d(C) = min{d(ci, cj )|ci, cj ∈ C, ci = cj }
u  7    * h &  d &  % 0 , "    0  * X  0 *  h  7   &  M )
% 0 N 
C = {0011, 1011, 1111}
 , -
.    M % 0 N    
M
h  &  Q 7  , %  &   N 0 "  %
n
,  Q 7     & m  Q  "  % 
r
, X * Q  &  ,
E
% 0 , "    0 
* X  0 * 
dmin
d ,  &  %    * 0    
(n, M, dmin)
)
 M % 0 N  7 )  7 0  -
  % 0 , "    0  * X  0 * 
dmin
 , " 9 & 0 N  %   & 
  h   0 %  %   7 7   "  7 
E
%  "   "  7  %  &  M % 0 N 
C
       M % 0 N 
C
 , %  "   "  7 % 
v
 7 7  7  , , 0
E
, M &  , 0
dmin ≥ v + 1
-    M % 0 N 
C
 ,   7 7   "  7
% 
e
 7 7  7  , , 0
E
, M &  , 0
dmin ≥ 2e + 1
-
z  "     , d , 0    M % 0 N 
C
" 0       % 0 , "    0 
* X  0 * 
dmin
d
C
h   %  %  "   "  7
dmin − 1
 7 7  )
7  ,
E
  7 7  N 0 7
(dmin − 1)/2
 7 7  7  ,      & )
R  0  7 h  &  Q 7  %  &  M % 0 N  -
    7 7    0 M  %   7 7  7  , ,  Q  ,     & b B  
@ B B = ? :  4 5 B   7 : b = I B  B  B ; $ ? d R    , "  Q &   
R      "  &  7    h  0 M  %     h  &  Q 7 
W
 
h  7 "     0   "   &  M % 0 N 
C
d ,   %  h "   &  7 0 "  7 0 
%   &  N 0 7   *  h  &  Q 7 
W
  W 0  %  d  R  { & &  R  
,    4 I @ : b @    
W
-   h  &  Q 7   4 I @ : b @  
  ,  7 9  R  { & &   
E
 % 0 , "    0  
W
,   &  * 9 ,
h  R   /  %    " 7   & 7  , "  %  % 0 , "    0  , 
W
d
 , %   0 7 
d(W, W

) < d(Y, W

), ∀Y ∈ C; Y = W
-
. &  2  7  %  % 0 ,  /  7    M % 0 N    7 7   "  7 % 
 7 7  7  , &  ,  Q   " 0 W  , R   ,  h &   "    ,   
•
} 0  0 * 0 ~  7
n
 z     " 7  7 h  &  Q 7  , %  &   N 0 )
"  % * X  0 *  d h  7  R    & *   ,    ,  h   % 
" 7   , * 0 " 0 7 7 9 h 0 %  *   "  -
•
}   0 * 0 ~  7
dmin
   % 0 , "    0  %  -  * )
* 0  N   " 7  h  &  Q 7  , %  Q  ,  7 * 9  0 *  h  )
7  N  7   " 0 ~  7    & "   0 W  & %    7 7    0 M 
   & 7    h "  7 -   , h  &  Q 7  , 2   %  ,  7 & 
* 9 , % 0 m  7   "  , h  , 0 Q &  d %  *    7  R   ,  
* 
E
0 * h 7  Q  Q &  R   ,  h 7  %  ~    ,  ^ )
 0   "  ,  7 7  7  ,   *  h  7  " 7   , m  7 *  7   
h  &  Q 7  %  &  M % 0 N     " 7  -
•
}   0 * 0 ~  7
M
 }   0 * 0 ~  7  &   *  7  % 
h  &  Q 7  , %  &  M % 0 N  Z  &  Q   " 0 W   ,    7 )
  7 ,  &  * 9 , h  , 0 Q &  
An -
 0   * Q  7 N  d  , "  ,  Q   " 0 W  , h 7  ,   "      )
<
0  "  ,   " 7  , X d &  R   2    R   ,  h &   "    h )
" 0 * 0 ~  7    %  &  , h  7 9 *  " 7  ,
n
d
M

dmin
d
%  %  , &  , W  &  7  , %  &  ,  " 7  , %  , -    h  0 M 
* 9 , m 7      "  %  & h 7  Q &  *   , *   0 * 0 ~  7
dmin
%  %  ,
n E
M
-
z & h 7  Q &  *  R   ,  2  h &   "   %  7  ,  & W  7  
 , "  " 7  Q     ,  h  7 " 0   %  %     , W  &  7  , ^   ,
% 
M E
n
 Q "    7 d %    " 7  "  %  , &  , h  , 0 Q &  ,
 M % 0 N  , R   ,  h   %   N    7  7 d  R   &  M % 0 N 
R   h  ,   &  * 
E
 7 % 0 , "    0  * X  0 *  - z &   )
*  7  "  "  & %  h  , 0 Q &  ,  M % 0 N  , % 
M
h  &  Q 7  ,
%  &  M % 0 N  % 
n
Q 0 " ,  , 0 N   & 
2n
M
- z , "   0 m 7 
h   %  2    7 R   &  7  ,  &   0 M  %  & h 7  Q &  *  ,  
h 7 9  " 0   *   "  0  W 0  Q &        "   & " 0  * h  % 
 M * h  "  ,  7  ^  7  d
E
 R     *   "    h     )
 0  & *   "  d     %   & N    %  &  , h  7 9 *  " 7  ,
M

n
 7    ,   , 0 Q &  *   "  -
=
?

‚            @       „ ‚  C
   E     F G  
u  7  &   Q "    0 M  %  &  M % 0 N  % 
M
h  &  Q 7  , % 
n
Q 0 " ,    &  * 9  0 *  % 0 , "    0  * X  0 *  ,  2 
0 * h &  *   "  %   & I  D = b B ;  = ? :  =  I ; b $ @ @ B A 
? : L $  @ =  M $  ; = I  †  - z , "   & N  7 0 " *  h  7 * 0 " 
N    7  7 "  %  , &  , h  , 0 Q &  ,  M % 0 N  , % 
M
h  &  )
Q 7  , %  &   N 0 "  %
n
d %    " 7  &  , R   ,   Q "   % 7 9
&  ,  &   0 M  ^   & - z &  M % 0 N  ,  &   0 M  ,  7 9  R  { &
R   "   N  &  * 
E
 7 % 0 , "    0  * X  0 *  %    " 7 
"  %  , &  , N    7  %  , d "   0   %        "  R  
608 Aplicaciones
         
             " #      %         (    
          *                  %     
              +     " #          .   /            1       (    
         3 4             1            /             
             4 6 7    " #     3 4      %      .     %             :  :   
= = =
>
    ?        
   @    A B  6   7       %         (    
= = =
>
    ?       
     C         1          %     
?            ?     (   %         %      %     
= = =
>
D
    F  G 

           I J K K L J
  ! # & ' ( * ' + , . + ' 1 ( 4 5 ! ' 7 1 ( 4 1 # ( . ! ' ( * . # 4 ' .
= ? & ' = . A
 # . E 1 + = . ! + !  4 ' + J 4 5 =   * 1 ! ( L
* . N
( O  ! . & P .  ( * ' , . 4 1 # ( ' ( * # ( * . N J L
4 + O  * 1 ! 1 ( J 1 ( (  N 4 1 # T  # * 1 ( O  ( , .
W
. #
. 7 # + . + 4 1 # * # 7 . # J .  . J . N + . O Z Z A A A Z Z P [ !
n
N ' * (  ] 4 1 # J 1 O  ( + !  4 J .  + 1 E  # ! ' ! . !
! J ? + N 1 J ! &  J 1 + . 4 ' 5 # [ . J * # + # ( 4 . ( 1
( 5 J 1
M − 1
 . J . N + . ( . ( J 4 4 ' 1 # . +  A d 1 # ( * .
4 1 # ( ' ! + . 4 ' 5 # # 1 (  + ! + ? J . & . 4 * ' *  ! ! J .
( 1 J  4 ' 5 # ] ! N ' ! 1 . O  ( ' =  + ( 4  =  J O 
 # 1 ! J 1 ( 4 5 ! ' 7 1 ( 4 1 # J . = .
W
1 + ! ' ( * . # 4 ' . = l L
# ' = .  1 ( ' N J 4 1 # * ' # ! ' 4 P .  . J . N + . A
m * + . = ! ' ! . . ! 1  * . ! . 4 1 # ( ' ( * # 7 # + . +

# ' 4 . = # * . O  J J 1 ( 4 5 ! ' 7 1 ( O  4 1 = ' # 4 #
 1 +  # .  . J . N + . O  ( # 4  # * + # J .  + ' = L
+ . = ' * . ! ! J 4 1 # T  # * 1 !  1 ( ' N J (  . J . N + . ( A  .
( 1 J  4 ' 5 # O  ( 1 N * # ! + ? ( 7  ' + ? ( ' # ! 1 & . 4 * .
! N ' ! 1 . O  J . (  . J . N + . ( ! J . ( 7  # ! . = ' L
* . ! * ' # # J 1 ( N ' * ( ' # , + * ' ! 1 ( + (  4 * 1 . J 1 ( !
J .  + ' = + . [  1 + T =  J 1  # J .  + ' = + . = ' * . !
( # 4  # * + . # J . (  . J . N + . ( Z Z Z 
W
Z  Z  ] O 
4 1 + + (  1 # ! + l . # . J . (  . J . N + . ( # J . ( 7  # ! .
= ' * . !    Z
W
 Z  Z  A  ( * . E 1 + = . ] J 1 ( (  N L
4 1 # T  # * 1 ( 4 1 # ( * +  ' ! 1 ( ( 5 J 1 4 1 #  . J . N + . ( ! J .
 + ' = + . = ' * . ! ( 1 # . # ? J 1 7 1 ( . J 1 ( O  (  1 L
! + l . # 4 1 # ( * +  ' + ( 5 J 1 4 1 #  . J . N + . ( ! J . ( 7  # L
! . [
# ' 4 . = # * * # ! + l . # ' # , + * ' ! 1 ( J 1 ( N ' * (  ]
# J ( # * ' ! 1 ! O  J . ! ' ( * . # 4 ' . = l # ' = . 1 N * L
# ' ! . ( + l . J . = ' ( = . A
v ! = ? ( ]  # . , w ( P . 1 N * # ' ! 1  1 +  # . !
J . ( + . = . ( ! J ? + N 1 J ! &  J 1 + . 4 ' 5 # ]  # .  1 ( ' N J
( 1 J  4 ' 5 # 4 1 #  # . ! * + = ' # . ! . ! ' ( * . # 4 ' . = l # ' L
= . ] ( '
# 1 * + . ! J . ( + . = . ( ( ( * ? 1 N * # ' # ! 1
 # 4 5 ! ' 7 1 4 1 #  # . ! ' ( * . # 4 ' . = l # ' = . = # 1 + 1
' 7  . J . x ( * . ] (  1 ! . ! ' 4 P . + . = . R   ( * 1 O 
 1 + J J . # 1 , . . ( +  1 ( ' N J = T 1 + . + J . ( 1 J  4 ' 5 # ]
( ' # 1 O  x ( * .  1 ! + l . ' # 4 J  ( 1 =  1 + . + A
' # . J = # * ] ( P . ! * + = ' # . ! 1 O  J 4 5 ! ' 7 1
( 1 J  4 ' 5 #  + = ' * . 4 1 + + 7 ' +  # #
= + 1 = l # ' = 1
! + + 1 + ( [ (  4 ' z 4 . ! 1  1 + J  (  . + ' 1 1 ]  1 +
! E 4 * 1 ]   A { ( * 1  + = ' *  1 ! . + . O  J J . ( + . L
= . ( O  7 # + # 4 5 ! ' 7 1 ( O  # 1 4  =  J . # ( * .
4 1 # ! ' 4 ' 5 # A
S | }
~    ~  €   ‚ ƒ „ € ‚ … €
>
  € T V
{ # J  7 . + ! . N 1 + ! . + ! ' + 4 * . = # * J . ' =  J L
= # * . 4 ' 5 # 4 1 # m  # † ‡ !  # . J 7 1 + ' * = 1 O 
 * ' J ' 4 J . * x 4 # ' 4 . !  . = ' z 4 . 4 ' 5 #
W
v 4 1 * . L
4 ' 5 #  . + . + ( 1 J , + J  + 1 N J = . O  # 1 ( 1 4  L
 . ] ( P .  * ' J ' w . ! 1 J ( O  J * 1
          
A
{ ( * ( O  J * 1 + O  ' + O  J  (  . + ' 1 ' =  J L
= # *  # . 4 J . ( X Y [ \ ^ _ ` ! 1 # ! ( ! z # J .
( * +  4 *  + . ! ! . * 1 ( ! J  + 1 N J = . ]  # . 4 J . (
a
[ ^ c d e [ f  . + . +  + ( # * . + J + (  J * . ! 1
W
 # .
4 J . (
a
c \ X Y [ \ ^ _ `  . + . +  + ( # * . +  # (  N  + 1 L
N J = . A  . ( * +  4 *  + . ! J . ( 4 J . ( ( + O  + ' ! . ( ]
 . + . J 4 . ( 1 4 1 # 4 + * 1 ! J  + 1 N J = . ! J d 5 ! ' 7 1
d 1 + + 4 * 1 + ! { + + 1 + ( ] ( 1 # J . ( O  ( =  ( * + . #
# J . ' 7  + .  A
XVI Jornadas de Paralelismo, JP '2005 609

  

   
            

    

 " #
     #    '    
  ,  " # " '    # 
1
  
2
     5 6     #      8    "     :   #   1
 " <       " 5 8   5  
# "       
  #    # "

2
 
8

  
#   ? 8   A B D F   5 G  :      1
          8

5   " I
J    :      : 
  

    
# "     8
 G 5     :   8      
 " I

      

5 " , #
# " ' 
2
F # 
# " '  P

 

J      

     
 " #  
 8  
   #  
 "

2
  "   
 G  "  "      J 8   J   5
  " 5 " 
  
2
8      D
T           5 8  
 
 " 
       8   1
 "      

 " I

2
:  "     #  
 "  :  
 " 

      
2



 " I
   D B

#  5   I
 :   "  1
  
   
 " 
       8    "       #   1
        J 8   J   5
 "  " # "
   D T  #

8
  :
   ] 
   8  " 5          
 " 
:     
1
5 " , #
         J 8   J   5

2
6      
.
1
 "   

 " 
 
J "     D T  " 8    "     # " ' 

 
 " I
    
 " 
  8        "   

 
  8   J   5
  5
] " 5 " I
# " '   5 "  " 5 " I
# " ' 
2
   " 8        # # " '      J 8   J   5
   8  1
# " , #
  ^ 8  " 5    1   1 5     : 8   d    " 
 :  #  D
T   8   #    , 
 " I
# 
       #    
 

    # " '  ^     #
     
J      

 
8  " 1
5  
    # " '    #   

   G 
' 8 " 5
 "  5 1
8      
d   # " '     
 
# " '  P    h  " #
  1
6   J   " 5

   J     " 5

:  "     8   1
J   5
  5
] " 5 " I
# " '    # 
   
 " 
 
   

# h
^     #
     

5 " , #
# " ' 
2
F # 
# " '      #  <  
5         # " '     


   #   

  D
T   
" 5 8   5  
# " '  :     
 "  P
    1
8  # " , #

         
d   5
       


"  <    
        J 8   J   5

2
#  G        1
J   G     #

   #

5  5    D B

    :
P
  " 5 8   5  
   
d   # " '     
  

# 
 

 
  D
 
5 " , #
# "    
2

 8  1

  
 " I

      #
      ]
#
5    

5 "  5
    
 "      # " 
   
" 5 8   5   1

# " '    A B i :
2
  
2

P
  "   5   # "  


   
8

 
   "   D
T         5
8

    : 
  " 
  5 8  
1

 8


      # " '      #    

 5
#  1


   5  5   "
#  5 8
 " 
D F  h :  "  "   
P "     8   #     8       
 " I
 

5 " , #
1
# " '     " d         J 8   J   5
  " 5   G  
1
5    D A "   
 :   P "   5
        #
 <

   ] 
    #

8
          
 " 

2
  "    
    #      8    "  
    J 8   J   1
5
 : 8    "
5    <    
   8  
 <     # 
1
  :   
 " 
 
J "     D    
d   5
:  
5
    
 
 " I
   
  ] 
# # "      "     1
# "       
 " 
5 "   
         P "     
  #
 <
    
 " I
 
 
5 " , #
# "         
  J 8   J   5
 8    "     D T  8   J   5
    
     5

 " #
    P  # P         5
   

 
 " I
   5   " , #
# "       J   
 " 


5 "  5  "  5 8          # 
     J   "    #  1
  " 6    
  J   #
  
J
  8   P
#   D B  
   5  "   :    5  #
 "  5      "  #    " I
# " ' 
  #  
 "   8

  "
 8   J   5
     
# #  1
    " 5   G                   5     5 G 
#  5 8              5
D n "   5 J
 <  : 
   1


  P
J    "  " I
  
 " J    h
#    "    
     P
 J  "
   
 
" 5 8   5  
# " '  :
 J   " 6     
  5 G " #
5    #    '     8  1
# " , #
 
 # 
      #  "

 8  "  # " 8 "      

8

  D
 o p
q   r q r s t  u v w s u x s  
p
T 
" 5 8   5  
# " '    P
  
    
   
 1
  y  
2
A B i D
 # 
    "  " I

 8

  1
8     
   8   J   5
    " 5 " 
  

   

 " <  
 D T       5
" 5 8   5  
    G J
1

      8

 " < 5
          !  $  ^  6
  

  " <  
 
2
z  D
T  5
       h

     # 
   
8  " 5  

8

J 
8   
     J    5 8  I

<    

     J #        D y

  # 
  <    
   
   8   " J      J #         5 8  I
  
8
 " 
  
8

J 
   "

8     5
    D      
         J #        <    
   :     # 
 
   h

 5
    
5         # " '   J   " 
D T 
5
      # " J  
    # " '   J   " 
8   #


  # 
  :     # # "  
         6 
 
5    
    # " '  :     # "  : 
  5

2
   " 
 # "
5 h  " 1
5
D y
J    .

      5
      " #
5   
    #
 <
   "   " J  "    
J
           1
# 
   : 8            8   " J    
 " I
  

   #  # " '  #       " #  8   #  
   D
B

    # "      5        J #       

<    
 :   P
 "  #   8  
 
 & ! (   )  *  - 
.
 /     ) 3 / -  7 9 :   / < 9 /      #        
8  
 :
2

#  5  

    
8

  z D T 

8  
   P
 " 5 8   5  
    "       #    1

   
    # " '        J   "   
  
 " I
 1
610 Aplicaciones

    
              
 
  
    
      
            
    
       
       !       
   !     " !    
  
#   $   
     %           
    
   
 
    


      
  )   ! %    
        
-
.     "         
  
  
 !
 
             
      
      
 / !            
       !         !   !     " !    
 !
 
        
   
!    

    1 
 
      . 2 3  %           % $   %  
       5     
%  %    
. 
# # 6 $ . .  % $ & 7 8

9     !
 
        ( * ( . 
# #
; + (  ( . . + /

 
 
      
=
6 !     !    
      $  
%        !     

  
     0   
    $  !    !        
? 5 
  
    )  ! %   
            
-
. 
# # 6 $ . .  % $ & 7 8

&     !
 
            ( . 
( . 
# #
; + ( . 
# # / ; .  9 $ 5 & 6 # ( . . + /

(     !   
 !
 
             
    
 !
 
        
   
!    

    1 
 
     
. 
# # 6 $ . .  % $ & 7 8

9     !
 
        ( * ( . 
# #
; + (     ! 
 
     !     ( . . + /

 
9    %   !     
  
!             %  "   
  
!        ! 

 
!    

6 5  / !    9 
!          
 !
 
             
 
      
=
9        
  @
  %         / !  / !                
    
   

      
  )   ! %    
        
-
. 
# # 6 $ . .  % $ & 7 8

&     !
 
            ( . 
( . 
# #
; + ( . 
# # / ; .  9 $ 5 & 6 # ( . . + /

 
 
!    

6 5  / !    9 
!          
 !
 
             
=
9     $ 
       

  
       
    
   
  
A
    B 6       
     8    

    
              
 
  
  -
. 
# # 6 $ . .  % $ & 7 8

&     !
 
   %      ( * ( . 
# #
; + ( . / 9 + # & ( . . + /

 


 !
 
   %           9 + $   #
%             
  
   / !    5  ; % 2             
   
    < 

          
   !     " !     / !        1   !    
        ; / !  %  "     !  
         % $   %       %     
   
 %        


6      !      9 !   "     !
 
   %         (  ! %         (  !
 
   %      
  
6        ;    $   
 !
 
    
  
!            
   
 %        


6     ? !
 
   !
 
   
. 
# # 6 $ . .  % $ & 7 8

9     !
 
  (    
 %        

 
   .  
( . 
# #
; + ( . / 9 + # & ( . . + /

 
=
? 5 

 
A
    B 6       
     !   $ 
XVI Jornadas de Paralelismo, JP '2005 611
    

  
 
        
       
       
 
     
 
   
         


 
   
 

 

  

  
  
  

 









  
        



     
 

 
    

 
  
                
  
    
   


   
   
     
   
     
   


  
 
        
        
        
       
        



    
  
     

      



   
        
 


    
 
    
 


   

    
  

  

 
  


  


 
 

   

 

   
 
 

 
        
  
        

 

      



       



   

 
       
     $ & (
 !   

!     !     !   

  
 
        
        
        
       
      
   
    
  
     
 
     
 
   
         

 


 
  


 





  
  


  

  

 
 
 

      
  


   
 
 
 
    
 
 

  
        


 


  


  
       

    
  


   

 
*       
     + -   $ &

   /            2
 
4 6   8

 - 
8

;    
 8
>
 ;   ?

@


- 8  -  8    
8 8  D
   
   / 
    -   8  
   ;     I

@


       I
 
  >  >     4
L  8 >
    8  D

 - 8     8 -
8
  
 > -   >   
  R    

  /          - 8  >  8   /
8 W

 
      R 
-
8  

@

     
-  8      
?     
  

Z 8      2 -   8
  R  W     
8
>
;      Z
 2 -   8
       Z           
  
  

> \   >
>    8   / 
 ;   
  
  
 

      R 
  
 W           8 
  ^

- 

  I
8
>
-      ;  
 8
? _     
  ?


  8 -       > 
 8
8 
      R  W     ;   _  

-  8 \
        > -   8
8 4 b  > Z  W   >
   8 
  ? \

      
?   
> Z 2  >
  
  
> \   D
>
     
I
 
  >  >         8   


          
-  8 

 -  8       
?   4 6   

8
>

  
 ;        
?     Z  2 -   8
 
     Z           
  
  
> \   >
>  D
  8   / 

  
  
  
          - 

  I
8
>
W -      ;   -  8   

@

  ?

  8
-       > 
 8
8 
      R  ;   -       >
  D
 8  W     ;   _  
-  8 \
        > -   8
8 4
 d
e f g h j  k l g n l o  h
j  n p l r  f g
&
8
    
8     > -  8 
>       
  > -   D
>   
      -
8
  
   I
         
  
  
        
  
  - 8     >
      D
      ?
  8   
n @
M
4   
>  8  > \   > 
  8 8  8  
  8 8  /  8          
     
   4     
L  8 >
W   -   

  ^
8 
 t D
     
 
  > -   >   
      -
8
   
 D
 
         > -  
   
 > 
@
 L  8     4
   2 -  8  >        I
 8 
  ^
    8   

+ 8  /   * u v v ;     -      v - 8    
 8  
$ ( & 6    v v v
v v $  ^ W    8          v
      - 8    
 8   

   W      
 >  >  8 
-  8 - 8    
 8
@
 v u v       
 8  4


 
 >     8
     > -   
   D
  R 
@
  
>  8         > -  
  -
8

 
 /  8   >         
  > -   >   
  8   
D
>       z
@
  /    8
 -  8     ;      
     
4   ?
  8   8     
   >  
8   W -  8  
;          
@
 ;       ;            8    
   /  
   8  
8 /
    
         
 4
612 Aplicaciones



D  
 
E           
           
#
$  ' ) * '  - .   '    ) ' . 4
5 '  4 5 4  ' 8 :  4 .  5 4 
#
 4  - = ' ) : 4  5 ' ' A ' B * B = C 
4  - '  = 5 4  :  .    = ) :  ' ) '  -  B = C  B 4  K M N
#
O : '  K M ' ) :  '   5 4  R  R S
#
 : . 4 B '   5 4 . ' 
4 U =  4  V  C - '  ' X * ' '    ) ' . 4 5 '  4 5 4  Z '  ' [
.  5 4  :  .     ' A ' B * B = 4  '   ' B * '  B =   ' 
#
 * 
B 4 . . '  : 4  5 = '  - '  :  .   '    '  '  ) =  ) 4 V   - 4
4 B * . . ' : 4 . X * ' '   )  4  B   4  R :  .  Z  .   - = ^  .
  4  - '  B = C  5 '    4  * B = C  ' 8  B -  R '   ' B '   [
. = 4     = ^  . - 4 5 4   4   *  : . 4   ' )   : 4  =   '  R
 *  X * ' : 4  - ' . = 4 . ) '  - '  ' . '   = B '  : 4 5    - '  [
5 = '  5 4   4  :  . f ) ' - . 4  B 4 ) '  -  5 4  '  : f . .  [
h 4    - ' . = 4 . '  V
   = Z * .   ) * '  - .     Z . f m B   5 '   
 B '  ' .  B = 4  '  4  - '  = 5   R . '  : ' B - 4    ' A ' B * [
B = C   ' B * '  B =   R :  .     = ) :  ' ) '  -  B = 4  '  ' 
O : '  K M 

#
K M N 
V     B '  ' .  B = 4  '  :  [
.  K M N : . '  '  -   *  ) ' A 4 . B 4 ) : 4 . -  ) = '  - 4
X * '    5 ' O : '  K M V   - 4 5 4   4  : . 4   ' )  
 4  '  4 Z .  ) ' A 4 .  . '  - = ' ) : 4  ' B * '  B =   R : ' [
. 4  4 4 B * . . '    4 )   t   B 4 ) 4 '  '  B   4 5 '
O : '  K M R X * ' B 4  '  : . 4   ' )  N    R K    P
: . '  '  -  *  B   4 5 '  * : ' .  =  '   = 5  5 V u ' U  5 '
- '  ' . '  B * '  -  X * '  ' U  = ) :  ' ) '  -  5 4 * 
'  X * ' )  5 '   ) = m B  B = C 
#
w B 4 -  B = C 
#
4 B * [
. . ' X * ' :  .  '  - ' : . 4   ' )  '  B 4  B . ' - 4 R *  4
5 '  4  U =  4  '  B * '  - .     4  * B = C   =  - '  ' . X * '
. ' B 4 . . ' . - 4 5 4 '  f .  4  R B 4   4 X * ' -  . 5  ) * B U 4
) '  4  X * '   ' A ' B * B = C   ' B * '  B =   V
   = Z * .   ) * '  - .     Z . f m B   5 '    ) ' [
. 4 5 '  4 5 4  B 4 ) : *
-  5 4  : 4 . : . 4 B '   5 4 . 5 '   
= ) :  ' ) '  -  B = 4  '  '  O : '  K M 

#
K M N 

:  .  '  : . 4   ' )  N    $ R K   P V    )  4  B  [
 4  U 
#
*    * '   5 =  - . =  * B = C  5 '   B  . Z  5 '
- .    A 4 '  - . '  4  U =  4  4 : . 4 B '   5 4 . '  V  C - '  '
X * ' '  '  B   4 5 '   = ) :  ' ) '  -  B = C  '  K M N
  5 =  - . =  * B = C  5 '  4 5 4   ' . '   = ^  '  - . '  4 
'  B   x 4  R
#
 X * ' '  )  '  - . 4   = B  ) '  - '  ' '  [
B  . Z  5 '  . ' :  . - 4 5 '    -  . '   V   '  B   4 5 '
O : '  K M '  )  '  - . 4 : * ' 5 '   ' Z  .  B 4 ) : * -  .
  Z    4 5 4 V

z 
{ | }   €  { | ‚ €
  '  - ' - .    A 4  ' U  : . '  '  -  5 4   = ) :  ' ) '  [
-  B = C  5 ' 5 4    Z 4 . = - ) 4  :  .   '  4  :  .    . ' [
 4  * B = C  5 '  : . 4   ' )  5 '  ƒ C 5 = Z 4 ƒ 4 . . ' B - 4 . 5 '
 . . 4 . '  R B 4  B . ' -  ) '  - ' :  .  B C 5 = Z 4  5 '   4 [
X * ' V w )    : . 4 : * '  -   '  - f      5   '   
- „ B  = B  5 '   ) = m B  B = C 
#
w B 4 -  B = C  V   : . =  [
B = :    : 4 . -  B = C  5 '    ) =  )   B 4   =  - ' '  X * '
 '  *  B     4  * B = C  ' 8  B -  * - =  = ^   5 4 '  X * ' [
)   5 ' :  .   '  = ^  B = C  V  4  . '  *  -  5 4  B 4 ) : * [
-  B = 4    '  4  - '  = 5 4  ) * '  - .   X * '    = ) :  ' [
) '  -  B = 4  '  B 4  K M N - = '  '  *  ) ' A 4 . B 4 ) [
: 4 . -  ) = '  - 4 X * '    5 ' O : '  K M V
 4  . ' B 4 . . = 5 4  5 '  f .  4  5 '    X * ' 5  5 '  ) [
   = ) :  ' ) '  -  B = 4  '   4  '  : . 4 h *  5 = 5  5 V w B [
- *   ) '  - ' R  ' '  - f - .    A   5 4 '  *   = ) :  ' [
) '  -  B = C  5 ' *      X * ' 5  : . = ) ' . 4 [ '  [ ) ' A 4 . V
XVI Jornadas de Paralelismo, JP '2005 613



D  
 
E         
    
 " $ & ) "  , ) & . / 0 ) " . 0 3 $ 0 $ 5 /  7 ) " 9 ) 0 ;
3 $ /  0 $ 5 / $ 3 ) & /   $ " " $ 3 & $ A $ $ & $  . B  & $ 5 E 5
F E / E & ) $ H 3 $ & . 0 $ 5 / ) " $ 5 ) / & ) / . 3 ) 7 $ 0 N O E . 5  " Q
R ) 5 9 & $ /  0 $ 5 / $ " $ V  3 $ 5 "  7 ) $ 5 E 5 0 E / . 3 & ) ;
9 $ "  7 ) &
X
$ 5 E 5 9 E " / $ & 7 $ ) & 7 $ 5  7 ) & $ " Q
 [ 
\
^ _ ` a c a _ d f g i
j " / $ / &    k ) V  " . 7 ) " E  A $ 5 9 . ) 5  7 ) 9 ) 5 F ) 5 ;
7 ) " 
      
X
3 ) & $ n . 5 . " / $ & . ) 7 $ R . $ 5 ;
9 . 
X
 $ 9 5 ) ) , o  $ 5 $ 0  & 9 ) 7 $  r  5   ;
9 . ) 5  7 $       9 ) 5 $ 3 & )
X
$ 9 / ) 5  0 $ & )


 ! !  # ! % % & ( # + ! - # ! - Q   0  . u 5 V  9 ) 5 / & . ;
 E . 7 ) $  )  . $ & 5 ) 7 $ R  5  & .  " 9 ) 5 $ 3 & )
X
$ 9 / )
w x D y / / z 1 / y y
Q j / &    k ) 7 $  Q n . &  5 7  " $ V 
7 $ "  & & )  7 ) 9 ) 5   $ 9   r  ;  r ;  } }  ;    } Q
  0  . u 5 O E $ & $ 0 ) "  , &  7 $ 9 $ &  R  j n   $
E " ) 7 $ " E " 0 N O E . 5  " Q
 _ 3 _ \ _ d ` a
i

   ƒ j Q ƒ R V . 9  5 ) ƒ 4 Q  Q ƒ
      5      
6
       
6
   8       9   5 8      ; = "
    ;  #   $    $ ƒ r & ) 9 $ $ 7 . 5 , " ) F / V $  R n
"
X
0 3 ) " . E 0 ) 5  3 3 . $ 7 9 ) 0 3 E / . 5 , ƒ  †  ?
 †  ƒ  } } 
 
   ƒ j Q ƒ $ /  Q ƒ @ A B B C A E G  9   $
6
  "
       J K     M    O     = Q  
*
  "
  K 5     = T  $     #   
= $    $ ƒ  9 /  " 7 $
 " V   4 ) & 5  7  " 7 $ r  &  $ . " 0 ) ƒ }  ? } ƒ
 } } Q
 ‡
Y &  " "  & 7 ƒ  Q ƒ Y &  / $
X
ƒ r Q ƒ Z # 
    $  
-         ƒ r & $ 5 / . 9 $   ƒ   
 
R ) / /  ƒ R Q ƒ
    
   5  /       - K "
K    5  $    5      
6
       
6
   8   "
    ƒ  $ 9 / E & $  ) / $ " . 5 R ) 0 3 E / $ & Š 9 . $ 5 9 $
‡ } }  ƒ  ?  } ƒ  } } 
 
 . ƒ  Q ƒ - Z   $ 
6
 #  $  
6
    G 5    = ƒ
‹ H F ) & 7  3 3 . $ 7 0  / V $ 0  / . 9 "  5 7 9 ) 0 3 E ;
/ . 5 , " 9 . $ 5 9 $ " $ & . $ " ƒ  † 
 
n . &  5 7  ƒ  Q ƒ  $  5 ƒ R Q ƒ  $ ] #      $ K  -  "
       $ - ` ƒ  3 / ) Q 7 $ j " /  7 o " / . 9  ƒ  Q ‹ Q
X
R ) 0 3 E /  9 .  5 ƒ  5 . A $ & " . 7  7 7 $     , E 5  ƒ
  ;  j  ‹ R ; }  ; }  ƒ  } }  Q
 
n ) & $ ) " ; a  &  , ) B  ƒ  Q ƒ G 5     Q        "
            ƒ c . $
X
ƒ  } } 
 †
‹ 3 $ 5 n r  & 9 V . / $ 9 / E & $  $ A . $ e Y )  & 7 ƒ
J K  / 8
6

6 f f
- K K    "
   8      h    Q   ƒ j $ & " . ) 5 Q } ƒ
V / / 3  k k e e e Q ) 3 $ 5 0 3 Q ) & , ƒ   † Q
 
Š 5 . & ƒ n Q ƒ ‹ / / ) ƒ Š Q c Q ƒ  E " " ;  $ 7 $ & 0  5 ƒ Š Q ƒ
c  n $ & ƒ  Q c Q ƒ  ) 5 ,  & &  ƒ 4 Q 4 Q ƒ / 8 h E G 5 
6
  K     q  Q      ƒ  V $ n   r & $ " " ƒ    Q
614 Aplicaciones
                            " $     "  "    $ *  -   .   " 1
2 3 4 6 8 : < > ? A B C 3 E F G I J B K 3 C F N O B 4 3 P 6 R R J U W 3 X N > Y
Z [ \ ] _ a c ] _ e f g \ h e \ a j k m o p e ] p
q h e r o p [ e f a f v o w _ o e v a
y a k | o ~ ~  € 
‚ ƒ „ „ …
w _ o e v a
† ‡ ˆ ‰ Š ‹ Œ Ž  ‡ ˆ ‰ ˆ Œ Ž  ‹  Œ ’ ˆ  “ ˆ Œ ‡ ‹ ‡ ”  • – — ˜ ‡ ™ › “ œ ™ — ‡
 Ÿ   ¡ ¢ Ÿ ¤
¥ ¦ § ¨ © ª ¬ ­ ª ¯ © ª ­ ° ­ ± © ª ¬ ³ µ ¶ ° ­ · ¹ ° ³ § º © ¶ © » ¼ ¹ ¬ ³
¦ ª © § © ° ­ ¬ ­ ¹ º © º ³ § ³ ª ­ ° ¹ º ­ º § © ¿ ¯ © ¿ ¹ ¿ ª ­ ª ° ³ · ¹ ª
§ ¿ ­ ¯ ° © » ¿ Á Â § © ª Ä ¹ ª ³ ¹ ¯ ¹ ¿ ¹ ¹ ¦ ° ³ º ° ­ Â § ¹ ¿ ¹ ¹ ¶ Æ
» ¦ ­ ³ º © ¯ ¹ ¿ ¹ § ­ Ç ¿ ¹ ¿ · ³ º ª ¹ Ê ³ ª ¹ ³ º ± ­ ¹ ¿ Ë Ì ­ º ³ · Æ
Î
¹ ¿ » © Ï ³ ª ° © ª · ³ § ¹ º ­ ª · © ª ° ­ ³ º ³ º ¹ ¶ » ¦ º ¹ ª § ¹ Æ
¿ ³ º § ­ ¹ ª Ñ ¦ ³ ¨ ¹ § ³ º Ñ ¦ ³ º © ª ³ ¹ ¯ © ª ­
Î
¶ ³ ³ ¶ ¦ ª ©
¬ ³ ¶ ¹ § ¿ ­ ¯ ° © » ¿ ¹ Ç ¼ ¹ § © º ± ³ º § ­ © º ¹ ¶ Ä ª ³ ¹ ¿ ³ § © · ³ º Æ
¬ ¹
Î
¶ ³ ¿ ³ § ¦ ¿ ¿ ­ ¿ ¹ ¶ ¦ ª © ¬ ³ § ¦ ¿ ± ¹ ª ³ ¶ ¼ ¯ ° ­ § ¹ ª Ë Ô º
³ ª ° ¹ ª ­ ° ¦ ¹ § ­ Õ º ¿ ³ ª ¦ ¶ ° ¹ ­ · ¯ ¿ ³ ª § ­ º ¬ ­
Î
¶ ³ ¬ ­ ª ¯ © º ³ ¿
¬ ³ ¹ ¶ » µ º · ³ § ¹ º ­ ª · © Ñ ¦ ³ ¯ ³ ¿ · ­ ° ¹ ¬ ³ ° ³ ¿ · ­ º ¹ ¿
Ç Á § ­ ¶ · ³ º ° ³ § ¦ ¿ ± ¹ ª ³ ¶ ¼ ¯ ° ­ § ¹ ª § ¿ ­ ¯ ° © » ¿ Á Â § ¹ · ³ º ° ³
µ ° ­ ¶ ³ ª Ë Ø ¹ ¿ ¹ ³ ¶ ¶ © ¿ ³ ª ¦ ¶ ° ¹ · ¦ Ä ± ³ º ° ¹ Ê © ª © § © º © Æ
§ ³ ¿ ¶ ¹ ³ ª ° ¿ ¦ § ° ¦ ¿ ¹ ¬ ³ ¦ º » ¿ ¹ Ç © ± © ¶ § Á º ¬ ³ § ¦ ¿ ± ¹ ª
³ ¶ ¼ ¯ ° ­ § ¹ ª Ë Ô ¶ ¯ ¿ ©
Î
¶ ³ · ¹ Ñ ¦ ³ ³ º § © º ° ¿ ¹ · © ª § ¦ ¹ º Æ
¬ © ª ³ § © · ¯ ¦ ° ¹ ³ ¶ ¿ ³ § © ¿ ¿ ­ ¬ © ¬ ³ ¶ ± © ¶ § Á º ³ ª Ñ ¦ ³
¶ © ª § Á ¶ § ¦ ¶ © ª ª © º · ¦ Ä § © ª ° © ª © ª Ë Ô º ³ ª ° ³ ° ¿ ¹
Î
¹ Ê ©
ª ³ ¯ ¿ © ¯ © º ³ ¦ º ¹ ¹ ¯ ¶ ­ § ¹ § ­ Õ º ¯ ¹ ¿ ¹ ¶ ³ ¶ ¹ ¬ ³ ¯ ¹ ª © ¬ ³
· ³ º ª ¹ Ê ³ ª ¯ ¹ ¿ ¹ ³ ¶ § Á ¶ § ¦ ¶ © ¬ ³ » ¿ ¹ Ç © ª ± © ¶ § Á º Ë Ú © ª
¿ ³ ª ¦ ¶ ° ¹ ¬ © ª ³ Û ¯ ³ ¿ ­ · ³ º ° ¹ ¶ ³ ª · ¦ ³ ª ° ¿ ¹ º ¶ © ª
Î
³ º ³ Æ
 § ­ © ª ©
Î
° ³ º ­ ¬ © ª ³ º ³ ¶ Ý Þ ß ß à á Þ ¹ ¶ ³ Ê ³ § ¦ ° ¹ ¿ ¶ ¹
¹ ¯ ¶ ­ § ¹ § ­ Õ º ³ º ¦ º § ¶ ¦ ª ° ³ ¿ ¬ ³ ³ ª ° ¹ § ­ © º ³ ª ¬ ³ ° ¿ ¹ Æ
Î
¹ Ê © ¯ ¹ ¿ ¹ ¶ ¹ » ³ º ³ ¿ ¹ § ­ Õ º ¬ ³ » ¿ ¹ Ç © ª ± © ¶ § Á º ¬ ³
¬ ­ ª ° ­ º ° ¹ ª § ¹ ¿ ¹ § ° ³ ¿ ¼ ª ° ­ § ¹ ª Ë
ã ä æ
¤ ç è é ê ¡ ë ë ì î ¤
Ú © ª ª ­ ª ° ³ · ¹ ª § ¿ ­ ¯ ° © » ¿ Á Â § © ª Ï ³ º ³ ª ° © ª ¬ ¼ ¹ ª Ï ª © º
¦ º ¹ ¨ ³ ¿ ¿ ¹ · ­ ³ º ° ¹ · ¦ Ä ¦ ª ¹ ¬ ¹ ¯ ¹ ¿ ¹ » ¹ ¿ ¹ º ° ­ ï ¹ ¿ ¶ ¹
§ © º Â ¬ ³ º § ­ ¹ ¶ ­ ¬ ¹ ¬ Ï ¹ ¦ ° ³ º ° ­ § ­ ¬ ¹ ¬ Ï ­ º ° ³ » ¿ ­ ¬ ¹ ¬ Ä º ©
¿ ³ ¯ ¦ ¬ ­ © ³ º ¶ ¹ ª § © · ¦ º ­ § ¹ § ­ © º ³ ª Ë
ð ñ ò ó ô ó õ ÷ ø ÷ ù ú ô ò ó û ò ü ø ý ô þ ÿ
ú þ ÷  ú  ú õ ô   õ ú  ô ÿ ó ú
          
 ô  



Ô º ³ ¶ ¦ ª © § © ° ­ ¬ ­ ¹ º © Ï § ¹ ¬ ¹ ± ³ ï ª © º · Á ª ¶ © ª ¬ ­ ª Æ
¯ ©
ª ­ ° ­ ± © ª Ñ ¦ ³ ­ º § © ¿ ¯ © ¿ ¹ º Ç ¦ º § ­ © º ¹ ¶ ­ ¬ ¹ ¬ ³ ª § ¿ ­ ¯ Æ
° © » ¿ Á Â § ¹ ª Ë Ô Ê ³ · ¯ ¶ © ª ¬ ³ ³ ª ° © ª ¬ ­ ª ¯ © ª ­ ° ­ ± © ª ª © º
¶ ¹ ª  " # %  # ( ß ) )  % + à ) Ï ) - % + #  % + à ) © ¬ ­ ª ¯ © ª ­ ° ­ Æ
± © ª § © º § © · ¦ º ­ § ¹ § ­ © º ³ ª · Õ ± ­ ¶ ³ ª 1 2 Ï 4 6 Ë Ô ª ° ³ ° ­ Æ
¯ © ¬ ³ ¬ ­ ª ¯ © ª ­ ° ­ ± © ª ° ­ ³ º ³ º Ñ ¦ ³ ³ º ± ­ ¹ ¿ § ¶ ¹ ± ³ ª § © ¿ Æ
° ¹ ª ¯ ¹ ¿ ¹ Ñ ¦ ³ ¶ ¹ ¿ ³ § ³ ¯ § ­ Õ º Ä ¹ ¦ ° ³ º ° ­ § ¹ § ­ Õ º ª ³ ¹ º
¿ Á ¯ ­ ¬ ¹ ª Ë 7 ³ ¶ ¶ © ° ³ º ³ · © ª Ñ ¦ ³ ¹ 8 ¹ ¬ ­ ¿ ¶ ¹ ª ¿ ³ ª ° ¿ ­ § Æ
§ ­ © º ³ ª § © º ¿ ³ ª ¯ ³ § ° © ¹ ¶ ³ ª ¯ ¹ § ­ © ¬ ³ · ³ · © ¿ ­ ¹ Ï ¶ ¹
§ ¹ ¯ ¹ § ­ ¬ ¹ ¬ ¬ ³ § Õ · ¯ ¦ ° © Ä ³ ¶ ¹ º § ¨ © ¬ ³
Î
¹ º ¬ ¹ Ñ ¦ ³
³ ª ° © ª ¬ ­ ª ¯ © ª ­ ° ­ ± © ª ¯ ¿ ³ ª ³ º ° ¹ º Ë 7 ª ¼ · ­ ª · © Ï © ° ¿ ©
¯ ¿ ©
Î
¶ ³ · ¹ ¹ ¹ Ç ¿ © º ° ¹ ¿ ³ ª ³ ¶ ¨ ³ § ¨ © Ñ ¦ ³ ª ³ ¬ ³
Î
³
§ ¹ ·
Î
­ ¹ ¿ Ç ¿ ³ § ¦ ³ º ° ³ · ³ º ° ³ ¶ ¹ § ¶ ¹ ± ³ ¯ ¹ ¿ ¹ ¯ ¿ ³ ± ³ º ­ ¿
Ñ ¦ ³ © ° ¿ ¹ ª ¯ ³ ¿ ª © º ¹ ª ¶ ¹ ¯ ¦ ³ ¬ ¹ º ©
Î
° ³ º ³ ¿ Ä ¨ ¹ § ³ ¿
¦ º ¦ ª © Ç ¿ ¹ ¦ ¬ ¦ ¶ ³ º ° © Ë
: ¹ ¶ ³ ª ¯ ¿ ©
Î
¶ ³ · ¹ ª ª ³ ¯ ¦ ³ ¬ ³ º ¿ ³ ª © ¶ ± ³ ¿ · ³ ¬ ­ ¹ º Æ
° ³ ³ ¶ ¦ ª © ¬ ³ ¶ ¹ ª § ¦ ¿ ± ¹ ª ³ ¶ ¼ ¯ ° ­ § ¹ ª Ï ¦ º ¹ ¬ ³ ¶ ¹ ª
° ³ º ¬ ³ º § ­ ¹ ª § © º · Á ª ¹ ¦ » ³ ¬ ³ º ° ¿ © ¬ ³ ³ ª ° ³ § ¹ · Æ
¯ © ¬ ³ ¶ ¹ § ¿ ­ ¯ ° © » ¿ ¹ Ç ¼ ¹ 1 < Ï > Ï ? 6 Ë @ ª ° © ³ ª ¬ ³
Î
­ ¬ © ¹
Ñ ¦ ³ ¶ ¹ ª ° A § º ­ § ¹ ª § ¿ ­ ¯ ° © » ¿ Á Â § ¹ ª
Î
¹ ª ¹ ¬ ¹ ª ³ º ¶ ¹ ª
§ ¦ ¿ ± ¹ ª ³ ¶ ¼ ¯ ° ­ § ¹ ª ¯ ³ ¿ · ­ ° ³ º ¦ ª ¹ ¿ § ¶ ¹ ± ³ ª ¬ ³ ° ¹ · ¹ Æ
8 © · ¦ § ¨ © · ³ º © ¿ B § ¶ ¹ ± ³ ª ¬ ³ < 4 D
Î
­ ° ª Ï Ç ¿ ³ º ° ³ ¹
< D 2 >
Î
­ ° ª ³ º § ¿ ­ ¯ ° © » ¿ ¹ Ç ¼ ¹ § © º ± ³ º § ­ © º ¹ ¶ G ¹ ¯ © ¿ Æ
° ¹ º ¬ © ­ » ¦ ¹ ¶ ª ³ » ¦ ¿ ­ ¬ ¹ ¬ Ë
7 ¨ © ¿ ¹
Î
­ ³ º Ï § ¹
Î
³ ° ³ º ³ ¿ ³ º § ¦ ³ º ° ¹ Ñ ¦ ³ º © ° © Æ
¬ ¹ ª ¶ ¹ ª ¯ © ª ­
Î
¶ ³ ª § ¦ ¿ ± ¹ ª ³ ¶ ¼ ¯ ° ­ § ¹ ª ª © º § ¿ ­ ¯ ° © » ¿ Á Æ
 § ¹ · ³ º ° ³ ª ³ » ¦ ¿ ¹ ª Ï § © º ¶ © Ñ ¦ ³ ³ ª
Î
¦ ³ º © ª ¹
Î
³ ¿
§ ¦ ¹ ¶ ³ ª ª © º ¹ ¯ ¿ © ¯ ­ ¹ ¬ ¹ ª ¯ ¹ ¿ ¹ ¦ ª © § ¿ ­ ¯ ° © » ¿ Á Â § © Ä
§ ¦ ¹ ¶ ³ ª º © Ë Ø ¹ ¿ ¹ ³ ¶ ¶ © ¿ ³ ª ¦ ¶ ° ¹ µ ° ­ ¶ ° ³ º ³ ¿ ¶ ¹ ª § ¶ ¹ ª ­ Æ
 § ¹ ¬ ¹ ª ª ³ » µ º ¶ ¹ ª ³ » ¦ ¿ ­ ¬ ¹ ¬ Ä ¯ ¿ © ¯ ­ ³ ¬ ¹ ¬ ³ ª § ¿ ­ ¯ Æ
° © » ¿ Á Â § ¹ ª Ñ ¦ ³ ¯ ¿ © ¯ © ¿ § ­ © º ¹ § ¹ ¬ ¹ ¦ º ¹ ¬ ³ ³ ¶ ¶ ¹ ª Ë
H º ¹ ³ ª ° ¿ ¦ § ° ¦ ¿ ¹ Ñ ¦ ³ º © ª ¯ ³ ¿ · ­ ° ³ § ¶ ¹ ª ­ Â § ¹ ¿ ¶ ¹ ª
§ ¦ ¿ ± ¹ ª ¬ ³ ¯ ³ º ¬ ­ ³ º ¬ © ¬ ³ ¶ ¹ ª ¯ ¿ © ¯ ­ ³ ¬ ¹ ¬ ³ ª § ¿ ­ ¯ ° © Æ
» ¿ Á Â § ¹ ª Ñ ¦ ³ © Ç ¿ ³ § ³ º ³ ª ¦ º » ¿ ¹ Ç © ¬ ³ º © · ­ º ¹ ¬ ©
I
(  J " 1 L 6 Ë


 


            
   !   

$

        
    !      ! 
+  , -       
  0
     ! 2  
 
  ,    4 

  
 




   
     
         
     !     
0
!
  
 

+   !    ?
@ ! 

$
  +
   
       ! 2  

  
 0
       
   H 
 
   
     !
   
 0

J 
$
   

  
 
4 

  2   
 4 



$

 
  ! O   
           
 

 
0
 ! 
 
 


 


 
    
 


S  0 !  
  ! 
 ? U  
J
 J

 J  
 !   

  W 
         
 ! O   ! 2  
 

$

  
 0
  ! 
?
U 
 
      



    
    
+ !  

   
 ! O   ! 2  
 

$

  
+

   ! 2  


   
     
 
 
 !    !
$
 ! 

$
   


     ! +   
 


   `
 ? a
 !   0

 
c
 ! 
    ! 2 
       


$

   0

 4 




$


   g h i i j k h 
 , 


?  
   +  
   
 ?
U  
 

   
$
 `


         

 ! 0
+ 
? U    
  ! 2   
!   
   !  ,
$



 


 
 



  ,  
     
   !       


   


 
 H 
!
  
 ? U   

  ! 2   

c

 
    
+ !  
   
 ! 0
O   ! 2  4 

J  
+  ! 
     +

   ! 2 

+   W
  !

  ,  ? U    
  ! 2  




 
     
 4 

J  

$

 ! 

    ,  0
 !    
`
         !    ! 2     
  
  
    
 ?  !    ! O  

 
    
     !

 H
  
$
 `
 W    
 ?
 q
r  t u v w
U 
 
     


c

 
         


  ,  `   

     !   !  
      
    !   
H    
!
  
    ?
 
   ! 

l
 
-  ! 

  
l
0 
  ,  


  +   W
4 

  !

  x  ! 
 !  
  
4 
     

    i  H 
 

    
0



 
 !  

 

l − 1
, 
$



l
0   !
 ?
y   J
`   

 
 , 
$


 
 ,  
4 


0
  
 


   i   

l
0 
  ,   !
     4 


 
 



 
    , 
$

 
 - +      
  j i  

l
0 
  ,  ?

   



l
0 
  ,   !
0


l + 1
  !     ? @



  
         

 
l
0 
  , 
   - +     ?
y
 

 

 
+   W



       


     
   !    

$

   !  
 

- 0
 {  | } ~
  
€  ‚  ƒ 
 ! 

p
 

p
 ! 
?        
   !  
  ,
W
    
 

  4 
 
   
 
  W
 0
 
P = (x, y) ∈

p

p
4 
   !  W  
   

    ! 2  
  !

y2
= x3
+ ax + b,


a, b ∈

p
H    4 

  !    !  !    

∆ = −16(27b2
+4a3
)

 
  
   4 


 +    
  !  +    0

 ?
y  
+   !      ! 
+  , -   
       
  0
 !  
  ,  ! 
   
 

   !
    

  x 0



  
 
         

 !   
 
j "    
       ?

J
 J
  
         

l
0 
  ,   !


     !      !    
4 

            

   

  !


  !  
    !    ?    4 

 ! 
 !

        4 
     
 
4  ! 0
 ! 
 

 
 

$


+   !      ! 
+  , -   

 !
 



 

l
0 
  ,  
!  , 

$

0
 !
 

          4 

 +       !    
    !   
 
      
 ! + !    ?
U  +

   
 +   W

l
0 
  , 
   J    


 
4 
 !
     4 
    
  

l
0 
  , 

 


  ! 

 
 
 !      !      ! 
 0
 
  

4 

 


   , 
 H   


4 

 


  


  
    
 
 !  W
 !

  " 


 4 

 
    
   , 
  !
0

  +     x 




 ? U        4 


   
   !    !

   ! 
+  , -    


 
+    
 
 !  

 


    ?
#
         
  
+      !  !     ! 


616 Aplicaciones
                          
l
"
#  &                      0      "
#  4  7      4 8    4 9 ;     
?
      4 
            4   4  4         4  4      4   
 4  4           &     H    4         J
       4     4  4    L      4  4  &   "
4  H     & 4  &   
     Q  4   4

?
   4    4     
?
 S      U    0  
       H          Q    X  
?
"
       4  4    #  4  7      4  #  &  
H     &    J 4      9
 [ 
\
^
_  a _ b d f ^
 \ g

^ h
i   4   4     0  4   m      4            "
    U    0  4                 J     "
    0      H #  &  9
r         0           4  4     H
#  &   4          4    4        
9 ;                    Q    
4   4     4  4       0          "
H Q  4      L  4         &    9


 4  4 
?
       
?
          # "
 &  9
 9               &    9
 9 i m      0    4 4 & 
?
 4    "
   9
    U      &     4                 "
       4      
?
     4
l
" #     4
    4         4 4    4   4       9 t  
 
?
   Q           &    J  4     
 4    4  4 & 
?
 4  4           "
    4         &            4
  4
L   L       #      #   4  
          9  
?
   Q        U    0 
   4  L   #    
?
         0   H   "
  8           4       4    &    J 
       4      #       9


?
  4        
  &    4  4  J       4        
    4    J  4  4 4 Q    4    
    4       &      7   4      "
 4      4    
l = 2
   4    0    
        
l2−1
2
        X   
p
   
l > 2
9
             ! "  "  $  
i            4  L   4       "
                 4     4  S  4 w ; '
 (  Q 
 4             0  r  w 9 9 r   4    "
            U    0  4      4 
?
 4    
      4 
   y 
*   , y         #   L  "
            4    m       H      
     4 9
i       4                   "
   4  4      
?
      4  4 
  &    J  H                       
& 
?
                   
 4  4  4 9 ;     Q         0    4   
4    4    4       4 4         4  .  0     
 & 4     
M
          H           

?
          0  Q . 2 0        &     
i
C

        4  4    &    J Q .  0     
     
j
L
          4  4      
    H #  &  9 i 4   4      4         
 4                   0      4    
   X      9

 4     
?
4   #   
       0    4             & 4    
M
Q
4      4   &    
i
C
J
n
     4     
j
L
9
r           0           4      4
4   H       & 4                & 4    9 
         0  4   m     H         
         4 9
T T
C C
1 2
TM
T T T
L L L
1 2 n
 €  ‚ ƒ
„  5
‚ ƒ 6 … † ‡ ˆ ƒ ‚ ‡ ƒ ‰ 
XVI Jornadas de Paralelismo, JP '2005 617


   


M
   
           
 

 
   #  $ %        
  - .   /  
  1 $  
 $  5  %   $ 8   #       
   .   .  >
    @      $
A
$ 
     
1
 -         
# 
  % $  %   #     % #    .  
   5 
  

  $ . %   % L   .   
#   L   8  $ 
O L       #    
 .     
M

                    
  !       $        % '
i
C
  !       $    (    % '
j
L
            (          -     ( 
   .      0 1       (   %    3  
     3   5 5 '
i
C
  !       (         % '
j
L
   
8
         (  
$   
$         
  !     ;        <  % '
i
C
        '
j
L
   !  
   .      0 1       (   % '
j
L
8
         (  
$         
  !     ;        <  % '
j
L
;  
  
   
 ? A
P Q S P C  T U S Q E
A
M F

    .  
  $ . %   # L    1    % 
M
 % # $  Z    1 $   
 $  5  %   $ 8  
  .     
  - .   @
        #   . $ 1  %   .  #    O L 
 % $      
 8 % # L .   #   . $     O L `  
  .     L   $ .     $ 8   
 O L   %   $  
O L    1      $
A
$        
  - .   /   . 
  1       1 $    
  .     
     #   
O L   % # L .   
- 
A

O L  #          
      1  Z 
     $   
  - .    
l  
$ Z   /
 .     % -  .     . $  n     . 
      .  
     
 L
    

     
 

   
  
i
C
   #   . $       >
  / 
     $   
  - .     
A
        $ >
    $             $ Z O L $       
A
$   

    .  % #
 n  $   %   . 
      $ 8     
.        - .    
1
C
@ 
2
C



A
    .     O L  

 -
 L
          #      
  .   $  / # 

.   .
      $ 8    % -  .        - .   
 #  .   `   $   n 
A
   l  $    
#   L   8  $ >
  

  $ . %    1   %     .     
i
C
 
 L
     1  Z        
  - .   @
   >
1 `  
 .     % -  .   
   .      $        % '
M
          $        <   '
i
C
   
n
    
1 H 200
  (  5 I  1     1  !     ( 
8
         (  %   0 1       (  
$     
  !       0 1       (   % '
M
$         
;  
  
   
L ? A
P Q S P N Q  U S Q E
A
i
C F

    .          #  .   #   
 L
 
 $         #  O L  .        $   .  #   
 .   
  #
$    $ 8    L       L
  $   
    L    #        u   L .      L    .  

L  .   / . 
 %   1   -   
 #   .    
 v #   $ %   .   $ 8   x L   . O L  
  - .     L 
 $ 
/ 
#            $   
  - .     
A
 >
 -  L     %
A
  .      
1
C
@ 
2
C
    L   
      $  /  L      @    
 L
  
 n   
 % n      .   $ . L   $ 8     -   .   .    # 

.     
M
/    L @      . $ 1   -
 l  
$ Z   $ 8 
 
  .      
i
C

 

 {
  
j
L
 

   #  O L  .      >
 $   .      
  - .       1 `   L   .    

     
j
L
/ O L   
 L
 
- 
A

     O L 
#              
#  O L  .     $
A
$     
1  Z  
 L
  
    $   .  - 
A

  /   %   >
    
M
 

  $ . % ! % L   .   
#   L  >
 8  $  O L       #     L   .     
j
L

   .      $    (    % '
M
          $        <   '
j
L
   .      (         % '
M
     (    ( 
∈
  (        
I      1      .     ( 
$     
  !       .    % '
M
$         
;  
  
   
 ? A
P Q S P | P } S Q P E
A
j
L F

~       -  1   $   .     
     
j
L
   

 #   .      v #   $ %   .   $ 8    1   -
 $  >
T
L    $   
 n %     .     
      €  .    
618 Aplicaciones
M
    
 
   
          
 
   %

&  & &   &  
-
&     

 
  0 &    3
    5 & 
 &
   0
 
9 
  :
     
 
%
 

j
L
>
@
A C D E G  H I D C   C L M O C Q G  C D
S    
         W      
  &       
&   Y %
W    [   
   &
-
    & 
  ]    
 

W   
%
    W

  
      &  0 &  
   3 W

 
 &  ]    &  b 
c &  0 &          
 

   %
 f    
 > S       [
     :
& W


  ]      & %
  
  &              & &  3 &   

 & &  &   

   W  &   
&  i      [ & 

 
:  &  

 [  [ &  
  k > l
  
      &   Y          & &     



-

-
  S  %
     >
l

W   
        
W

    :
& b    

b 
c &      W &  

      & &   &   & & 

      
   
  Y   W  
 &  &        & 
 &     
     &  
> k  
     

W   
   
 
b    
&    &  ]    &  0 &  
     5

     W      
     
 &   &   &    %
b        W
 [    &  
•
    
  0 &      > r [   & 
   

         
 
      & >
•
r [   &   & &          

  >
•
r [   &  & 
   & &   

 
5  
    &   0 &      l
 >
•
  [ W &      3     &     W &  
    [ W &
&
-
    &   [     &  3
  ]    
 

W   %

        r    & W  &   
&  >


 &         W       &  0 &  
    
&  >
 s t  u v    M u   x y z
@
 { v u | v

 } u v { 
~   €   

 ~  

 
 t

 ‚ ƒ y } u s
    ~  
„ „
  … …

~ €
 t

 ‚ | † ‚ s
… 


„
  €  €  
 
… 
„ t

 { v | { „
…  … 





 …

  
t

 { | v } v
   € … ~ … ~ 
 „
€ 
„
€
 
 €
t

 s ‚  s
    ~ € €

 € 
 „
€ 
t
i



0 &     
  
  :
&      

 ]      &    0
 
 &    r [   &  
 
 
 %


j
L
     :

 > S   r [   &  & 
  
 
   
     

W   
      


 &  &     W &  

 r [   &  
 
 
 
[      3 W     &   

5     &    [ W 
 
 Y       
 

 

[     5 &  
 
      >

 ]         

 
  :
&
  b 
 &  

 
W &  W  &   
%
&  >
     &       
   & 
 &   
 
  %
:
& 
9 b  
 3    [     

 0 &        
ˆ ‰ Š Š ‹ Œ ‰   c          r [   &  W  &   
& %
   3 5 W



  &   &  0 &  
    W   
-

>
|  ƒ u y 

 Ž v v z  Ž 
l & W   [   &      W    &
-
   0
      3  
b    
 3
 
       &  r [   &  W  &   
& %
     ˆ ‰ Š Š ‹ Œ ‰  
-
 3 W

   b &   

-
   :
   >
S  W    &    

-
   :
     W     
 
%

    f    
   0 &    3  [
  
   
  &
 

   
[
5 &  3  & [ &        [  
 b & 3
c
0 &      
&
-
        [  ] &         
&  >
S  0 &       & c     [
5 &  ˆ ‰ Š Š ‹ Œ ‰  
       3 W     &          

   
5  &  b  %
         &     

-
       b     &  0 &  %

        
               & &    

   
3
W  
           &      [   & %
&           3 5            [   & &    
   
  & > “    [
-

 b & 3    &  &          

    


   
  r    & c
  &      [  
 %
    ˆ ‰ Š Š ‹ Œ ‰ [ Y  [ &  & [ &  &   
 ]  [ W  &
    [ &    &  & 3    

W  
       
[
5 & 
   
3 & c     
W

    :
    [  W & %
-
  3 
-
 &
  W      &      >
S  
  

-
   :
       &     W &    & 
-

 %
XVI Jornadas de Paralelismo, JP '2005 619
   
                       
  
 #           * +  ,   #   /  ,  0
2  4 6 8

9
: 2 < = : 2 8 
>  #   /  ,  +    * B    #               
*        ,        # H       *   * 
L
 #  M  0
 *          , *    Q  ,    +      *  *  S
  ,       * #  *   * / ,    * T   ,    *   B  
 U   ,     ,    *    ,  *  *  #             S
   T      *   * 
L
 #  M   # H       0

,    *  B         * 
L
*  , +  ,    # / , S
               * B   #  \     *   #    M 
      U   ,    T  ,    ,    *    ,  *     S
   T  ,  * #   #  ,  0
   `   *    
   S
  \    *  ,  / #   
L
    *    B      ,  ,
       ,    \     #  *  ,  * +  #     * B   `  S
  *   #   #    0  * c      * B     #  * +  #     *

 ,  * f
    ,  T
   `        #      
  ,    *  * f  *     , f     *  ,    *  * #    ,  0 > 

      T
 *   *       #         ,    S
*  * f    B   #  *     * B     *      ,    *   
 *  * +  #     *   *     
L
,    *      *  
 #   *   
 ,  * T
    ,  0  f    #     f
 #                 
 *    #       ,    *
     ,    *  * 0


L
     ,  
L

 f B          B   #   # S
 ,    # +  #         f #  / ,            S
   *   +  M  *          0  * c f     ,  * +    *
 #   *   
 ,  * T
    ,        #    
 *   T        T `  T            *    *  S
  , 
L
#  *   
L
 * #    *   #                f
  #  *   *  *  
 *   * f
 *    T
   `  `  T
   *         *  *   #     *  *  * f    #
  *   
   `  *     , c  ` 
L
#  ,     *     *
           0  * c       *       ,    *  * 
L
S
*  , +       * B           *    ,  , *    #  S
,  * f *  
L
    B    #                
  
*     
  ,        U   ,    T  ,    ,    S
*  *        B   #   #  ,    # +  #    *  *
 #  0     * f    *    *  f #  *          * 
L
S
     *     U   ,     ,    *  * *    #  ,  * *  
 *   ,      *   ,  *  0 j  ,    ,  f         S
  , *   #   #  ,    *      ,  ,    *  #       
    *  ,    *  * T #    Q  ,        ,          
    U   ,  *    #  ,    ,    *  *      # #  /  ,
 *  ,   T   Q  ,    f  
L
 l      * c #  * / ,    *
          * B        ,    * 0
   *  ,    # #     ,  ,     *       B    
       ,   , #           B         * # #  /  ,
 
L
   , f
*  *  +   #  ,         # +  #  
   #  ,   f
   `  0 H    
L
 , /  f #  #   /  S
    #  ,  ,    *   Q    , B         *
      ,   ,   ,  f   , #  B   #    l  ,     \ 
 *
L
 *  , *    #   #  ,    ,   #  /  , #        
           ,   * #    ,  f T   ,    *  /     
   ,    *    ,  * 0
 n 
o p q
s t u o p v t
>   *   , c   #  *  `    *  ,  
L
,  +       #
/ ,  Q  +  #       , +  *  # c     *   ,   *   ,   S
 / ,    0 w     * ,     \    +  #     *  /  #  S
M  , c  #  /    ,    \     #  +  *     ,         *
 ,    / ,    * *  /  ,  * f  
L
    B     *   , +  *
  ,         *      *   +  #    ,  *    
  ,    , c *    * *    #  ,  * 0
w   ,     \    +  #     *  *     ,        S
      #       *  *  f    *  B    *  *    S
      , +  ,   *   # #    *       *    #  ,  ,
T #  *  #   #  *   #  *   T      *         *  

j  S     *  +  * 0
j  ,  # #  f  ,        * #    ,  #  #  M    \    # 
   * ,     \    # +  #             * B    
    ,  #  #  *    
  Q        # T      * 0
  +      * #    #      \    ,  *    *    ,  S
 * f     ,    *  , B      ,      # Q      S
       f   *  ,   *  ,  , B      * ,  T    #
 ,  ,   # +  #       ,        *     *  * f `  * S
      ,  , *  f T               /  , 
L
#   
 ,   * #    ,  B      * ,  T   #  * ,
L
 #  * B  
        #  *     *   #  ,  , 0
 * c   *   f 
      * ,  *  #    * 
  ,  S
    #  *   #    ,  #  #  M    \    *  ,     ,  # 
   * ,     \    / ,  Q  *


          *     # S
620 Aplicaciones
   
      
    
      
             % '   )  
   

,

)    -            1      4  )

T
  


  7 8 9 9 : < 8  4 % )    >      
,
)    D  


) F    4         )  '  )   D     F    4


K     
,
   
    '      4       ) K   
 
K )   -   D   - 
       
D   Q       S
,
 T       4 
,
     

,
)
  )   
W 
X  Y Z  [ \ [ X Y Z


    
,
 T  1    
  '   ' 
    K 
   S
 ) ^     '       ) ^   ) _
     '  )    ) _
     ) S
 '      K 
    ) _
  K   1  
l
S F    4
 

l > 2
  
,
)         '   T )    D        S
' 
 - 

'  )    '                    S
'     ) 
      '  )    ) _
  )           
 T     ) _
 
 )  )
     
 ) F      )     
>  
  '    ) )  4 F     )

T
 
 )  
   T    S
 ) _
  
                          
     '  D     D      
  ) 
        
 g   '    4 
,
       )  '    
  ) _
   
 '  )    ) _
 

 K  
    )    D      '  K ) S

          
    )   '      _  '   
     
)    ) _

i j  j X j k l m Z
        -


 o       ) -   o         8 
  

9     8    8    q 
 
r  Q 
o    - q  o    -


 
,
 )  K  
) F    ) 
t     -     
   r      F )  -   o     ) 7 9         9 

      9   7 !   :  t 
,
 )    


  '  K   ' Q   )   
 
 ) 
      S
Q  ' 
t    )   
 " Q     )
t 
,
 )    


  '  K   ' Q  - t 

%
 # - t   ) x      Q  S
  - '  ' 
- q 


o  $ %   
,
        # 
 %  r    D   -  r    )
     9   *       9 
  :  9 7  , ,      !  t      " o S  -
q 


o  %   - o '  )
K       -
 *  S    
 $  '    q )  -       ) -


 o )  -   q 


Q 
-
" 


Q  ) - 0      8 8         !    :   
9    8    

9   8     9 !  9  1   9 >  S




%
    - 
 
 ) 
 



1   
 

"  
  )

   
)   ) 
 -     -    
 - % #  S % # $ 
   '  r )   -   r   
 -   o    
)  - '  " 
 -
r               4  : 9  

    4  9   
  8   / 1   ! 9  9 8   9        
) _
>  S
'          ) '    K g     K   )        
S
1      ) _
-

F )    -     -  *  S  # * 
     r   
 -   o    
)  - '  " 
 - r       -
           ! 9    4  : 9  

  9  : 8  
   ! 9 :    9  

  : 9       9        '   S

      r    4 )    )        K   g S
 )   - r    )  -    $ -  # * S   $ 
 *    "  "    - r    r       )
7 !   : 
    9       ! ! 9  9 " "   Q
   K 
'   
  - o '  )
K   o  ) 
  -      * -    S
,
  % - '        -  * S   
 #  Q '  A A C C C          )   Q     %      A E A
   '  A >

o


 '  1  9     8   

9
 8     9 ! I  7 !   :  " Q 
  F 
Q )
    )    1 >



C Q )  '  '    


  )     Q )  t  '       # 
   r     K  t    )
K 
  1         0 L  N ,
0 9     9  8         9

  9 7   :  : '    S

   1 o  '      '    ' '  )   ) 

     # -
    % A $ -    $ 
XVI Jornadas de Paralelismo, JP '2005 621
S2
F2
M - Sistema Estadístico para la Predicción de Incendios
Forestales *
Germán Bianchini, Ana Cortés, Tomás Margalef y Emilio Luque
Dept. de Arquitectura de Computadores y Sistemas Operativos
Universitat Autònoma de Barcelona
08193 Bellaterra (Barcelona) España
german.bianchini@aomail.uab.es, {ana.cortes,tomas.margalef,emilio.luque}@uab.es
Resumen
Uno de los grandes problemas presentes en
las simulaciones de incendios forestales radi-
ca en la falta de precisión de los parámetros
de entrada (humedad, dirección y velocidad
del viento, etc.). En este artículo se descri-
be un método estadístico basado en experi-
mentos factoriales. El método evalúa un ele-
vado número de combinaciones de paráme-
tros en vez de considerar un único valor para
cada uno. De esta forma, se espera lograr
una predicción más cercana a la realidad. La
metodología propuesta ha sido implementada
bajo un esquema paralelo y probada en un
cluster Linux usando MPI.
1. Motivación
El principal objetivo de los desarrolladores de
modelos de comportamiento de incendios fo-
restales es proporcionar modelos que puedan
explicar, simular y predecir el comportamien-
to del fuego. Estos modelos pueden ser usa-
dos para desarrollar simuladores y herramien-
tas útiles para prevenir y luchar contra es-
tos siniestros [1] [2] [5] [6]. Además, estos
simuladores y herramientas pueden integrarse
dentro de un DSS (Decision Support System).
Pero ¾qué entendemos por un DSS? Es posi-
ble denirlo como un sistema informático que
*This work has been supported by the Comisión
Interministerial de Ciencia y Tecnología (CICYT)
under contract TIC2001-2592 and by the European
Commission under contract EVG1-CT-2001-00043
SPREAD
apoya el proceso de toma de decisiones, ayu-
dando a los decisores a formar y explorar las
implicaciones de sus juicios y, por tanto, a
tomar decisiones basadas en el entendimien-
to [10]. Por lo tanto, este tipo de sistema
debiera fundamentalmente ayudar a formar
juicios en vez de presentar ayuda general co-
mo suelen ser los resúmenes de información en
una base de datos. En la actualidad un DSS
persigue un objetivo más ambicioso ya que in-
tenta proveer información correcta (a veces en
tiempo real) para lograr una planicación del
terreno, implementación de medidas preventi-
vas, monitoreo eciente y ayuda on-line mien-
tras se está dando lugar el incendio, etc.
No obstante, la mayoría de los modelos exis-
tentes son incapaces de predecir con certeza el
comportamiento de un incendio forestal. Es-
to se debe a diversas razones, pero una de las
más importantes es que hay varios parámetros
(contenido de humedad, condiciones del vien-
to, etc.), que resultan difíciles de estimar con
precisión.
Es posible sobrellevar este problema de los
parámetros de entrada usando técnicas tales
como optimización de parámetros [3], cuyo ob-
jetivo es denir con la máxima exactitud los
valores de los parámetros para, de esta man-
era, obtener una predicción lo más real posible.
En este artículo, si bien nos enfocamos
también en el tratamiento de los parámetros
de entrada, nuestro objetivo es desarrollar
una metodología basada en análisis estadístico
para determinar el comportamiento más pro-
bable de un incendio forestal y aplicar dicha
metodología en la implementación de un DSS.
S2
F2
M (de la sigla inglesa Statistical Sys-
tem for Forest Fire Management) no sólo ali-
mentaalsimuladorconlosvaloresconocidos,
sino que efectúa un conjunto de simulaciones,
en vez de una sola, obtenidas a partir de la
combinación de aquellos parámetros de entra-
da de los cuales menos certeza se tiene acerca
de su valor.
Este método requiere una gran cantidad de
cómputo para poder obtener una conclusión
a partir de los datos utilizados debido a que
es preciso ejecutar un gran número de simu-
laciones. Para hacer frente a este problema
hemos usado un esquema de programación
paralela (master-worker), aplicado sobre un
cluster de PC. El método fue implementado
usando MPI [9] como librería de paso de men-
sajes y es ejecutado sobre un cluster Linux.
En este artículo analizamos las mejoras pro-
porcionadas por el esquema propuesto en tér-
minos de calidad de la predicción y en ganan-
ciadespeed-up paraquemasexperimentalesen
campo efectuadas para dicho propósito.
El presente artículo está organizado de la
siguiente manera: La experimentación facto-
rial y los conceptos básicos del sistema son ex-
plicados en la sección 2. La implementación
del sistema es descrita en la sección 3. La sec-
ción 4 incluye el resultado obtenido cuando el
método fue aplicado a dos casos de incendios
forestales. Finalmente, la sección 5 reporta las
principales conclusiones.
2. Experimentación factorial
La metodología de este trabajo está basada
en estadística. La estadística trata acerca de
la recolección, presentación, análisis y uso de
datosparatomar,porejemplo,decisiones.Hay
dos posibles formas de recolectar datos acer-
ca de un evento. En un estudio observa-
cional el investigador solamente toma notas
sin interactuar en la situación. Los datos se
obtienen conforme se van presentando. Otra
forma es a través de un experimento dise-
ñado. En esta clase de experimento se reali-
zancambiosdeliberados o intencionadosen las
variables controladas de un sistema o proceso.
Se observan los resultados obtenidos y luego se
hace una inferencia o toma de decisión acer-
ca de las variables responsables de los cam-
bios. Cuando son varios los factores potencial-
mente importantes (i.e. clima, velocidad del
viento, pendiente del terreno, etc.), la mejor
estrategia es usar algún tipo de experimento
factorial. Un experimento factorial es aquel
en el que los factores se hacen variar al mis-
mo tiempo [12] (por ejemplo cambiando las
condiciones del viento, contenido de humedad
y parámetros de la vegetación). Un escenario
representa cada situación particular que resul-
ta de un conjunto de parámetros. Dentro de
un intervalo de tiempo, nos interesa conocer si
una porción de terreno (llamada celda) se que-
ma o no. Si n es el número total de escenarios
ynA elnúmerodeescenariosenelcuallacelda
se quema, podemos calcular la probabilidad
de ignición como:
Pign(A) = nA/n
El próximo paso es generalizar este razona-
miento y aplicarlo a un conjunto de celdas. De
esta manera obtendremos una matriz con val-
ores representando la probabilidad de ignición
de cada celda (gura 1)
Pign
()=1.0
Pign
()=0.7
Pign()=0.1
Figura 1: Generalización del concepto de análisis
de celdas
A partir de este momento, podemos enfocar
nuestro análisis en el procedimiento de gene-
ración de posibles escenarios.
2.1. Generación de escenarios
Nuestro sistema utiliza un simulador de com-
portamiento de fuego como una caja negra,
624 Aplicaciones
el cual debe ser alimentado con un conjunto
de parámetros para operar correctamente. Un
conjunto particular de estos parámetros es lo
que dene un escenario. Estos parámetros se
corresponden con los parámetros propuestos
en el modelo de Rothermel [7]. Para cada uno
de estos parámetros, hemos de denir un rango
y un valor de incremento con el cual recorrer el
intervalo planteado. Para un parámetro dado i
(al cual llamaremos Parámetro_i ) el intervalo
e incremento asociado se expresa como:
[Cota_Inferior_i, Cota_Superior_i],
Incremento_i
Luego, de cada parámetro i, es posible
obtener un número Ci (cardinalidad del do-
minio del parámetro), el cual es calculado de
la siguiente manera:
Ci = ((CSi − CIi) + Inci)/Inci
donde CSi es Cota_Superior_i, CIi es Co-
ta_Inferior_i e Inci es Incremento_i.
Finalmente, a partir de la cardinalidad de
cada parámetro, es posible calcular el número
total de escenarios obtenidos de las variaciones
de todas las posibles combinaciones.
#Escenarios =
n

i=1
Ci
siendo n el número de parámetros.
3. Implementación de S2
F2
M
Los conceptos descritos arriba han sido imple-
mentados en un sistema operacional que in-
corpora un kernel de simulación y aplica la
metodología para evaluar la función tness.
Este sistema ha sido desarrollado sobre un
cluster de PC's LINUX usando MPI [9] como
librería de paso de mensajes.
3.1. El simulador
S2
F2
M usa como núcleo de simulación el si-
mulador propuesto por Collin D. Bevins, el
cual está basado en la librería reLib [4]. re-
Lib es una librería que encapsula el algoritmo
de comportamiento de incendios BEHAVE [1].
En particular, este simulador usa una aproxi-
mación basada en celdas y una relación con los
vecinos colindantes para evaluar si una celda
se ha quemado y en qué momento fue alcan-
zada por el fuego.
El simulador acepta como entrada mapas
de terreno, características de la vegetación, el
viento y el mapa de ignición.
La salida generada por el simulador consiste
de un mapa del terreno donde cada celda es
marcada con su propio tiempo de ignición.
3.2. La función Fitness
Para poder evaluar la respuesta del sistema
denimos una función tness. Debido a que
S2
F2
M usa una aproximación basada en cel-
das, la función tness se dene como el co-
ciente entre el número de celdas en la intersec-
ción entre la simulación y el comportamiento
real, y la unión del resultado de la simulación
y la situación real (Fitness = (celdas en la in-
tersección)/(celdas en la unión)).
La gura 2 muestra un ejemplo de cómo se
calcula esta función para un terreno de 5 x 5
celdas. En este caso, la función tness es 7/10
= 0.7.
Área quemada real
Área quemada simulada
celdas quemadas
celdas en la unión
celdas en la intersección
en la unión en la intersección
Figura 2: Cálculo del tness para un terreno de 5
x 5 celdas
XVI Jornadas de Paralelismo, JP '2005 625
Un valor de tness igual a 1 indica una
predicción perfecta ya que signica que el área
predicha es igual al área quemada real. Por el
contrario, un tness igual a cero señala el má-
ximo error, debido a que en este caso nuestro
experimento no tendría ninguna coincidencia
con el área quemada previamente, vale decir,
la realidad.
3.3. Paralelización
S2
F2
M debe efectuar una cantidad impor-
tante de cálculos debido a que utiliza un si-
mulador secuencial como núcleo [4], y por esta
razón precisa efectuar una simulación por cada
combinación de parámetros resultante (#Es-
cenarios). Esto conlleva un substancial coste
en tiempo.
Para reducir el tiempo de ejecución hace-
mos uso de múltiples recursos computacionales
trabajando en paralelo para lograr la ecien-
cia requerida. Teniendo en mente la natu-
raleza del problema que S2
F2
M pretende re-
solver, creemos que una arquitectura de tipo
master-worker es idónea para tal propósito,
pues de esta manera un procesador principal
puede calcular cada combinación de paráme-
tros y enviar dicha información a un conjunto
de workers (gura 3). Éstos se encargarán de
efectuar la simulación y retornarán el mapa
resultante al master. Cada mapa indica qué
celdas han sido quemadas y cuáles no.
Master
Worker Worker Worker Worker
Áreas quemadas independientes
Intersección
Figura 3: Ejemplo conceptual con cuatro escena-
rios
Nuestro sistema posee una estructura bien
denida. El proceso Master tiene una eta-
pa de recepción de datos (cheros de pará-
metros, cheros de terreno, tiempos de simu-
lación, etc.). A continuación hay una etapa de
inicialización para las estructuras de datos. En
el bucle principal, el Master distribuye escena-
rios a los workers, espera por los resultados y
envía más datos a los workers que van ter-
minando los escenarios asignados (si quedan
escenarios por simular). Finalmente, presenta
una salida gráca.
Por su parte, la estructura de los workers
es complementaria. Cada uno tiene una etapa
de recepción de datos (para inicializar dimen-
siones del terreno e inclinanción). A continua-
ción, ingresan en un bucle en el cual reciben
escenarios por parte del Master para activar
la rutina de simulación para calcular la propa-
gación del fuego.
4. Resultados experimentales
Para probar el sistema usamos dos experimen-
tos de campo. Ambas quemas fueron llevadas
a cabo en Serra da Lousã -Gestosa, Portu-
gal (40◦
15'N, 8◦
10'O)-, a una altitud de entre
800 y 950 m sobre el nivel del mar. Las que-
mas fueron realizadas en el marco del proyecto
SPREAD [11]. En los experimentos de campo
de Gestosa [8], el terreno fue dividido en plots
con la nalidad de realizar diferentes pruebas y
experimentos. Esto lo podemos ver en la gura
4.
Figura 4: Vista del área de Gestosa y de la división
del terreno en plots
626 Aplicaciones
En particular, trabajamos con los plots 513
y 519, los cuales presentaban las siguientes ca-
racterísticas:
Experimento 1 (Plot 513): el plot se repre-
sentó mediante una matriz de 58 columnas por
50 las, con un tamaño de celda de 0,94 m de
alto x 0,94 m de ancho.
Experimento 2 (Plot 519): el plot se repre-
sentó mediante una matriz de 89 columnas por
91 las, con un tamaño de celda de 0,94 m de
alto x 0,94 m de ancho.
Para conseguir la mayor cantidad de infor-
mación posible acerca del comportamiento del
fuego, se utilizó una cámara infrarroja para
registrar la evolución completa del incendio.
Seguidamente, se analizó el video obtenido y
se extrajeron imágenes cada 2 minutos en el
primer ensayo y cada 2,5 minutos en el se-
gundo. De dichas imágenes se extrajeron los
perímetros del fuego y se los convirtió al for-
mato de celdas para la correcta interpretación
de S2
F2
M.
4.1. Experimento 1
Este tipo de caso resulta muy complicado, de-
bido a que por ser un experimento en campo
no es posible controlar las condiciones ambien-
tales, cosa que sí es factible en los experimen-
tos de laboratorio. Sin embargo, jamos cier-
tos valores conocidos (pendiente del terreno y
contenido de humedad en 1, 10 y 100 horas) y
dejamos variar los demás.
A n de efectuar comparaciones, determi-
namos un tiempo inicial y un tiempo nal a 0
y 12 minutos respectivamente.
En la tabla 1 podemos ver que el valor del
tness se encuetra entre 0,7 y 0,91, lo cual es
un indicador de que nuestra salida estadísti-
ca se aproxima notoriamente a la realidad. Es
importante notar que en la tabla de tness só-
lo se consideran aquellas celdas con 100% de
ignición (celdas que se han quemado en la to-
talidad de los escenarios).
En la gura 5 se aprecia que el resultado que
ofrece S2
F2
M siempre está acotado por la rea-
lidad, es decir, no sobrepasa los límites de la
propagación real. En la gura sólo incluimos el
último paso de simulación (en este caso el mi-
Tiempo inicial Tiempo nal Fitness
0:00 2:00 0,749420
2:00 4:00 0,690152
4:00 6:00 0,864360
6:00 8:00 0,953166
8:00 10:00 0,826158
10:00 12:00 0,915669
Tabla 1: Fitness del experimento 1 en cada
intervalo
nuto 12), ya que los pasos precedentes también
están incluidos en el perímetro real.
Exp. 1: Área final propuesta por S2
F2
M
Área real
Figura 5: Salida de S2F2M para el minuto 12 del
Experimento 1
4.2. Experimento 2
El segundo experimento presenta un chero de
rangos idéntico al del plot 513. Esto se debe
a que la ubicación de estas parcelas de terre-
no era muy cercana, de modo que las caracte-
rísticas del terreno pueden considerarse como
equivalentes. La tabla 2 muestra el tness re-
sultante.
Finalmente, y siguiendo el mismo criterio,
en la gura 7 mostramos el estado propuesto
por S2
F2
M para el minuto 12,5. Es posible
identicar con claridad que el área propuesta
por S2
F2
M está incluida dentro del perímetro
real.
XVI Jornadas de Paralelismo, JP '2005 627
Figura 6: Minuto 12 durante la quema realizada
para el Experimento 1
Tiempo inicial Tiempo nal Fitness
2:30 5:00 0,451988
5:00 7:30 0,486521
7:30 10:00 0,425703
10:00 12:30 0,774615
Tabla 2: Fitness del experimento 2 en cada
intervalo
Exp.2: Área final propuesta por S2
F2
M
Área real
Figura 7: Salida de S2F2M para el minuto 12 del
Experimento 2
Figura 8: Minuto 12,5 durante la quema realizada
para el Experimento 2
4.3. Mejora en el Speed-up
En un caso real el sistema debiera trabajar
bajo restricciones de tiempo real y, por lo tan-
to, es necesario analizar el speed-up obtenido
usando diferente número de procesadores. El
número de procesadores usados en los suce-
sivos experimentos fue 1, 2, 4, 8, 12, 16, 20,
24, 28 y 32. La gura 9 muestra el speed-up
para un ejemplo particular comparado con un
speed-up lineal (el caso ideal).
Speed Up
número de procesadores
speed
up
Lineal
Speed Up
0
8
16
24
32
0 8 16 24 32
Figura 9: Curvas de Speed-up para el experimento
1 y para el caso ideal
Se puede apreciar cómo hasta el uso de
16 máquinas el speed-up es prácticamente li-
neal. A partir de ese punto, el incremento del
número de procesadores asignados sigue siendo
benecioso, pero se observa que la pendiente
de la curva comienza a disminuir.
628 Aplicaciones
5. Conclusiones

 
   
 

    
 

 





   

 

 
   

  


 
   






   
   

  
  
 

   


  
 

   

  


   
   S2
F2
M 
 

!""#  
    

   

  
 


    
    

  
 
  $
  
 %         
 
   S2
F2
M   
 
$
 
      
 
 


 master-worker 

 
 

Referencias
&!' %
( ) * +, -%. / 0 ,
 

 

  $ , 

   !1 2

3

4$
 563$!78 9 
 :3 :; 

 %
  0 ; 5

$

4 ;
< !7=>
&?' %
( ) *< ,
 


<
;
 4  +,)
 @  


 
?"/ :A 2  1 2

3 4 4B4;$234$!">CCC 9$

 :3/ 
  %
  0$
 ; 4D B

4 ;$

 ?""E
&E' ,D % 
 2 ,

 %

F 3G B
 
 *  /
+5
 C


0 ) 


B)5 
1 *6; ?=8"  H?"$H?=
?""E
&8' 


  ,
 +0* : B


I
3

4
1 !77>
/JJ(((@
&H' 0

 BD % +0%4;53 / 0 %
;
$ 


 

$

1 4 ) 4B4;$4)$8 9 
 :3/
:; 
  %
  0
; 4D B

4 ;$

 8K  !77=L
&>' % %5 ) / 054 ;3%3596
/JJ((( J J@
J
&K' 4
 4  +% 
 

  
 @  
(


 $

1 :; % 0; 9 
3: 4 ) 563$
!!H !7K?
&=' % %5 $  50 M
  0 0 ; $
N /JJ((( JJ2J
&7' B)5/ 3 B )
 5
 ;
$

/JJ((($


JJ
&!"' ; 4 5
  

,
 *$
 %

 B 

 +0
$

 
 ;  %  
 $

1 4B ?""? 5;,6 =8$K=7K$878$>
&!!' ) ;  0 0 ; )$



B

/JJ((( J J
&!?'  
  B
 2 
4
 1%
  

$
  

1 O
C
 I ;
 6(
PD * !778 5;,6/ "8K!"!"?!7
XVI Jornadas de Paralelismo, JP '2005 629
   
              "    $ &   $  *  -       1     $   -  7 
*  - "  9      -   &  < -    $ >
? @ A C D C F G I J K @ L M N G O P Q R T U @ V W D V R @ C [ @ M ] D _ A R @ V D b C F A @ U
d e f h i k h l e m k p q e r m t p i l w k y { h q e | y } k e l h } ~ € p l f  k h q p i e }
‚ m y ƒ e i } y q h q † p ‡ y k ˆ { m y { h q e ‰ h ‡ e m { y h
€ h l y m p q e ‰ e i h } Œ m  Ž   ‘ ‘ ‰ h ‡ e m { y h
’
p f e ” • q y } { h –  f ƒ – e }  ˜ ƒ h ‡ y e m k • q y } { h –  f ƒ – e }  ™ h m q i e  • q y } { h –  f ƒ – e }
š œ  ž Ÿ   ¡ ž
¢ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª ¬ ¯ ° ­ © ° ¥ ± ² © ¬ ­ ¯ ³ © ¨ ± ¬ ° ­ ± § ¯ µ ¯
¨ § ¤ ¤ ¬ © « ° £ ± § ± ± ² © ¹ ­ § » ¯ ± § ª © ¯ ° ¥ ± ² © ½ § ­ £ ¾
¥ § ¨ ± £ ¤ ¬ ­ ª ³ ¤ ° ¨ © ¯ ¯ ° ¥ ¨ © ¤ § ½ ¬ ¨ ± ¬ » © ¯ À Â ­ ³ ¤ © Ã ¬ ¾
° £ ¯ Ä ° ¤ µ ¯ Ä © « © Ã © » ° ³ © « § ½ © ± ² ° « Å § ¯ © « ° ­
¨ ° ½ ³ £ ± © ¤ Ã ¬ ¯ ¬ ° ­ ± © ¨ ² ­ ¬ Æ £ © ¯ ± ° § £ ± ° ½ § ± ¬ Ç © ± ² ¬ ¯
± § ¯ µ À É ² ¬ ¯ ³ § ³ © ¤ ³ ¤ © ¯ © ­ ± ¯ § ¯ ± £ « Ê § Å ° £ ± ± ² ©
¤ © § » ¾ ± ¬ ½ © ¨ ° ½ ³ » ¬ § ­ ¨ © ° ¥ ± ² © ½ © ± ² ° « À Î © § » ¾
± ¬ ½ © ¨ ° ½ ³ » ¬ § ­ ¨ © ¬ ½ ³ » ¬ © ¯ ± ° Å © § Å » © ± ° ¬ ­ ¯ ³ © ¨ ±
§ » » ± ² © ³ ¬ © ¨ © ¯ § ± ³ ¤ ° « £ ¨ ± ¬ ° ­ ¤ § ± © ¯ À É ² © ¯ ± £ « Ê
§ » ¯ ° ¬ ­ ¨ » £ « © ¯ ± ² © ³ § ¤ § » » © » ¬ Ç § ± ¬ ° ­ ° ¥ ± ² © ½ © ± ² ° «
£ ¯ ¬ ­ ª § ­ § ¤ ¨ ² ¬ ± © ¨ ± £ ¤ © Å § ¯ © « ° ­ ¨ » £ ¯ ± © ¤ ¯ § ­ «
Ñ Ò
 À Ó © ¨ ° ½ ³ § ¤ © « ± Ä ° « ¬ Ô © ¤ © ­ ± ¨ » £ ¯ ± © ¤ ½ § ¾
¨ ² ¬ ­ © ¯ ± ° « © ± © ¤ ½ ¬ ­ © ± ² © Å © ­ © ¹ ± ¯ ° ¥ £ ¯ ¬ ­ ª ² ¬ ª ² » Ê
¥ © § ± £ ¤ © « ¨ » £ ¯ ± © ¤ ¯ § ª § ¬ ­ ¯ ± ½ © « ¬ £ ½ » Ê ¥ © § ± £ ¤ © «
¨ » £ ¯ ± © ¤ ¯ À
Ö × Ø
ž Ÿ Ù Ú Û ¡ ž Ü Ù
Ø
É ² © ¤ © § ¤ © ½ § ­ Ê ¬ ­ « £ ¯ ± ¤ ¬ © ¯ ½ § ­ £ ¥ § ¨ ± £ ¤ ¬ ­ ª ½ § ¾
± © ¤ ¬ § » ¯ ¤ © » § ± © « Ä ¬ ± ² Ý § ± ¯ £ ¤ ¥ § ¨ © ¯ ± ² § ± ­ © © « ± °
¯ ³ » ¬ ± ± ² © ¬ ¤ ³ ¤ ° « £ ¨ ± ¬ ° ­ ¬ ­ ± ° ² ° ½ ° ª © ­ © ° £ ¯ ¯ © ¾
¤ ¬ © ¯ ª ¤ ° £ ³ © « Å Ê ± ² © ª » ° Å § » § ³ ³ © § ¤ § ­ ¨ © ° ¥ ± ² ©
¹ ­ § » ³ ¤ ° « £ ¨ ± À É ² © ¯ © µ ¬ ­ « ° ¥ ³ ¤ ° « £ ¨ ± ¯ § ¤ ©
£ ¯ © « ± ° « ¤ © ¯ ¯ Å £ ¬ » « ¬ ­ ª Ä § » » ¯ ° ¤ Ý ° ° ¤ ¯ § ­ « © Ã © ­
« ¤ © ¯ ¯ ¤ ° ° ½ ¯ ° ¤ ³ © ° ³ » © À ¢ ° ½ © ° ¥ ± ² © ¯ © ³ ¤ ° « £ ¨ ± ¯
¨ ° ½ © ¥ ¤ ° ½ ­ § ± £ ¤ © § ¯ ½ § ¤ Å » © à ª ¤ § ­ ¬ ± © ° ¤ Ä ° ° «
Å ° § ¤ « ¯ à § ­ « ° ± ² © ¤ ¯ § ¤ © § ¤ ± ¬ ¹ ¨ ¬ § » ¯ ± £ Ô » ¬ µ © ¨ © ¾
¤ § ½ ¬ ¨ ± ¬ » © ¯ ° ¤ ± © á ± ¬ » © ¥ § Å ¤ ¬ ¨ ¯ À
 ­ ± ² © ¯ © ¬ ­ « £ ¯ ± ¤ ¬ © ¯ ± ² © Æ £ § » ¬ ± Ê ¨ ° ­ ± ¤ ° » ¯ ± § ª ©
¬ ¯ ¨ ¤ £ ¨ ¬ § » ¬ ­ ° ¤ « © ¤ ± ° ¤ © ½ § ¬ ­ ¨ ° ½ ³ © ± ¬ ± ¬ Ã © À â ­ ©
° ¥ ± ² © ½ ° ¯ ± ¬ ½ ³ ° ¤ ± § ­ ± Æ £ § » ¬ ± Ê ³ ¤ ° Å » © ½ ¯ ¬ ¯
± ² © ­ ° ­ ¾ £ ­ ¬ ¥ ° ¤ ½ ¬ ± Ê ° ¥ ± ² © Ã ¬ ¯ £ § » § ¯ ³ © ¨ ± ° ¥ ± ² ©
³ ¤ ° « £ ¨ ± ¬ ­ ¯ ¬ « © ± ² © ¯ § ½ © » ° ± ° ¥ § ¯ ³ © ¨ ¬ ¹ ¨ ½ ° « © » À
å
¯ ± ² © ¹ ­ § » ³ ¤ °
« £ ¨ ± ² § ¯ ± ° Å © © á ³ ° ¯ © « ¥ ° ¤ ½ ¬ ­ ª
à ¬ ¯ £ § » § ¤ © § ¯ Ä ² ¬ ¨ ² § ¤ © ¯ £ ³ ³ ° ¯ © « ± ° Å © £ ­ ¬ ¥ ° ¤ ½ à
± ² © ³ ¤ © ¯ © ­ ¨ © ° ¥ ³ ¬ © ¨ © ¯ Ä ¬ ± ² « ¬ Ô © ¤ © ­ ± § ³ ³ © § ¤ ¾
§ ­ ¨ © ¯ ¬ ¯ ¨ ° ­ ¯ ¬ « © ¤ © « § ¯ © ¤ ¬ ° £ ¯ Æ £ § » ¬ ± Ê ¥ § £ » ± À
å
± ± ² © ½ ° ½ © ­ ± à ¬ ­ « £ ¯ ± ¤ ¬ © ¯ ¤ © » Ê ± ² © ± § ¯ µ ° ¥
¯ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª ° ­ ² £ ½ § ­ ° ³ © ¤ § ± ° ¤ ¯ À É ² ¬ ¯ ² £ ¾
½ § ­ ª ¤ § « ¬ ­ ª ¬ ¯ ¯ £ Å ç © ¨ ± ¬ Ã © § ­ « ° ¥ ± © ­ ¬ ­ ¨ ° ­ ¯ ¬ ¯ ¾
± © ­ ± Å © ± Ä © © ­ « ¬ Ô © ¤ © ­ ± ª ¤ § « © ¤ ¯ è é ê À É ² £ ¯ à § £ ± ° ¾
½ § ± ¬ ¨ § ­ « ¤ © » ¬ § Å » © ¯ Ê ¯ ± © ½ ¯ § ¤ © ­ © © « © « À
å
» ¯ ° à
¤ © § » ¾ ± ¬ ½ © ¨ ° ½ ³ » ¬ § ­ ¨ © ¬ ¯ § Ã © ¤ Ê ¬ ½ ³ ° ¤ ± § ­ ± ¬ ¯ ¯ £ ©
¬ ­ ° ¤ « © ¤ ± ° ½ § µ © ¯ Ê ¯ ± © ½ ¯ § Å » © ± ° ¬ ­ ¯ ³ © ¨ ± ± ² ©
° Ã © ¤ § » » ³ ¤ ° « £ ¨ ± ¬ ° ­ § ± ° ­ ¾ » ¬ ­ © ¤ § ± © ¯ À
¢ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª ¬ ¯ ¤ © » § ± © « Ä ¬ ± ² ± ² © § £ ± ° ¾
½ § ± ¬ ¨ ¨ » § ¯ ¯ ¬ ¹ ¨ § ± ¬ ° ­ ° ¥ Ý § ± ³ ¬ © ¨ © ¯ ³ ¤ © ¯ © ­ ± ¬ ­ ª
¤ § ­ « ° ½ à ³ ¯ © £ « ° ¾ ¤ § ­ « ° ½ ° ¤ ¹ á © « ¯ £ ¤ ¥ § ¨ © ³ § ± ¾
± © ¤ ­ ¯ À É ² © § ¬ ½ ° ¥ ¯ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª ¬ ¯ ± ° ¯ ³ » ¬ ±
± ² © ³ ¤ ° « £ ¨ ± ¬ ° ­ ¬ ­ ± ° « ¬ Ô © ¤ © ­ ± ¨ » § ¯ ¯ © ¯ ¯ ° ¤ ± © « Å Ê
± ² © ¬ ¤ ª » ° Å § » § ³ ³ © § ¤ § ­ ¨ © à Ä ² ¬ ¨ ² « © ³ © ­ « ¯ ° ­
¨ ° » ° £ ¤ § ­ « ± © á ± £ ¤ © ³ ¤ ° ³ © ¤ ± ¬ © ¯ À
 ­ ³ ¤ © à ¬ ° £ ¯ Ä ° ¤ µ ¯ è ï ê à Ä © « © à © » ° ³ © « §
½ © ± ² ° « ± ° ³ © ¤ ¥ ° ¤ ½ ¥ § ¯ ± ¯ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª Å § ¯ © «
° ­ ± ² © £ ¯ © ° ¥ ¯ ° ¥ ± ¨ ° » ° £ ¤ ± © á ± £ ¤ © « © ¯ ¨ ¤ ¬ ³ ± ° ¤ ¯ À
Ó © ± © ¯ ± © « ± ² © ½ © ± ² ° « £ ¯ ¬ ­ ª ¯ § ½ ³ » © ¯ ¨ ° ½ ¾
¬ ­ ª ¥ ¤ ° ½ ± ² © § ¤ © § ° ¥ ¨ © ¤ § ½ ¬ ¨ ± ¬ » © ¯ § ­ « Ä ©
§ ¨ ² ¬ © Ã © « § ­ § ¨ ¨ £ ¤ § ¨ Ê ° ¥ ò ó À ô õ ° ¥ ³ ¬ © ¨ © ¯ ¨ ° ¤ ¾
¤ © ¨ ± » Ê ª ¤ § « © « À ö © Ã © ¤ ± ² © » © ¯ ¯ à ± ² © ½ © ± ² ° « ¬ ¯
¯ £ ¬ ± § Å » © ± ° Å © £ ¯ © « Ä ¬ ± ² ° ± ² © ¤ ¤ § ­ « ° ½ « © ¨ ¾
° ¤ § ± © « ¯ £ ¤ ¥ § ¨ © ¯ » ¬ µ © ½ § ¤ Å » © à ª ¤ § ­ ¬ ± © à Ä ° ° « ° ¤
± © á ± ¬ » © ¯ ± £ Ô À
É ¬ ½ © ¤ © Æ £ ¬ ¤ © ½ © ­ ± ¯ § ± ¥ § ¨ ± ° ¤ Ê ¨ § ­ Å © ² § ¤ « À
É ² © Ä ° ¤ ¯ ± ¨ § ¯ © ¨ ° ¤ ¤ © ¯ ³ ° ­ « ¯ Ä ¬ ± ² ± ² © ³ ¤ ° « £ ¨ ¾
± ¬ ° ­ ° ¥ » § ¤ ª © ³ ¬ © ¨ © ¯ ÷ ø ù á ø ù ¨ ½ ú Ä ² ¬ ¨ ² ¨ § ­ Å ©
³ ¤ ° « £ ¨ © « § ± § ¤ § ± © ° ¥ é ù ³ ¬ © ¨ © ¯ ³ © ¤ ½ ¬ ­ £ ± © À
 ­ ± ² ¬ ¯ ³ § ³ © ¤ Ä © ³ ¤ © ¯ © ­ ± § ­ ¬ ­ ¾ « © ³ ± ² ¯ ± £ « Ê ° ¥
± ¬ ½ © ¨ ° ½ ³ » ¬ § ­ ¨ © ¥ ° ¤ ± ² © ¯ £ ¤ ¥ § ¨ © ª ¤ § « ¬ ­ ª § ³ ³ » ¬ ¾
   
         
              $  &  (
     + $ 
      . 
0 (  2      2        (  8
  2 &  :      $  &     
 $  
0  .    2

= ?
@
=

  $ . B D   F G H I J L N 
      
 $   
    R  2       L    
 
     2 &  :   R  2   8
    L    

    2   $     2  R 2   
   
  8
  

   2 R  2       L    
  $    
 2     8
 $ 2  [     
 $    2  

\ =
B  ^       . 8
R  2        a  2 
  $    2  
 2   2       2 8
. 
      c 
  0    ( $  
0   0   & (    $ 2  
 $    2   0  
  .    $ .  & (    $ 2    $    2  

 (  2  R  2       L    
G     $        
g $ 8

  (        
0 @  .  0  2     $   
N  c  2   
 $ 2  & 2   $    
    
F  :        
  
    2 . 
    2     .  0  2     $   

     (  2
    $ 2 (   0 2   
0  R R      
 :    2  0 
 
 .  0     2   + $  2   $  
0  2     $   
 ( F G H
R      R  2 .     .   2  [   $       &    .   
        0
  (  2          
 (  .     $ 2 8
(     (     J    c  2 G    $  R         2   8
  $   
 $   [        c  (  2    R $ 2 R     (
 $ 2 (   0 2   
0  :     R  2  . 
  $  
0     2
 .  0  2     $   
   . 
  2         2  2  0  

  2     $   
 ( r   R      R  2 .     .   2 
 $ 2 R         . 
 . $ .  $ 2  &   .   @ u v w N
2  + $        (    2 & 
 
   & G 
    
v   R 2   
    
 $ 8
  
 
  
y
z
{ | ~ |
z
 

€ { | ‚
z
 ƒ ‚ €

 
  2    & G    2 2     $     $  & (  2     2 . 
8

0    2      .   . R   
 $  
0 
 & 

 . R $   2 
   
  
   
0  ( R  2       L  8
  
 ^  $     .    2

= ? 
    $  &   
  . 
0      (    
 R    
R 2     G    
    c     
  (  $ 2  $ [ 8 R 2       

 B .  0   + $      
     R  $ 2   (   
     .  0      2 2 &  $  $  
0      
: 2     $ .  
 
  .  2  

      
?
 2   8 B .  0 
0
= ?
8  B I 0 2  [ [  2 
H  :       2    
      2 2   R 
        
  0 . 
    
 (         $ 2 (   ( 2  .   
[  ‰ 0 2  $
 
        2  R      


2   2  
    
 (        
 2   2   (     8
        . R $     
 (    (    $ 2   
      ! # % '  ) * + - / 1 2 4 - 6 8 : !  ! 8 < > '  A B B
C
/ 1 2
=
2       .       
 
Š
+ $      
H


F
:       2    


r u F
?
 . R $     
 ( (    $ 2   H v H r
?
     ‹    
r
D E G H I J K J L
:  [  

 :  . 
0      (      + $ 
    
 R  8
  
R 2       
F 
?
 . R $     
 ( (    $ 2        . R $   8
  
 (      (     $ 2     $ 2     2  R   2 
 (     .  0  

 Œ $ 2 (   0 2         ‹    
        ‰  
 
 $  
0  ‰ 8        ‹  2 

Ž 
?
   8
  ‹    
$      2  

0    G R 2  c   $   &
0 2     G       2 . 
    0 2     2      (
   
 R         
?
     ‹    
  $  $ 8
   &          R 
  c     ‰ 
 $   .   

 R    
 &    .  
:     2        (    2 &  2 2   R 
     
   
 R    
 ( v r  v r . R     @      2 0  2
. 
$ (   $ 2        N     
[  R 2   $    
H r R     R  2 . 
$    :  $  G     c  F   8

  (  2          R  2 (  2 .       
 R    

R 2       
Š
     .  0   + $      
   
 $  
0   

 
  .  2  G     .  0    
 &  . R       ( 8
  2       R       R      $
  2     .  2  
:   R      2    R  2          .  
    

 ( H r 
  .   2   
    R     2 2   R 
 
    F   
  
  .  G   $  G     R        R  8
2    
[     
      2 2   R 
       v ‘ .   8
    
   :          c     [     .    R  2 (  2 .
   2  .  

0    ‰   (   2     + $      

:  [  

        .    $ 2     . 
0    
 (    
 R    
R 2        :          . 

       
 R    R    (  2  $ 2 (   0 2   
0
   2  &  $ 2 R         .    ( F   
   :  $  G
     .  . 
 G R  2       L    
 
     
 2 8
  2   [   [     R  2 (  2 .    
 R    
 (   
R     
632 Aplicaciones






     
 
    


  
 
 

 




           "  " % ' ( % +  -   % 0 (  3 4    + + 0  5
 ( +   % ( 8   %    ; 3  >  0 % ' % '  4  (  @ % 0 ;  4  @
- 0 4  ;   % + D   3  (    " ( + % " > ( 8  % % '  0  @
I      J % '  0 ; ( 5  4  +   % 0   0  % '  (   4 (  >
 J + 4 J (   5 4 ( " 0  5 ( + ( R 4 + % ( % %  ; 3 % %  (  ' 0  T 
4  (  @ % 0 ;    ; 3  0 (    U
V  0 % 0 (   >   +  " % '   4 0 5 0  (  4  +   % 0    J
0 ; ( 5  + D [ U \ 3 0 ^   + 3  4 ; 0   0 ;  % 4  U ` ' 0 + ' 0 5 '
4  +   % 0    ( + +     %  " 8   ( +  % '  + > + %  ;  ( +
(  +  "  + 0 5   " J  4 % '  "  %   % 0    J + ; (   + 4 J (  
"  J   % + U h    T  4 D   % '  5 ' % % ' 0 + 4  +   % 0  
   " 8   ^   + + 0 T  J  4 % '  3 4 3  +   J + 4 J (  
5 4 ( " 0  5 D 8   ( +  + 4 J (   5 4 ( " 0  5    " + ;  ( @
+ 4  +  J 5   8 (  ( 3 3  ( 4 (    4 ( % '  4 % ' (  R     @
 (  0  J  4 ; ( % 0   U
o
+ % '  " ( % ( + 0 p  0 + ( 3 4 0 ; ( 4 > J (  %  4 0  % ' 
  ; 3 % ( % 0   (    + % + D   + % " 0  " % '   T   % 0  
 J (   4 (  > + 0  5 + ; (    4 4  +   % 0   +  J 0 ; @
( 5  + U r  4  3  ( %  " % '    ( + + 0 R  ( % 0    J 0 ; ( 5  +
+ 0  5 " 0 u  4   % 4  +   % 0   +  4 +  (   + 

U v D v U w v D
v U \ w D v U

\ (  " v U v x +  (   +   4 4  + 3   " 0  5  0 % '
[ U \ D

U x D v U  D v U  (  " v U \ 4  +   % 0   + y 3 0 ^   + 3  4
; 0   0 ;  % 4  z U
90
92
94
96
98
100
0.06 0.12 0.25 0.5 1.0
accuracy
%
scale
min factory accuracy
soft colour-texture descriptors method
 { | } ~     € € } ~  € ‚ ~  ƒ } … † ƒ ‡ ƒ ˆ  †  ƒ €  …  ƒ ‰
` '  0  I      J % '  +  (    T  4 % '  (   @
4 (  > 0 + + '    0  R 5 4 

U ‹  (   +

U v (  " v U \ w
( 4     > +  3 ( 4 ( %  " 8 > (    +   J \ Ž  J (  @
 4 (  > U ` '  v U \ w +  (   + 4 3 ( + +  + % '  J (  %  4 >
 0 ; 0 % + 0  5 (  ( ;   %  J " ( % (

x % 0 ;  + + ; (    4
y ;  4  % ' (      4 "  4  J ; ( 5  0 % "  z U ` ' + D
[ U \

U x v U 
o
 - 0 + 0 % 0   \

 [ \

 [ \

 [
` 0    ^ % 4 (  % 0  

v ‘ [ \ w v  ’
“
 ; 3 U  J J  ( % 4  + \ w \ v x [ v

w v
“
 ( + + 0 R  ( % 0   v v v
   "  # % ' ( * ( + , . / , / , 0 .
1 2 4 6 2 8 8 2 ; = > @ 4 C ; E
` ( 8   \ G ` 0 ; 0  5   + % +  J % '  0  + 3   % 0   3 4  @
  + +  + + 0  5 +  T  4 (  0 ; ( 5  4  +   % 0   + U
% '  0 ; ( 5  4  +   % 0    (  8  4  "   " J 4  ; [ U \
%  v U  3 0 ^   + 3  4 ; 0   0 ;  % 4   0 % '  % ( + 0 5  0 R @
 (  %    +   J " 0 +  4 0 ; 0  (  % 3    4 y ‘ w U w Ž z D   ; @
3  > 0  5  0 % ' % '  J (  %  4 > 4  - 0 4  ;   %  J 5 4 ( " @
0  5 3  4 J  4 ; (    U
o
 +  0  %  4  + % 0  5 0 + % '  4  +  %
 8 % ( 0   " + 0  5 % '  v U w +  (   U h  4  D  0 % ' ( 
( ;   %  J " ( % ( J  4 % 0 ;  + + ; (    4 D % '  (   @
4 (  > (  ;  + % 4  ; ( 0  +  - (  y    > " 4   3 + v U \ Ž D
J 4  ; ‘ ’ U x Ž %  ‘ ’ U  Ž z U
o
4  +   % 0    J

U x 3 0 ^ @
  + 3  4 ; 0   0 ;  % 4  0 + (  +  ( 5   "  '  0   %  4  @
"   " ( % ( + 0 p  (  " % 0 ; 0  5   + % + U
` ( — 0  5 0  %  (     %    0 ; ( 5  4  +   % 0   +
% '  3 4  T 0  + % 0 ; 0  5 % ( 8  

0 + (  % (  0 p  " ( + 0 %
0 + + '    0  % ( 8   \ U
r 0 % ' % '  0 ; 3 4  T  ;   % 0  % 4  "   " + 0  5
% '  +     4  +   % 0   + % '  3 ( 4 (     0 p ( % 0   ( 3 @
3 4  (  ' 0 +   %    "  " 0 J    '  +  v U  3 0 ^   + 3  4
; 0   0 ;  % 4  U š  T  4 % '    + + D 0 J   3 4  J  4 %  5 0 T 
;  4  3 4 0  4 0 % > %  5 4 ( " 0  5 3  4 J  4 ; (     4  
% ' 0  — %  ( " " ;  4  + 4 J (   0  + 3   % 0   % ( + — + D 0 %
0 +  J 0  %  4  + % %   ( 4 4 >  % ( + % " >  J 3 ( 4 (     0 p ( @
% 0   (  " +  % '  4  +  % + J  4 J % 4  "   0 + 0   +
     4  0  5 % '  0  + 3   % 0   + > + %  ; U
H I


 

  K
 
 M  O


 
  



›


   
œ
( 4 (     0 p ( % 0    (  8  ( 3 3  0  " 0  %  " ( % (  4 0  @
+ % 4  % 0   + 5 0 T 0  5 4 0 +  %  %   " 0 u  4   % +  '  ;  + G

U Q 0 T 0 " 0  5 % '  0 ; ( 5  " ( % ( 0  % 
n
+ 8 @
0 ; ( 5  + y ( + ; (  > ( +   ; 3 % ( % 0     "  + 0  @
T   T  " 0  % '  3 ( 4 (     0 p ( % 0   z U S (  '   " 
3  4 J  4 ; + % '  % 0    ^ % 4 (  % 0   (  "   ; 3 % ( @
% 0    J J  ( % 4  + %  0 % +   4 4  + 3   " 0  5 + 8 @
XVI Jornadas de Paralelismo, JP '2005 633
                      "   %
      
(
       -    1  3 3 5
   "        3    1      > ?
@ ? B    "         3            
   ? F       I            5  
  3   P               "
"       "        3       ? V   
   1  3 X   I              
"         
(
       -     3   %
 1     3       ? B  
(
         
          >  "   ^          
 " 3   ? V    
(
         -  %
                3   3     
       -        "     
 3                 3       ?
    3   P       > -          %
         -    f  3         f   
-   > h i j   3    -          "    "   
  "    1 P           3   "       3   ?

o p q r t u   v  q o r t w x o z t { | w v } r | t r ~ w t x t v x o } | 
B   3   P              €     
               -       f   €     
    3  3     3      1     @ ‚ ? B    
    "            3     3 ‚       
  P           3           
   ? B       € 5      "   „    
B    "    ? B          "   3     3 3  
  1     3           -          
           3   "  3       %
 3      
X
 
Y
 P        1  
3     "      %  3      %    3    
     3  ? B   I   3           5 
    
     "   3     P            
    1     † ‚ ?

o p q r t 
o z t t  x r { v x t w { | w r t p o ~ x t r t w 
B   3   P                   € 3 
-        € %      ? B       3      
           5             " 3 
"      €   >                    %
"             5        3   3  
     3       ? B    I   1          
     3 3  3 X   €           3   3 5
  €     3   "             " "       ?
V  1  3 3 5            3 5          %
             3    3   P    
    3 3  3 X         f  €         %
"       ?
      3 3  3 X   -                 
€           "    3         -     
 
( ˆ
F 
(
     
ˆ
    F   "    ‚   " -    ?
‰
 3         3 3     "     3        %
   -                ? B 5    3 3 5 I
 3 3            3            
"        3 3 5 I   5   f        %
                     ‚        
 5    ? B       3   5     "   €  3    3   %
        3 3 5 €                      %
              -   >  ? B      %
       "  3         1   3 5    3 3  
   5         1   3 3 5 €  3  "       3 3  3 X  %
         3                 ?
Œ
3   %
      f      5         € 3            %
 3 3  3         ?
‰
  Ž          3         €    
     "     3         " -    I      
ˆ
’
(

ˆ
   3 3  3 ’    3
(
    ‚ h  j  
( ˆ
F
634 Aplicaciones


    

                ! # %    '   )   
 + + ' )  ,      '    0 2 ' 5  ' 6     ' + +     ' ' 
0   %    '   '  , @    + +  + @  '   0  ' 
, 0 5   '  0   %     '     J 5 K  + '   +    
  ) '  O !
'  % Q

R


 J

     '   )    +  5      
 '  @    + +  +  V    ' ,    + ,       J    J   J
Y
 J  '     @  '   0  ! Z  J    J  J  ' ,  
 % 

  '   )    5    ,       '      J  '

  %   6  %  % @    '  0      ' 0 0 ,      ' 
) %   %    0  O  J '  % '        '     J
 c  % ' 0 '   ' ,    ) '  O   ! # %     ' ,      Q
 J  +  ' 0 ,  % '   %  @    + +  +  V    '  ,     
J  @  J  '  %    ) '  O          @    '  g
0    ! #  +   0       +    J        ) %   %
  J  ' 5           J   %  +    @ '    5 +    0 
 '   %   6     + @    + +  +  V    '   %  @  '     
'   0      ' J   !
 '   %   l @    0    m    + K )  ,   J  % 



   ,   '   + ,     + '     J    %  o
p


 5 g
'    '  K

   + +  +
p
  %      ,    o  ' , @    % 

' + K    %     6      K '  R  +     ! # %   0  g
 %      ' 0 @ '   J '  s

' J   5   '  ' 
 %  0  % 


     ' J  !    % ' J     u ,  @ @  J
)   % 

   , 0    5  g @  '     '   

o x V  J

o '  y
p


0  0 '  K !
p
+ + ' J       g
    '     J ,       J   J

o 5   %    
  ) '  O ! # %   '   )     '  @    + +  +  V    '  g
   + +  J   %   + ,        % 

 6     '

! s !
# %  m     l @    0    '      J '  0    ,  
 ' 0 @ ,     0   ) %  ,     ' )  , 0 g
5   '  ' J   ! # %  @    + +  +  + '    % 0  '    g
 @ ' J  )   %  %     ' J   %  0  '  @    + +  +  V  g
  ' Q 5    J '  %  J      5 ,   ' '  ) % ' +   0   
 '     ' J     %   + ,     ! # %  ' J       K
' ,   %    +   l       '  J  ' 0 @ ,     ' '     g
 ,    ! ~ '    ' + ' ,    l  ,   J      @  '        
 '  % 


     ' J  ) %   % m  + + K @    '  0   % 
 ,        J  ! #  5 +    J m ,     % ' )  % 
   , +    '   0      ' + ,   '  '   ! s Q

! €  J  ! 
@  l  +  @   0  + +  0     !
  ,     % ' )   %   @    + +  +  V    '     %  
   ,     ' ) %  )  ,   0 '    % 

 ' J   !
Z    %   6   ,       @    + +  +  V    ' ) %   % 
  u ,    J   0    , J    c  0  + +     ' J  ! # %  
   %    0    0          %   0     u ,    g
  '  


     ' J  !   ' 0  %   @ '   '  6   ) Q
 %   ! s    ' + ,   ' J '   '   ,      5    ,    % 
  0    J  J ,   s  ' J     „   0  + +     ' J  !
0
2000
4000
6000
8000
10000
12000
0 5 10 15 20
time
in
milliseconds
number of nodes
3.2 pixels per millimeter
1.6 pixels per millimeter
0.8 pixels per millimeter
 † ‡ ˆ ‰ Š ‹   † Œ †  ‡ Š Ž   ˆ ‘ †   †   Š ‰ ’ ˆ ‰ †  ’  ˆ “ ‘ Š ‰ ”
   0 '   ' J    ' , + J +   J  '   %   6    0  
, J    %  +  0   '   c  0  + +     ' J  Q 5 ,    + ,  g
   '  s  ' J   '  0 '       ' ' 0 ,  %  l @  g
  6    ' ' 0    + + K  J  @     + + K ! # %  @  '  '  K @ 
      '  K  % ' , + J 5   u ,  @ @  J )   %      ' g
 5 +  , 0 5   '  ' J     ' 0  %    @ '    '  6   )
'    ' ' 0    J  @     +  '    ! # %  5      +  g
  ' 5   )      ,    K  J , 0 5   '  ' J    
  %   6  J ,    ' ,  ' J    J     ' + ,   ' ' 

! € @  l  +  @   0  + +  0     ! # %    ' m ,     '
  , J    %    0  +  0   ' + K   J    s 0  + g
+     ' J   '  ' 0 @ ,      %  0     J ,    
  J ,   J , 0 5   '  ' J   !


'   ' J   Q '  
   ' + ,   ' '   !  @  l  +  @   0  + +  0     Q   5 
 % '     )  @ +   '    ' J ,   0 '     @     '
   O    J J    '  '  ,        J  !
     ' J  l @    0   )       J  %   ,     
  J   @ @ +      ' ,    %  % + K @    '  0  J
0   %     % 

 c  


 + ,     ! # %   0  g
 %       + +  J  x K  J     J   + '     J    % 
Y
' 0 @ ,  
Y
    '   % 

' + K    %     6   g
   K '  R  +     ! # %    + ,     Q '      J  '  , g
@    ' 0 @ ,      O  Q    ' 0 @ '   J '  €  ' J  
 u ,  @ @  J )   %    +   ' 5  g @  '     '     s Q 
o x V  J

o '  y
p


0  0 '  K ! # %  ' J  
        '     J ,   


K       ) '  O
) %   % @  ' 6  J   s o 5 '  5  J )  J  % ! # %    + ,  g
       @    m  0   %   5 K 


'      J
 '  , @    ' 0 @ ,    @ @ +      '   J   0 ,  %
0 '    l @    6   % 


   ,   ' ! Z   %  %    l g
@    0   )    K  ' J     0         ) '   % g
) %  +   ' ,   %  % + K @    '  0  J  + ,       '   % 
XVI Jornadas de Paralelismo, JP '2005 635
0
2000
4000
6000
8000
10000
12000
0 2 4 6 8 10 12 14
time
in
milliseconds
number of nodes
3.2 Mercurio
3.2 Hyades
1.6 Mercurio
1.6 Hyades
0.8 Mercurio
0.8 Hyades

     

      
        

      "
# % % ( * , # - * . / . 1 2 3 4 1 # , 6 8 4 # : * / 8 < > / ( @

 / . : 6 2
C 6 4 6 # F # * ( # G ( 6 C J 6 / C 6 , # 4 4 * 6 : . 3 - . 3 4 6 O P
% 6 4 * R 6 / - 2 S G 3 - - J * 2 / 3 R G 6 4 . 1 / . : 6 2 * 2 2 3 1 P
[ , * 6 / - 1 . 4 , . R % # 4 * 2 . / % 3 4 % . 2 6 2 < ^ J 6 2 . 1 - C # 4 6
1 . 4 % # 4 # ( ( 6 ( * ` # - * . / * / 2 - # ( ( 6 : * / d @ # : 6 2 * 2 - J 6
f g
h F 6 4 2 * . /

< i <
 4 . R - J 6 - * R * / 8 , . R % # 4 * 2 . / . 1 [ 8 3 4 6 m C 6
, # / , . / , ( 3 : 6 - J # - d @ # : 6 2 % 6 4 1 . 4 R 2 2 * 8 / * [ P
, # / - ( @ G 6 - - 6 4 C J 6 / 3 2 * / 8 # 4 6 : 3 , 6 : / 3 R G 6 4
. 1 / . : 6 2 S J . C 6 F 6 4 S - J 6 - * R * / 8 , . 2 - 2 . 1 G . - J
R # , J * / 6 2 R 6 6 - t 3 * , u ( @ 1 4 . R - J 6 - J * 4 : / . : 6
. / < h / : * F * : 3 # ( ( @ #  6 . / G * P % 4 . , 6 2 2 . 4 , ( 6 # 4 ( @
. F 6 4 , . R 6 2 #
g
6 / - * 3 R h h h G * P % 4 . , 6 2 2 . 4 * / % 6 4 P
1 . 4 R # / , 6 S G 3 - - J * 2 * / : * F * : 3 # ( # : F # / - # 8 6 * 2 / . -
- 4 # / 2 ( # - 6 : - . - J 6 , ( 3 2 - 6 4 2 , J 6 R 6 . 1 % # 4 # ( ( 6 ( * ` # P
- * . / <
f
6 4 , 3 4 * . # / : d @ # : 6 2 R # , J * / 6 2 C 6 4 6 # ( 2 .
, . R % # 4 6 : 3 2 * / 8 - J 6 } % 6 6 : 3 % # / :   , * 6 / , @
C J * , J # 4 6 , ( # 2 2 * , # ( R 6 # 2 3 4 6 2 - . , J # 4 # , - 6 4 * ` 6
% # 4 # ( ( 6 ( * ` # - * . / 4 6 2 3 ( - 2 < ^ J 6 } % 6 6 : 3 % * 2 - J 6 4 6 P
( # - * . / G 6 - C 6 6 / - J 6 - * R 6 / 6 6 : 6 : - . , # 4 4 @ . 3 -
# 8 * F 6 / - # 2 u * / . / ( @ . / 6 / . : 6 # / : - J 6 - * R 6
/ 6 6 : 6 : 1 . 4 - J 6 2 # R 6 - # 2 u 3 2 * / 8
n
/ . : 6 2 < ^ J 6
  , * 6 / , @ * 2 - J 6 4 6 ( # - * . / G 6 - C 6 6 / - J 6 4 6 # ( # / :
- J 6 * : 6 # ( } % 6 6 : 3 % < ^ J 6 * : 6 # ( } % 6 6 : 3 % 3 2 * / 8
- C . / . : 6 2 2 J . 3 ( : G 6 - C . S - C . / . : 6 2 2 J . 3 ( :
: . 3 G ( 6 - J 6 2 @ 2 - 6 R 2 % 6 6 : S - J 4 6 6 / . : 6 2 2 J . 3 ( :
* / , 4 6 # 2 6 - J 6 2 % 6 6 : * / - J 4 6 6 - * R 6 2 # / : 2 . . / <
 * 8 3 4 6 € 2 J . C 2 # , ( 6 # 4 # : F # / - # 8 6 . 1
f
6 4 , 3 P
4 * . , ( 3 2 - 6 4 C J * , J # , J * 6 F 6 2 G 6 - - 6 4 % 6 4 1 . 4 R # / , 6
* / } % 6 6 : 3 % # / :   , * 6 / , @ < h / - J * 2 , # 2 6 S - J 6
0
2
4
6
8
10
12
14
0 2 4 6 8 10 12 14
Speedup
number of nodes
Speedup evolution
Ideal Speedup
Mercurio
Hyades
0
0.5
1
1.5
2
0 2 4 6 8 10 12 14
Efficiency
number of nodes
Efficiency evolution
Ideal Efficiency
Mercurio
Hyades

   ‚  ƒ         
 
    
  
    "
J * 8 J ( @ % 6 4 1 . 4 R 6 : R # , J * / 6 S d @ # : 6 2 S : . 6 2 / . -
% 4 . F * : 6 6 / . 3 8 J G 6 / 6 [ - 2 - . „ 3 2 - * 1 @ - J 6 6 , . P
/ . R * , 6 † . 4 - - J # - C * ( ( G 6 / 6 , 6 2 2 # 4 @ <
 
‡
ˆ
‰ Š ‹ Œ ‡
ˆ
‹
 6 J # F 6 2 - 3 : * 6 : - J 6 4 6 # ( P - * R 6 , . R % ( * # / , 6 # / :
% # 4 # ( ( 6 ( * ` # - * . / 1 . 4 # 2 3 4 1 # , 6 8 4 # : * / 8 R 6 - J . :
- J # - C 6 % 4 6 F * . 3 2 ( @ J # : : 6 F 6 ( . % 6 : <  6 , # 4 P
4 * 6 : . 3 - # ( ( - J 6 2 - 3 : * 6 2 J # F * / 8 # 2 4 6 1 6 4 6 / , 6 - J 6
C . 4 2 - , # 2 6 # - 1 # , - . 4 @ < ^ J * 2 , . 4 4 6 2 % . / : 2 C * - J #
% 4 . : 3 , - * . / . 1 m  O m  , 6 / - * R 6 - 4 6 2 - * ( 6 2 # - # 4 # P
- * . . 1 i  - * ( 6 2 % 6 4 R * / 3 - 6 < h / - J * 2 , . / : * - * . / 2 S
C 6 . / ( @ J # F 6 ‘ 2 6 , . / : 2 - . * / 2 % 6 , - # / : 8 4 # : 6
6 # , J - * ( 6 <
 * 4 2 - ( @ S C 6 2 - 3 : * 6 : - J 6 - * R * / 8 4 6 t 3 * 4 6 R 6 / - 2
. 1 - J 6 R 6 - J . : 2 6 t 3 6 / - * # ( ( @ % 4 . , 6 2 2 6 : 3 2 * / 8
636 Aplicaciones
                  !     %  
        '   )     !     -  / -   1
2  -   '   -  %   ' 8  : 8 ;             1
-  / ! A       -  - 
B          %   '          ) 
! -  D    ' ! -   /     -  G  !
          '        !  - / -        1
-  %   ! - / ! O A  P  - Q      -   -   O ) 1
    !     %     - /       ' 
   '   /    -  / )     '  !   -  '
      '    [    %      -     
  ! - G            G  !          -  -
' ` 8 a '  !     -   '  ;    b 
 - Q  
   -   -     !        -  /     -  /
-   %  ' A b P A    P A  b  -   -       1
   - G     !   O b 
    -      -  % - !
   -   2  -     )   ;    ) 
   P A  -   -      
f
 !  / !        - g  -  -     -   
   O %   -         ! -     
)     -     ) ' -    - ' %   - 
  -  - - g !           '       %
         -     -    l  !    1
  [  !  !
n
    1
o p
B   !  ) 1
    -   G -          q    )      
            -  /  [ s       -   !
       - g  -  Q   -      -  /    -   1
 G    '             
o
    - 
o
 1
   - -       '    % - !
p
 -   B B B
) - 1         w x g      -  /        
w )  !   '  -       -    ! -  1
-  /       ! %  !  ! )     -  ) 1
%  !    )  '               %  
  ! - G    -  / '              - 
'  ;  - Q      -   -       -     1
   )     )  '    '        - ' %
! -  l -     '    -        -      
 !         -  )  ! -     -     1
  '     -    -      -    )    
        l  !     )       1
- G   -      %     !    '   /    -  /
Q   -    -   ! - / !     '       ! - 
     x     % ! -  ! %        '   
% - !
 ) - 1         P   w x g    
o
  -   %  l  P w )  B  -  -  /      O
x          ! - G         G    / -    1
'        -  /    !   A     ƒ     -  1
-  /   O
o
    -         x     -  %     1
 -          '        - g  -    '      
ƒ           -      !    -   - q  1
     / ) !         !   ! - G   1
               - -   %  ! % ! - 
-  G  -   ! - / !     '  
      '  !
   '   /    -  /     -   -  

„ … 
†
‡  

ˆ 
  †
‰ Š
 ! -  %  l %   '     )      ‹ 1
n
B
n

Π
p
B P b b A 1 b ` : A 1
n
b P 1 b   [    !   l  !
-   -      )      )   -  ' ! w
f
p
  ) 1
       !
n
   -  /
n
  ' !
p
  1
 !  -  #  - G   -  ' Ž     -  
$
 & 

 †
…

Š
 ‘ ‹  ’        
p
   x   O * , - - / 1 3 4 6 , 8 8 : ; <
4 , - : > 3 , 3 @ 8 4 / 3 / , 3 , 6 C 8 : 8 O E !  [ -     
ƒ   O “ %  l O ` : A 
 P ‘ x  G     -   O I / K / 6 > M N / 3 - > S , 4 > 6 > 1
N , 4 X : 3 / K : 8 : > 3 N / - X > @ S > 1 ^ > > @ 8 ` 1 S , 4 /
: 3 8 M / 4 - : > 3 O
p
!   !  -  O ’    #  - G   -  O
` ` ` 
 A ‘      
e g
 g O E  i
o
- /   Ž   -  O
‹  
g

j
    -  !   
o
  k  Ž      O m , 8 -
8 ` 1 S , 4 / o 1 , @ : 3 o ` 8 : 3 o 4 > 6 > 1 8 - , - : 8 - : 4 8 : 3 - X /
t u v w , x 8 M , 4 / O P   B )  -  
n
 '    
p
   ‹  /  - -     B   /
f
     -  O
   -  O
p
  /   O P b b 8 
  ‘
f
 w -     O * , 1 , 6 6 / 6 z : 1 - ` , 6 | , 4 X : 3 / }
~
` 8 / 1  8 o ` : @ / , 3 @ - ` - > 1 : , 6 S > 1 3 / - ^ > 1  / @
M , 1 , 6 6 / 6 4 > N M ` - : 3 o O
o
B 
p
   O ` `  
 8 ‘
f
 w -  O E 
f
 G !    
p

o

p
 1
        O * z | , 3 @ | * u }
~
t > N M , 1 <
: 8 > 3 > S m / , - ` 1 / 8 O
n
        
p
       O
Ž  
O “  P O ` ` ; 
 ; ‘ E  i
o
- /   Ž   -  O      
e g
 g O
    
f
 ) 
g
       - 2 
p
i  g O
~
3
: N , o / 1 / o : 8 - 1 , - : > 3 N / - X > @ S > 1 4 / 1 , N : 4
- : 6 / : 3 8 M / 4 - : > 3 M ` 1 M > 8 / 8 O P b b
n
 '   
     - 
n
   ) 
f
 -  -   Ž -  - 
Œ 
n
f
Ž  b  O
e

n
   O      O P b b 
 : ‘ !  ‘ ’ ’ % % %    - 1 '      / ’    ’   - 1 1
!   ’   - 1     !   O | * u }
~
N / 8 8 , o /
M , 8 8 : 3 o : 3 - / 1 S , 4 / 8 - , 3 @ , 1 @ O #  - G   -  '
      ` ` 8 
XVI Jornadas de Paralelismo, JP '2005 637
   
   

     
  
    
         
 
       
       

        

 
     
       


  
  
 
   

     

      
   

 
   
 
  
    
 
    
     
 
        

       
        
         
"  $   (  ( + , ( +
-

0 
(    ( + , (  " , 
   3
$  4 (  +      6  " +  
9 ( :  $  9 
 ( $ $ (   4
 6
4 (   (  , ( <  + ( +  ( $ $ (   0  +  
   
   

     
        
         
        
         

    
       
      


    

       
  
 

   

 
     
        
       
"  $   (  ( + , ( + A B "      ( + , (  " , 
   $  3
4 (  +      6  " +  
9 ( :  $  9 
 ( $ $ (   4
 6
4 (   (  , ( <  + ( +  ( $ $ (   0  +  
638 Aplicaciones
Parallel implementation of CTC algorithm for a customer
fidelisation problem
José I. Martín, Jesús Mª Pérez, Javier Muguerza, Olatz Arbelaitz, Ibai Gurrutxaga
Computer Architecture and Technology Department
The University of The Basque Country
20018 Donostia
j.martin@ehu.es, txus.perez@ehu.es, j.muguerza@ehu.es, olatz.arbelaitz@ehu.es, i.gurrutxaga@ehu.es
Abstract
This paper presents a parallel implementation of
the CTC algorithm. This algorithm has been
developed in our research group to build
classification trees. The CTC algorithm builds
classification trees based on the consensus among
several proposals made from different subsamples
extracted from the training set. The algorithm has
shown to behave better than a tree built from a
single sample from the discriminating capacity
point of view, and besides, it has larger structural
stability, so that we can state that the explanation
given to the classification made is more robust. In
order to face the computational cost of the CTC
algorithm, we have developed a parallel version
based on MPI. A customer fidelisation problem
has been used in order to evaluate the
performance of the parallel implementation. The
speed-up achieved with the parallel algorithm is
linear to the number of processors.
1. Introduction
When solving machine learning problems, the
main focus has been done in reducing the
achieved error rates. This is a very important
aspect but it can not be forgotten that there are
many real domains such as illness diagnosis, fraud
detection in different fields, customer’s behaviour
analysis (marketing), customer fidelisation, ...
where it is not enough to obtain high accuracy in
the classification, the comprehensibility of the
classifier is also necessary [1]. This kind of
problems need the use of classifying paradigms
that are able to give an explanation, for example
classification or decision trees.
On the other hand, due to problems such as
class imbalance or non uniform costs of the errors,
sampling (undersampling) has to be used. This
sampling affects severely the behaviour of the
classification algorithms [2]. Classification trees
are not an exception. Classification trees induced
from slightly different subsamples of the same
data set are very different in accuracy and
structure [3]. This weakness is called unsteadiness
or instability. The stability is of capital importance
in domains where comprehensibility of the
classifier is necessary [1]. As Turney found
working on industrial applications of decision tree
learning, “the engineers are disturbed when
different batches of data from the same process
result in radically different decision trees. The
engineers lose confidence in the decision trees
even when we can demonstrate that the trees have
high predictive accuracy” [4]. How could we
obtain stable classifiers even if sampling is
required? An easy way would be to build multiple
classifiers creating several subsamples with
changed distribution by undersamplig the original
data set. If the number of generated subsamples is
chosen adequately, most of the information in the
original sample will be covered. A classifier can
be built with each one of the subsamples. The
classification of new examples can be done by
assigning the most voted class (similar to bagging
[5]). This can be a good option in some cases, but
not in areas where explanation is important,
because as many different trees as subsamples
would be built. It is clear that “while a single
decision tree can be easily understood by a human
as long as it is not too large, fifty such trees, even
if individually simple, exceed the capacity of even
the most patient” [1].
To face the problem of need of explanation
when sampling is used we have developed the
CTC (Consolidated Trees’ Construction)
Algorithm. The CTC algorithm creates several
subsamples from the original training set, but
opposite to other algorithms that build multiple
trees (bagging, boosting), it induces a single tree,
therefore it does not lose the comprehensibility of
the base classifier. Previous works [6] show that
CTC algorithm has greater discriminating capacity
and structural stability than a single tree built
based on the well known C4.5 algorithm [7].
Building classifiers based on several
subsamples increases the computational cost and
this cost is even larger working with large
databases [8]. Within this context we propose in
this paper a parallel version of CTC algorithm,
able to obtain the same kind of results obtained by
the serial version but scaling the time with the
number of used processors.
The paper proceeds describing how a single
tree can be built from several subsamples, CTC
algorithm, in Section 2. A brief summary of
previous results is presented in Section 3. Section
4 is devoted to define the characteristics of the
real problem that is treated in the paper. The
parallelisation of the algorithm is described in
Section 5. Section 6 presents the experimental set-
up (used methodology and characteristics of the
parallel system) together with an analysis of the
performance of the parallel version of CTC.
Finally, Section 7 is devoted to show the
conclusions and further work.
2. CTC algorithm and previous results
Consolidated Trees’ Construction Algorithm
(CTC) uses several subsamples to build a single
tree [6]. This technique is radically different to
other learners based on multiple subsamples such
as bagging, boosting, etc. The consensus is
achieved at each step of the tree’s building
process and only one tree is built.
Generate N_S subsamples (Si
) from S with R_M method
CurrentNode := RootNode
for i := 1 to N_S
LSi
:= {Si
}
end for
repeat
for i := 1 to N_S
CurrentSi
:= First(LSi
)
LSi
:= LSi
- CurrentSi
Induce the best split (X,B)i
for CurrentSi
end for
Obtain consolidated pair (Xc
,Bc
), based on (X,B)i
, 1 <= i <= N_S
if (Xc
,Bc
) != Not_Split
Split CurrentNode based on (Xc
,Bc
)
for i := 1 to N_S
Divide CurrentSi
based on (Xc
,Bc
) to obtain n subsamples {S1
i
,…,Sn
i
}
LSi
:= {S1
i
,…,Sn
i
} ∪
∪
∪
∪ LSi
end for
else consolidate CurrentNode:=leaf
end if
CurrentNode := NextNode
until ∀
∀
∀
∀i, LSi
is empty
Algorithm 1. Description of CTC algorithm.
The different subsamples are used to make
proposals about the feature that should be used to
split in the current node. Any criteria used in
decision tree’s building processes can be used as
split function: gain ratio criterion (C4.5 [7]), χ2
(CHAID) or Gini Index [9]. The decision about
which feature will be used to make the split in a
node of the Consolidated Tree (CT) is accorded
among the different proposals. The decision is
made by a voting process node by node. Different
voting procedu
res can be used: standard voting,
weighted voting or other strategies. Based on this
decision, all the subsamples are divided using the
640 Aplicaciones
same feature. The iterative process is described in
Algorithm 1.
The algorithm starts extracting a set of
subsamples from the original training set
(Number_Samples, N_S). The subsamples are
obtained based on the desired sampling technique
(Resampling_Mode, R_M). For example, the class
distribution of the original training set can be
changed or not, examples can be drawn with or
without replacement, subsamples of different sizes
can be used ⎯100%, 75%, 50%, … of the
original training set ⎯, etc.
Decision tree’s construction algorithms divide
the initial sample in several data partitions. In our
algorithm, LSi
contains all the data partitions
created from each subsample Si
. When the process
starts, the only existing partitions are the initial
subsamples.
The pair (X,B)i
is the split proposal for the
first data partition in LSi
. X is the feature selected
to split and B indicates the proposed branches or
criteria to divide the data in the current node. Xc is
the feature obtained by a voting process among all
the proposed X. Whereas Bc will be selected
taking into account all the proposed values (B)
and using different heuristics depending on the
kind of variable: discrete or continuous. For
example, when the variable is discrete a branch
for each of the categories can be generated or
categories can be grouped to find the best
combination. When the variable is continuous, a
cut value can be calculated based on the mean,
median or other statistical criteria or several cut
values can be proposed generating more than two
branches.
The process is repeated while LSi
is not
empty. The Consolidated Tree’s generation
process finishes when in the last subsample in all
the partitions in LSi
, most of the proposals are not
to split it, so, to become a leaf node.
Once the consolidated tree has been built, it
works the same way a decision tree does, so, new
examples can be classified the same way they are
classified in a single classification tree and other
operations such as pruning can also be done the
same way. This way, the explanation of the
classifier is not lost even if several subsamples are
used to build it [10].
3. Summary of previous results
The algorithm has been tested in previous
experimentation with 20 databases of real
applications: Breast
-W, Heart
-C, Hypo, Lymph,
Credit-G, Segment210, Iris, Glass, Voting,
Hepatitis, Soybean-L, Sick-E, Liver, Credit-A,
Vehicle, Breast-Y, Heart-H, Segment2310, Spam
and Faithful. All applications but Faithful belong
to the well known UCI Repository benchmark
[11]. The Faithful database is a real data
application from our environment, centred in the
electrical appliance’s sector, and its characteristics
will be described in next section.
For the results presented in this section the
options selected for CTC have been mostly based
on the standard options of C4.5.
The used methodology has been to execute 5
times a 10-fold cross validation [12]. In each of
the folds of the cross-validation, a C4.5 tree has
been built and to build CT trees 100 subsamples
with 75% of the original training set have been
drawn without replacement. CT trees have been
built with N_S: 5, 10, 20, 30, 40 and 50.
In order to obtain two systems with similar
complexity level, both, consolidated trees (CTC)
and C4.5 trees, have been pruned with the pruning
algorithm of the C4.5 Release 8 software.
Figure 1. Average error rates for CTC and C4.5.
The graphic in Figure 1 shows the average
error rates (20 databases x 5 runs x 10 folds)
achieved for C4.5 and CTC in the described
conditions. The values in the horizontal axe
represent different values used for N_S parameter
to build CT trees.
14,80
14,90
15,00
15,10
15,20
15,30
5 10 20 30 40 50
N_S
Error
CTC C4.5
XVI Jornadas de Paralelismo, JP '2005 641
The obtained results show that when 10 or
more subsamples are used to build CT trees, CTC
algorithm achieves smaller error rates than C4.5.
The obtained difference increases with the number
of samples used to build CT trees. So we can
conclude that when N_S is 10 or greater CTC
algorithm has greater discriminating capacity than
C4.5.
25
30
35
40
45
50
55
60
65
70
5 10 20 30 40 50
N_S
%
Common
CTC C4.5
Figure 2. Average of %Common for CTC and C4.5.
Relative to the explanation we have observed
that the common structure (relative to their size),
%Common, for CT trees increases with the
number of used subsamples. This means that the
CT trees tend to have a larger common structure
when N_S increases. It seems that from a certain
value of N_S parameter the trees obtained with
CTC algorithm will be always identical (see [10]).
This tendency can be observed in Figure 2, where
the percentage of common structure existing in a
set of compared trees is represented in the vertical
axe and different values for N_S in the horizontal
axe.
Figure 2 shows the values %Common for CTC
(rhombus), and C4.5 (dashed line, N_S parameter
does not make any sense in this case). This way,
for each case an idea of the percentage of the tree
that remains common is given.
With the presented results we can state that
CTC algorithm has greater discriminating capacity
and greater structural stability than C4.5 and, as a
consequence, CTC is an adequate method to solve
the customer fidelisation problem.
4. Faithful database
The Faithful database belongs to a
manufacturing company of the electrical
appliance’s sector. The database contains
information about the customers of the company.
Data mining techniques need to be used in order
to know the characteristics and necessities of the
final customers of the company. This information
will be used to build a plan to turn customers
faithful to the brand in the future and therefore
increase the sales of the company. The aim is to
be able to obtain different user profiles and their
characteristics.
In this project the customers have been
divided in 4 profiles: faithful (customers that have
repeated purchase during the time), multi-product
(customers that, in a single purchase, have
acquired many products), unfaithful (customers
that have not repeated purchase in long time) and
others (sporadic customers). At the moment the
unfaithful customers are very few because the
database is very recent and the company is
interested in repeating the study in the future.
In order to design the right strategy in this
kind of situations it is very important to
understand the customer. That is to say, it will not
be enough to classify the customer within a group
if no explanation about the reasons is given. This
information will help the corresponding
department to make the good decisions so that
with the time the profile of customers changes
(improves) and most of them become faithful.
From this point of view CTC algorithm is
adequate to solve the problem.
On the other hand, the data set has 1,200,000
examples with 50 independent variables that
contribute to the report with information of
different nature about the customers: personal
information (age, sex, etc.), number and kind of
bought devices, dates of the purchases, etc.
This is a dynamic database. In one hand, the
number of examples will increase as time passes,
and, on the other hand, the information in some of
the examples will vary as the customers make new
purchases. If new classifiers are going to be built
as new data is generated, the use of CTC
algorithm can be too costly. The parallelisation of
the algorithm is a way of reducing this cost.
642 Aplicaciones
5. Parallel algorithm
As we have explained in Section 2, the CTC
algorithm bases its decision to consolidate a node
of the tree on proposals made by each one of the
subsamples (pair (X,B)i
in Algorithm 1). A voting
process among all the split proposals determines
the consolidated split (Xc,Bc). The decision affects
to the next partition of every subsample. As the
example in Figure 3 shows, the development of
the parallel algorithm has been centred in this
point. If compared to the serial algorithm, it has
the advantage that the load of calculating the split
proposals for each node is divided among several
processors.
Figure 3. Exampe of building a CT tree in parallel.
The process of building a CT tree is based on
a master/worker model. The master deals with all
the sequential part. That is to say, it covers the
tree that is being built and centralises the
information needed to consolidate a node. On the
contrary, the workers make their calculations in
parallel. With this aim, before starting the
process, the master communicates two values to
each worker (c0 in Figure 3): N_S, number of
samples to be considered when building a tree,
and N_W , the number of existing workers. This
way a static load balancing is done, where each
worker assumes the treatment of N_S/N_W
subsamples. From now on the parallel process
starts. For each node the treatment of the
subsamples will be done independently in each
worker and the proposed split, (X,B)i
,
communicated to the master. When a worker
sex:{m,f} age:cut=33 sex:{m,f}
CT Tree’s
Progress
• • •
sexC:{m,f}C sexC:{m,f}C sexC:{m,f}C
sex
m
age: cut=28 age:cut=30 color:{r,g,b}
ageC:cutC=30 ageC:cutC=30
ageC:cu
t C=3
age
f f f
· ·
·
·
·
·
·
·
·
color:{r,g,b} not-split not-split
not-split not-split
not-split
Finish Finish
≤30 >30 ≤30 >30 ≤30 >30 ≤30 >30
f f f
f
f
f
m m m
f
sex
m f
sex
m f
age
≤30 >30
• • •
• • •
• • •
• • •
• • •
• • •
• • •
• • •
• • •
•
•
•
•
•
•
•
•
•
Decision
Decision
Decision
• • •
Master
• • •
• • •
• • •
• • •
• • •
• • • c0
c1
c2
cn
Worker 1 Worker p
•
•
•
XVI Jornadas de Paralelismo, JP '2005 643
treats more than one subsample, after processing
all of them, the worker sends to the master the
information related to every subsample (proposed
variable and split). Based in all the proposals the
master determines the consolidated split (Xc,Bc)
and sends it to each worker so that all the
divisions are made based on the same criteria (bi-
directional communication, worker→master and
master→worker represented in Figure 3 with ci
1≤i≤n ). The decision made in the master could be
not to split the node. This decision will be
communicated to the workers using a special
code. The master continues at this point with the
sequential execution and passes to the next node.
The process is repeated until the tree is completely
built: all LSi
are empty.
MPI functions (concretely the MPI_Bcast and
MPI_Gather primitives) have been used for
communication and synchronisation [13].
The obtained results, final tree, error rates, etc.
are identical to the ones obtained in the sequential
version. Evidently the time needed to build a tree
will be considerably reduced. This will become
more important as the size of the database
increases.
6. Experimentation
The experimentation has been done in a cluster of
8 nodes. Each node has an AMD Athlon MP
2000+ processor (1.6GHz), with 512KB of cache
memory each and 1GB of RAM. Operating
system is Linux. MPI implementation is MPICH
[13]. Nodes are interconnected using a switched
Gigabit Ethernet network.
In the experimentation, 48 subsamples
(N_S=48) have been used to build the
consolidated trees. Previous experimentation has
shown that for N_S parameter, values in the rank
[30..50] achieve a good trade-off among quality of
results and computational cost and we have
experimented with 48 subsamples so that the
number of samples treated in each workers has
always been identical. In order to analyse the
scalability of the proposed parallel solution from
the computational cost point of view, we have
experimented with problems of three different
sizes: samples with 25,000 examples (25K),
100,000 examples (100K) and 300,000 examples
(300K). The baseline experiments for
performance comparison have been performed
using the sequential program in one node of the
machine. For each size and number of processors
4 executions have been done using different data.
The results presented in this section are the
averages of the 4 runs. Only the part related to the
CT tree’s building process has been taken into
account.
Results in Table 1 show the execution time for
the three sizes (Te ), as well as the speed-up
achieved when executing the parallel version of
the algorithm for 2, 4 and 8 workers. The
execution times for 1 CPU are the ones achieved
with the sequential version, except in the case of
300K. In this case, the serial program could not be
executed in the machine due to problems with the
size of the memory and the data. The value has
been estimated based on the previous speed-ups.
The data show that, independently of the size of
the problem, the achieved speed-up is practically
linear with the number of used workers.
Table 1. Execution time and speed-up for problems with different sizes.
25K 100K 300K
CPUs Te speed-up Te speed-up Te speed-up
1 0h 23’ 47’’ 1 6h 31’ 34’’ 1 46h 18’ 12’’ 1
2 0h 12’ 15’’ 1.94 3h 23’ 30’’ 1.92 23h 57’ 38’’ 1.93
4 0h 6’ 14’’ 3.81 1h 41’ 06’’ 3.87 11h 48’ 55’’ 3.92
8 0h 3’ 14’’ 7.35 0h 50’ 35’’ 7.74 5h 53’ 25’’ 7.86
We have studied how the execution time is
divided in serial execution, parallel execution and
communication/synchronisation. As an example
the graphic in Figure 4 shows, for the
experimentation with 25K subsamples, the time
distribution among the parallel part of the
algorithm (Tworker), the serial part of the
algorithm (Tmaster) and the times associated to
the communication and/or synchronisation
(Tcom_sinc). It can be observed that the program
spends most time in the parallel part of the
execution (92.79% average for different numbers
644 Aplicaciones
of workers), what is in agreement with the speed-
ups presented in Table 1. Besides, the serial time
is always under 0.3%, negligible if compared to
the total execution time, and does not increase
with the size of the problem. Tcom_sinc time
varies in an interval among 5% and 10%
depending on the number of workers. The
behaviour for larger problem sizes, 100K and
300K, is similar; concretely the parallel part of the
execution is in average 94.73% and 95.69%
respectively.
Both, the results shown in Table 1 and the
ones appearing in Figure 4, prove the scalability
of the algorithm for the sizes of the problem we
have analysed.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2 4 8
CPUs
Tcom_sinc Tworker Tmaster
93.47 90.46
94.45
Figure 4. Time distribution percentages for 25K size
problem.
Table 2. Load distribution of the different experiments
in seconds.
25K (a)
CPUs Tcalc (s) Tworker (s) ± σ
2 692.05 691.56 ± 3.89
4 347.28 346.80 ± 2.10
8 173.60 173.03 ± 1.35
100K (b)
CPUs Tcalc (s) Tworker (s) ± σ
2 11,435.39 11,432.21 ± 63.38
4 5,744.62 5,741.37 ± 23.51
8 2,869.10 2,865.92 ± 14.57
300K (c)
CPUs Tcalc (s) Tworker (s) ± σ
2 81,243.99 81,206.76 ± 664.76
4 40,626.18 40,599.65 ± 284.46
8 20,269.66 20,248.28 ± 153.15
In order to analyse the load distribution
among the workers, we present in Table 2 the total
calculation time in seconds (master + slowest
worker), Tcalc, and the average calculation time
of the workers, Tworker, for problems of 25K (a),
100K (b) and 300K (c). The standard deviation of
the execution time of the different workers is
presented likewise. The results show that the
calculation time of the workers is the dominant
time and the variations in execution time existing
among them are small. This means that an
equitable distribution of the load has been done
even if we have used a static planning strategy.
7. Conclusions and further work
This paper presents a parallel implementation of
the decision trees’ construction algorithm called
CTC. CTC algorithm builds a decision tree based
on several subsamples extracted form the training
set; the decisions in each step of the process are
made by consensus. In order to face the
computational cost of the CT trees’ building
process, a parallel version of the algorithm,
following the master/worker model and based on
MPI, has been implemented. Static planning is
done in the parallel implementation; the treatment
of the different subsamples is distributed
uniformly among the workers (2, 4 or 8 depending
on the experiment).
The efficiency of the algorithm has been
evaluated in data-sets of 25K, 100K and 300K
examples from a customer fidelisation problem.
The results show that the parallel solution scales
correctly and besides, the achieved speed-up is
linear to the number of processors. The proportion
of time spent in the serial execution and parallel
execution has been analysed, and in every case,
more than 90% of the total time is spent in the
parallel part. Furthermore, we have analysed the
execution times of different workers and there is
not significant imbalance among them.
There are many things that can be done in the
future: proves with problems with larger size
should be done to analyse the scalability of the
algorithm (computational cost, memory
requirements, etc.), the parallel algorithm can be
evaluated in a shared memory machine (with MPI,
OpenMP, etc.), a dynamic load distribution should
be implemented if we want the parallel version to
be efficient when number of subsamples used to
build the CT trees are not multiple of the number
of workers.
XVI Jornadas de Paralelismo, JP '2005 645
Acknowledgements
The work described in this paper was partly done
under the University of Basque Country
(UPV/EHU) project: 1/UPV 00139.226-T-
15920/2004. It was also funded by the Diputación
Foral de Gipuzkoa and the European Union.
We would like to thank the company Fagor
Electrodomésticos, S. COOP. for permitting us the
use of their data (Faithful) obtained through the
project BETIKO.
Finally we would also like to thank professor
Jose Miguel for giving us the right to use the
parallel machine where the experimentation has
been done and his help for getting it to work.
References
[1] Domingos P.: Knowledge acquisition from
examples via multiple models. Proc. 14th
International Conference on Machine
Learning Nashville, TN (1997) 98-106.
[2] Japkowicz N.: Learning from Imbalanced Data
Sets: A Comparison of Various Strategies,
Proceedings of the AAAI Workshop on
Learning from Imbalanced Data Sets, Menlo
Park, CA, (2000).
[3] Drummond C., Holte R.C.: Exploiting the Cost
(In)sensitivity of Decision Tree Splitting
Criteria, Proceedings of the 17th International
Conference on Machine Learning, (2000) 239-
246.
[4] Turney P.: Bias and the quantification of
stability. Machine Learning, 20 (1995), 23
-33.
[5] Breiman L.: Bagging Predictors. Machine
Learning, Vol. 24, (1996) 123-140.
[6] Pérez J.M., Muguerza J., Arbelaitz O.,
Gurrutxaga I.: A New Algorithm to Build
Consolidated Trees: Study of the Error Rate
and Steadiness. Advances in Soft Computing,
Proceedings of the International Intelligent
Information Processing and Web Mining
Conference (IIS: IIPWM´04), Zakopane,
Poland (2004
) , 79-88.
[7] Quinlan J.R.: C4.5: Programs for Machine
Learning, Morgan Kaufmann Publishers
Inc.(eds), San Mateo, California, (1993).
[8] Kargupta H., Chan P.: Advances in Distributed
and Parallel Knowledge Discovery. IAAA
Press (2000).
[9] Mingers J.: An Empirical Comparison of
Selection Measures for Decision-Tree
Induction, Machine Learning, Vol. 3, (1989)
319-342.
[10] Pérez J.M., Muguerza J., Arbelaitz O.,
Gurrutxaga I., Martín J.I.: Analysis of
structural convergence of Consolidated Trees
when resampling is required. Proceedings of
the 3rd Australasian Data Mining Conference
(AusDM04), Cairns, Australia (2004), 9-21
.
[11] Blake, C.L., Merz, C.J.: UCI Repository of
Machine Learning Databases, University of
California, Irvine, Dept. of Information and
Computer Sciences.
http://www.ics.uci.edu/~mlearn/MLRepositor
y.html (1998).
[12] Hastie T., Tibshirani R. Friedman J.: The
Elements of Statistical Learning. Springer-
Verlang (es). ISBN: 0-387-95284-5, (2001).
[13] M.P.I. Forum MPI: A message-passing
interface standard, The International Journal
of Supercomputer Applications and High
Performance Computing 8 (3/4) (1994) 159-
416.
646 Aplicaciones
Paralelización de un algoritmo de búsqueda de localizaciones
bajo competencia espacial en precios
Juani L. Redondo, Inmaculada
García, Pilar M. Ortigosa
Dpto. Arquitectura de Computadores y Electrónica,
Universidad de Almería
Ctra. Sacramento s/n
04120 Almería
juani@ace.ual.es, inma@ace.ual.es,
pilar@ace.ual.es
Blas Pelegrín, Pascual Fernández
Dpto. Estadística e Investigación operativa,
Universidad de Murcia
30100 Espinardo
Murcia
pelegrin@um.es, pfdez@um.es
Resumen
Este trabajo presenta la paralelización de un
algoritmo para la búsqueda de localizaciones de
nuevos centros o servicios de una compañía, la
cual tiene que tomar decisiones acerca de los
nuevos emplazamientos basándose en el precio de
establecimiento de los mismos, y con el fin último
de maximizar su beneficio. Los clientes compran
en el centro que oferta el precio más bajo dentro
de la zona de consumo a la que pertenecen. Este
problema de localización combinatorio es resuelto
por GASUB, un algoritmo genético multimodal
basado en subpoblaciones. Los altos
requerimientos computacionales del problema de
localización demandan la paralelización del
método. En este trabajo se han implementado y
comparado dos estrategias. La primera sigue un
modelo maestro-esclavo, donde el maestro se
encarga de tomar decisiones globales y distribuye
la población que debe ser evaluada. La segunda se
basa en una estrategia de grano-grueso, donde
distintos procesos ejecutan el mismo algoritmo de
optimización sobre diferentes subpoblaciones y
siguiendo caminos independientes.
1. Introducción
“Dónde” localizar sus servicios dentro de una
región dada, es la mayor decisión que tiene que
tomar una determinada empresa.
Su cuota de mercado y su beneficio se ven
fuertemente afectados por la localización de sus
servicios cuando éstos tienen que competir por
los clientes con otros centros pre-existentes, que
venden el mismo tipo de producto. En
Localización, al igual que en campos de modelado
relacionados, los clientes son agrupados en puntos
geográficos, con el fin de hacer los problemas de
optimización computacionalmente tratables (Ver
[1]). Nosotros asumimos que tanto los clientes
como los servicios se sitúan en diferentes nodos
dentro de una red de transporte (Véase Figura 1)
Figura 1. Problema de localización
En muchos casos, la compañía tiene que
seleccionar s localizaciones dentro de un conjunto
de m nodos, con lo que hay que explorar un gran
número de posibles localizaciones para localizar
aquéllas que son las óptimas, lo cual es un
problema de optimización combinatorio duro de
resolver cuando los valores de m y s son altos.
Nosotros consideraremos este problema cuando
v1
v2
v3
C1
C2
C3
f1
f2
f3
f4
R
w2
w3
w1
hay otras empresas en el mercado que compiten
en precios a la puerta del consumidor. Esto
significa que el producto es entregado a los
clientes en los lugares de consumo, y éstos pagan
un precio que incluye los costes de transporte. Se
considera un producto homogéneo, la demanda se
supone fija y conocida, y los clientes compran a la
empresa que les ofrece el precio más bajo. Si hay
empates en el precio, el cliente elige la empresa
más cercana para ser servido. A igualdad de
precios más bajos y de distancia se reparte la
demanda por igual entre la nueva empresa y sus
competidores.
Denotaremos por C = {1,2,…,n} a las áreas
de consumo, wi la demanda en el área i, y ci el
punto donde es agregada. Sea L = {1,2,…,m} las
posibles localizaciones para la nueva empresa. El
coste unitario de transporte es t, el coste de
producción es pprod y el precio mínimo de venta
en origen es pmin.. Para cualquier conjunto fijado S
de localizaciones, L
S  , el precio mejor que
puede ofrecer la nueva empresa en i es pmin.+tDi ,
donde Di es la distancia de ci al competidor más
cercano (Ver [2]). De esta manera puede obtener
mercado en los siguientes conjuntos de áreas:
^ `
i
S
i
S D
d
C
i
C 
 :
1
^ `
i
S
i
s D
d
C
i
C  :
2
Donde di
S
es la distancia de ci a la localización
más cercana en S. En el primer conjunto se lleva
toda la demanda y en el segundo la comparte. La
función objetivo a maximizar por la nueva
empresa es:
  ¸
¸
¹
·
¨
¨
©
§

 ¦ ¦
 
1
S
2
S
C
i C
i
i
i
prod
min w
2
1
w
p
p
)
S
(
3
 
¦



1
S
C
i
i
S
i
i w
d
D
t
El primer término de la función objetivo es el
beneficio debido a la cuota de mercado que
capturan los nuevos centros, el segundo se refiere
al ahorro de transporte, el cual se obtiene cuando
los servicios más cercanos pertenecen a la misma
empresa.
2. El algoritmo de optimización GASUB
Proponemos un algoritmo de optimización global
estocástico para resolver el problema de
localización. El algoritmo (GASUB) es un
algoritmo genético basado en subpoblaciones
(Véase referencia [3]) y que utiliza una técnica
similar al enfriamiento simulado (Véase figura 3)
Una subpoblación se identifica por un único
individuo, su función de adecuación y un valor del
radio. El individuo es el centro de la subpoblación
y el radio indica el área de atracción de esta
subpoblación.
Esta definición asume una distancia definida
sobre el espacio de búsqueda. Para problemas
combinatorios el algoritmo utiliza la distancia
Hamming, que se define como la medida del
número de posiciones o dígitos en la que dos
palabras binarias de la misma longitud (puntos o
individuos) son diferentes. Por ejemplo, la
distancia Hamming entre 10111010 y 11011010
es dos.
Teniendo en cuenta las restricciones del
problema, donde el número de servicios escogidos
y por consiguiente, el número de bits (o genes) a
uno tiene que ser fijo, la distancia Hamming entre
dos posibles puntos (individuos) debe ser siempre
múltiplo de dos.
El radio de la subpoblación no es arbitrario:
éste se toma de una lista de radios decrecientes,
que se calcula mediante una expresión matemática
(exponencial), y de modo que el primero de todos
ellos coincida con el diámetro del dominio de
búsqueda inicial.
Figura 2. Ejemplo de función de radio
Durante el proceso de optimización GASUB
mantiene una lista de individuos con la
información de su centro y de su radio, pero no
mantiene una relación de parentesco ni
dependencia entre las subpoblaciones. Esto viene
1 Nivel
Diámetro del dominio
R
a
d
i
o
648 Aplicaciones
a significar que los individuos que conforman la
lista son autosuficientes como para generar
nuevas subpoblaciones y para trasladarlas hacia la
posición de los óptimos locales y globales de la
función. De este modo hay un paralelismo
intrínseco que se basaría en dividir la lista de
individuos entre los distintos procesadores.
Figura 3. Estructura de GASUB
2.1. Parámetros de entrada
En GASUB los parámetros más importantes
son los que se definen en cada nivel: El radio (ri)
y el máximo número de evaluaciones para la
creación (newi) y mutación (ni) de individuos.
Estos parámetros se calculan a partir de los
siguientes:
x Evals (N): Número máximo de evaluaciones
de la función que el usuario permite al proceso
de optimización completo. El número de
evaluaciones requeridas por el algoritmo
puede ser menor que este valor.
x Level (l): Máximo número de niveles.
x Min_r (rl): El radio asociado con el último
nivel (es decir el nivel Levels(l)). Indica el
radio mínimo que puede tener un individuo
x Max_subp_num (M): Tamaño máximo de la
lista de subpoblaciones o bien el tamaño
máximo de población permitido.
2.2. Población inicial
La población inicial está compuesta por un único
individuo con un centro aleatorio. El individuo
debe tener tantos genes a uno como número de
nuevas localizaciones debamos escoger. El nivel
asociado es el primero, luego el radio de atracción
es el diámetro del espacio de búsqueda.
2.3. Generación y cruce
Por cada individuo en la lista, definido por su
centro, y el nivel (i) o radio (ri), se generan nuevos
individuos aleatorios, teniendo en cuenta que la
distancia Hamming entre el centro y las nuevas
subpoblaciones debe ser menor o igual que el
radio de esa subpoblación. Todos los individuos
generados deben satisfacer la restricción de tener
un número fijo de genes a uno.
Cada nuevo individuo es combinado con el
resto formando parejas, los cuales son
considerados como padres potenciales. El
operador de cruce es aplicado a los padres,
obteniendo así una nueva generación. La función
objetivo se calculará tanto para los padres como
para los hijos.
Si el valor de la función objetivo de cualquier
individuo de la nueva generación es mejor que el
centro de la subpoblación, entonces este individuo
se convertirá en el nuevo centro, manteniendo el
mismo valor del nivel.
Si el valor de la función objetivo de la nueva
generación es peor que los valores de los padres,
entonces ambos padres serán insertados en la
sublista y serán considerados como centros de
nuevas subpoblaciones.
A cada nuevo individuo insertado en la lista se
le asignará el nivel actual (i).
Como resultado de este procedimiento la
sublista contendrá, eventualmente, varios
individuos con diferentes niveles (y por tanto
diferentes radios).
El parámetro de este procedimiento (evals) es
un límite superior del número de evaluaciones.
2.4. Selección
Este procedimiento tiene dos mecanismos, el
primero intenta fundir las subpoblaciones que
están lo suficientemente próximas entre ellas y el
Inicializar población
Mutación
Determinar ri,
newi,ni
Generacion y cruce
Selección
Mutación
Selección
Incrementar
nivel
XVI Jornadas de Paralelismo, JP '2005 649
segundo selecciona la subpoblación que se
mantendrá dentro de la lista.
Fusión: Si los centros de cualquier par de
individuos de la lista están más cerca que el radio
asociado al nivel donde se encuentra el algoritmo,
entonces esos dos individuos se funden.
El centro de la nueva subpoblación será aquel
con mejor valor de la función objetivo y el nivel
será el mínimo de los niveles de las
subpoblaciones fundidas (así el radio es el mayor
de ambos).
Seleccionar-subpoblaciones: Si el número de
subpoblaciones en la lista es más grande que el
máximo permitido (max_subp_num), se eliminan
individuos de la lista hasta alcanzar dicho
máximo.
Los individuos con mayor nivel son
eliminados antes, guardando así, las
subpoblaciones con el radio más grande. Por esta
razón una subpoblación del nivel 1, cuyo radio es
igual al diámetro del espacio de búsqueda,
siempre existe, permitiendo que el algoritmo
pueda escapar de óptimos locales.
2.5. Mutación
Se aplican mutaciones consecutivas a cada centro
de cada subpoblación. La mutación consiste en
seleccionar y borrar una localización del centro y
añadir otra, es decir, consiste en intercambiar una
localización.
Si cuando mutamos un individuo, el valor de
su función objetivo es mejor que el valor del
centro, entonces este nuevo individuo
reemplazará al centro.
3. Estrategias paralelas
Los elevados requerimientos computacionales de
los algoritmos de optimización han suscitado la
aparición de numerosas estrategias de
paralelización (Véase referencia [4]). Una de las
estrategias más comunes consiste en realizar una
paralelización global siguiendo un modelo
maestro-esclavo. El procesador maestro se
encarga de tomar decisiones globales, repartiendo
las poblaciones de puntos que se han de evaluar, y
los procesadores esclavos evalúan la función
objetivo en esas poblaciones de puntos. Otra
estrategia bastante usada es la paralelización de
grano-grueso, donde los diferentes procesadores
ejecutan el algoritmo de optimización sobre una
subpoblación de forma independiente, aunque a
veces se intercambian resultados intermedios.
Se han evaluado dos estrategias de paralelización
de GASUB con el fin de compararlas.
La primera (PMS_GASUB) basada en un modelo
maestro-esclavo, donde los esclavos envían al
procesador maestro la evaluación de sus listas de
subpoblaciones. En esta estrategia, que en su
forma más básica presenta varios puntos de
sincronismo en la recepción de sublistas, se han
utilizado comunicaciones asíncronas y diversas
estrategias de solapamiento de comunicaciones
con computación de modo que se han eliminado
casi todos los puntos de sincronismo a la vez que
se consigue un balanceo de la carga.
La segunda estrategia paralela (PCG_GASUB)
está basada en el modelo grano-grueso en el que
cada procesador ejecuta básicamente el algoritmo
secuencial sobre una subpoblación distinta, y
donde se realizan intercambios de resultados
intermedios entre los procesadores.
3.1. Modelo Maestro-Esclavo
En esta estrategia asíncrona, los procesadores
esclavos serán, fundamentalmente, los
encargados de realizar los procedimientos de
mutación y generación de individuos. Como
dichos procedimientos sólo necesitan conocer las
características propias del individuo (es decir, su
centro y su radio), los procesadores esclavos sólo
necesitan tal información para poder ejecutar el
procedimiento que le corresponda.
En la figura 4 puede observarse el
comportamiento del algoritmo PMS_GASUB en
un nivel i.
El procesador maestro será el encargado de
manejar la lista de subpoblaciones global, por lo
que será el que distribuya los distintos individuos
entre los distintos procesadores para que éstos,
bien generen nuevos individuos, bien los muten.
Inicialmente el procesador maestro generará,
al igual que en la versión secuencial, una lista
formada por un único individuo y a partir de ella
generará una nueva lista de individuos.
Dentro del bucle, el procesador maestro
enviará un individuo de la lista global a cada
650 Aplicaciones
procesador, siempre que haya disponibles. En
caso de que el número total de individuos que
conforman la lista sea inferior al número de
procesadores, el master enviará un flag para que
estos no permanezcan a la espera de un nuevo
individuo.
Cuando un procesador esclavo recibe una
subpoblación, generará, a partir de ella, una nueva
sublista y la fundirá. Como consecuencia de esto,
se reduce el número de subpoblaciones enviadas
al master y por tanto las comunicaciones son más
fluidas y rápidas.
Cuando el master recibe la nueva sublista del
procesador, le enviará otro nuevo individuo, si es
que hay disponibles. De este modo el procesador
maestro reparte de un modo dinámico sus
subpoblaciones entre los procesadores esclavos
con el fin de obtener una nueva lista de nuevos
individuos.
El master comenzará a fundir las sublistas
enviadas por los esclavos mientras no reciba
respuesta de éstos. Este proceso de fusión será
interrumpido siempre que llegue una nueva
información al maestro, para que el procesador
esclavo que ha enviado la sublista no se encuentre
parado esperando un nuevo individuo.
Una vez finalizados los procesos de
generación y fusión, el master comienza a enviar
subpoblaciones a los esclavos para que estos las
optimicen (muten). El master contribuirá al
proceso de optimización, mutando alguno de los
individuos que todavía no hayan sido enviados a
los esclavos, si no recibe respuesta de éstos.
3.2. Modelo Grano-Grueso
En el modelo de grano-grueso, cada procesador
ejecuta un programa de optimización que
evoluciona independientemente del resto durante
la mayor parte del tiempo, aunque ocasionalmente
los individuos de cada subpoblación pueden
migrar de un procesador a otro (tal y como puede
observarse en la figura 5) conforme a una política
migratoria definida por los siguientes parámetros:
x Intervalo de migración: Establece cada
cuántas generaciones se realizará la migración
de una cierta cantidad de individuos desde una
subpoblación a otra.
x Tasa de migración: Indica cuantos individuos
han de enviarse a la otra subpoblación cuando
se cumple el intervalo de migración.
x Criterio de selección de migrantes:
Determina la política que se aplicará para la
selección de los individuos que han de migrar.
Como consecuencia de la paralelización del
algoritmo se ha producido una modificación con
respecto a uno de los parámetros de entrada. En
concreto, el tamaño M de la lista de
subpoblaciones con la que trabajará cada
Distribuir
lista inicial
(nivel i)
Generar
Fundir
Obtener
lista de
Subp.
final
Y
Fundir
Chequear
longitud
Distribuir
lista de
Subp.
final
MAESTRO MAESTRO
ESCLAVO
Mutar
subp.
Generar
Fundir
Generar
Fundir
Mutar
subp.
Mutar
Subp.
Mutar
subp.
y
Fundir
Obtener
lista
subp.
final
Mutacion
nivel i
ESCLAVO
MAESTRO
Puntos de sincronizacion
Comunicaiones
Figura 4. Estrategia paralela maestro-esclavo
XVI Jornadas de Paralelismo, JP '2005 651
procesador, se verá reducida en función del
número de computadores. Así pues, el número
máximo de individuos que pueden formar esa
sublista viene determinado por el resultado de
dividir el tamaño de la lista inicial entre el número
de procesadores. Si este resultado es menor que
dos, el tamaño será de dos individuos.
Figura 5. Modelo grano-grueso
Bajo estas nuevas consideraciones con
respecto a los parámetros de entrada, los distintos
procesadores ejecutarán básicamente el programa
secuencial, con la excepción de que
periódicamente se intercambiarán subpoblaciones.
De este modo para la inicialización de la lista
de subpoblaciones cada procesador generará un
punto aleatorio dentro del espacio de búsqueda, y
a partir de este individuo comenzará a optimizar,
generar, cruzar, fundir subpoblaciones en un
proceso cíclico y dependiente del número de
niveles.
Con el fin de permitir que las poblaciones
evolucionen independientemente unas de otras
evitando una convergencia prematura hacia un
óptimo local, se ha diseñado el algoritmo de modo
que el fenómeno o efecto de la migración no se
produzca en fases tempranas de ejecución del
algoritmo. En un principio se ha diseñado para
que este proceso comience cuando el nivel en el
que esté trabajando cada procesador coincida con
la mitad del valor máximo. Esta restricción
ayudará también a reducir el coste de las
comunicaciones. El intervalo de migración que se
ha escogido es el de una iteración del bucle, de
modo que al final de cada iteración se producirá la
migración de individuos (siempre y cuando el
procesador haya ejecutado la mitad del algoritmo).
La tasa de migración tiene valor uno, ya que
se ha definido considerando el envío, por parte de
cada procesador, de una única subpoblación
(aquella que presente mejor fitness o valor de la
función objetivo). Dado que el establecer
comunicaciones de todos a todos es muy costoso
cuando el número de procesadores es elevado, la
migración se ha implementado utilizando un
procesador como recolector, al que llegan los
distintos individuos del resto de procesadores.
Este formará una minilista de óptimos que enviará
a todos los procesadores.
4. Experimentos
Ambos algoritmos se han implementando usando
C++ y la librería de paso de mensajes MPI. Los
experimentos se han llevado a cabo en un cluster
de 48 nodos. Cada uno de ellos dispone de un
procesador de 52900 MHz Ultrasparc III y un 1
GB de memoria.
Puesto que nuestra pretensión en este estudio
es poner de manifiesto las ventajas del algoritmo
paralelo cuando el problema de localización es
costoso, se ha seleccionado un caso en el que la
versión secuencial tarda en obtener la solución
más de dos horas. Así pues, se han considerado
1046 ciudades (nodos) españolas, las cuales son
posibles candidatas o posibles localizaciones. El
número de servicios ya existentes se ha fijado a 10
y la tasa del coste de transporte y la red de
beneficio (r) se ha fijado a 0.001.
Todos los experimentos se han ejecutado 100
veces, por lo que se presentarán valores medios.
Hay que resaltar que el porcentaje de éxito en
alcanzar el óptimo global ha sido del 100% en
todos los casos, lo que pone de manifiesto la
robustez del algoritmo para encontrar los óptimos.
Los parámetros que se seleccionaron, para
ambos algoritmos, fueron: N=20.000.000, M=100,
l=10, r =1. El número de procesadores utilizados
ha sido p=2i
, con i (0,1,2,3,4,5)
5. Resultados
Con objeto de medir la eficacia, eficiencia y
rendimiento del algoritmo paralelo, se han
comparado los resultados obtenidos con respecto a
la versión secuencial, la cual se ha ejecutado sobre
la misma máquina para poder compararlo con los
resultados obtenidos por las versiones paralelas.
Inicializar
población
Mutar
Determinar
ri, newi,ni
Generar
&
Cruzar
Seleccionar Mutar Seleccionar
Incrementar nivel
Si
Migrar
subpoblacion
Si i >
levels/2
No
652 Aplicaciones
En primer lugar se comprobó que el algoritmo
siempre encuentra el óptimo global.
Como medida de rendimiento se ha utilizado
el tiempo de ejecución. Con el fin de ver la
proporcionalidad entre los distintos tiempos y el
número de procesadores, se ha calculado la
aceleración o speed-up.
A continuación se presentan en modo gráfico
los principales resultados obtenidos en los
experimentos.
En la figura 6 puede observarse la aceleración
de ambos algoritmos, y cómo estos se encuentran
muy próximos al caso ideal. No obstante, vemos
que conforme el número de procesadores crece, el
speed-up se aleja un poco del caso lineal,
presentando un mejor comportamiento el
algoritmo paralelo con la estrategia de grano
grueso que con la técnica maestro-esclavo.
En la estrategia maestro-esclavo, el reparto de
la carga computacional se hace a nivel de
subpoblaciones, por tanto, lo ideal sería que el
número de éstas fuera múltiplo del número de
procesadores de que se dispone. No obstante, el
tamaño de la lista de individuos es dinámico, lo
que implica que en ciertas etapas del algoritmo, o
bien el número de procesadores es mayor al
número de subpoblaciones o viceversa, el número
de subpoblaciones a evaluar supera en número al
de procesadores. En esa dinamicidad, el papel más
importante lo juega el proceso de fusión. Se da el
caso, sobre todo en los últimos niveles del
algoritmo, en el que casi todos los individuos
están muy cerca del óptimo. El proceso de fusión
reduce mucho el número de individuos de la lista
global, y por tanto, el trabajo a realizar. Este
proceso es además, el único punto de sincronismo
que presenta el algoritmo maestro-esclavo, así, el
rendimiento bajará conforme aumenten el número
de procesadores, pues el número de esclavos a la
espera de que el master finalice será mayor.
A resaltar que en el modelo maestro-esclavo,
aunque el aumento del número de procesadores
suponga el incremento de las comunicaciones,
éstas se solapan con la computación, por lo que no
afectan al tiempo total.
La disminución en la aceleración, con
respecto al caso ideal de la técnica de grano-
grueso, cuando el número de procesadores
aumenta, se debe fundamentalmente al aumento
de las comunicaciones y de los puntos de
sincronismo. En este caso, las comunicaciones no
se solapan con la computación, ya que todos los
procesadores esclavos tienen que esperar a recibir
respuesta del master, tras haber enviado sus
óptimos. Además, se produce un aumento del
trabajo redundante, sobre todo en los últimos
niveles. Los procesadores pueden estar trabajando
sobre los mismos individuos, ya que el proceso de
fusión no es global, sino local a cada procesador.
La Figura 5 representa el número de
evaluaciones medio necesario para encontrar el
óptimo para las distintas ejecuciones con diferente
número de procesadores. La estrategia maestro-
esclavo es fiel a la versión secuencial, es decir, el
comportamiento de la estrategia paralela es
idéntico al caso secuencial, obteniendo los
mismos resultados y en el mismo número de
evaluaciones de la función objetivo. No obstante,
en la técnica de grano grueso, se observa una
ligera disminución del número de evaluaciones
conforme el número de procesadores aumenta.
Esto se produce porque el número de
subpoblaciones con las que trabaja cada
procesador disminuye cuando p aumenta (siendo p
el número de procesadores). Esta disminución no
es lineal, sino que existen aproximaciones, por eso
el número de evaluaciones disminuye.
Figura 6. Speed-up
XVI Jornadas de Paralelismo, JP '2005 653
Figura 7. Número de evaluaciones
6. Conclusiones
Se han presentado dos métodos de paralelización
de un algoritmo genético multimodal basado en
subpoblaciones para la búsqueda de localizaciones
de nuevos centros o servicios de una compañía.
Tanto la técnica maestro-esclavo, como la técnica
de grano-grueso, obtienen buenas aceleraciones, si
bien, esta última se acerca un poco más al caso
ideal. No obstante, en la técnica maestro-esclavo,
prácticamente no existen tiempos de espera, por lo
que a pesar del gran número de comunicaciones
que se establecen, se obtiene una buena
aceleración. En la técnica de grano-grueso
presenta un reducido número de comunicaciones,
si bien nos planteamos, como trabajo futuro,
introducir otro tipo de estrategias de migración
para que los distintos procesadores no hagan
trabajo redundante y poder así obtener un speed-
up lineal.
Referencias
[1] R.L. Francis , T.J. Lowe and A. Tamir ,
“Demand Point Aggregation for Location
Models”.In Drezner Z. and Hamacher H.
(Eds.), Facility Location: Application and
Theory, Springer,2002, pp. 207-232.
[2] Fernández P., Pelegrín B., M.D. García, P.
Peeters: A discrete long-term discrete
location-price problem under the assumption
of spatial price competition. European Journal
of Operational Research. Forthcoming.
[3] P. Ortigosa, I. García, and M. Jelasity,
“Reliability and performance or UEGO, a
clustering-based global optimizar.” Journal of
Global Optimization, vol.9, no.3,2001,
pp.265-289.
[4] Pilar M. Ortigosa. Métodos estocásticos de
optimización global. Procesamiento paralelo,
Tesis doctoral, Universidad de Málaga, 1999.
654 Aplicaciones
    
 
            !    #  
   )        
,
 .

,
1 3 4 6 8 : ; = > 3 @ B D E 3 @ F G I J E 3 K L N I Q 6
R S T V W X Y [ ] ^ V S ` V ] Y b c S R S T V W c S e S g h ] b j S k R S T V W X Y [ ] ^ V S ` V ] Y b m
n o p
T ] V b c
o
Y S k m r t S ` V Y v g ^ ` b m
n o p
T ] V b ` ^
o
g w S ` g
o
t
o
h y b c S
n o p
T ] V b c
o
Y S k
} g ^ ~ S Y k ^ c b c c S X t
p
S Y y b } g ^ ~ S Y k ^ c b c c S X t
p
S Y y b } g ^ ~ S Y k ^ c b c c S  Y b g b c b
‚ ƒ „ … ‚
X t
p
S Y y b
‚ ƒ „ … ‚
X t
p
S Y y b
„ † ‚ ‡ „
 Y b g b c b
{
Y ˆ b g
o
k ‰ ` h ^ t
}‹
b ` S W ] b t W S k j h
o p
S 
‹
] b t W S k j ] t ^
o
‹
b V ` W ] h Y W S k
 ‘ ’ “ ” ‘ –
— ˜ ™ š › œ ˜  ž   ¢  ™   š £ ¤ ¥ ¤ ¦ § ¢  š  ¢  ª ¥ › § ª ¤ ª £   §
¢ ¤ ¬ ¤ ¢ ¤ š ˜   š  ¢  § ¬   š ¤   ª ª ¯ œ ° š  ¢  ª œ   ˜   § ¥    ¢   ª ²
¢  ³ › š ž   ´ ¯  ª  ž ¤ § ¤ ž ¤ ¥  § ˜   ª ¥ › ž ¯ § ¤ ¥   ¥ ¤ › §  ª
 § £ š   ˜ ˜   ª ¶ — ª £  ™ š › œ ˜  ž   ™ ¯  ¢  ª  š ž › ¢  ˜   °
¢ › ™ › š ¹ š   ³ › ª ² ¢ › § ¢  ˜ › ª § › ¢ › ª » ¥ › §  ¼ ¤ › §  ª
¢  š  ¢ ª › § š  ™ š  ª  § £   ¢ › ª ™ › š ¬ ½ š £ ¤ ¥  ª »   š ¤ ª °
£   ª ² š  ª ™  ¥ £ ¤ ¬   ž  § £  ¶ — §   ˜ ¹ ¯ §   ª   ™ ˜ ¤ ¥   ¥ ¤ › §  ª ²
 ª ¯ ª ¯   ˜ ¥ › § ª ¤ ¢  š   š ¥ › ž › ™ š ¤ § ¥ ¤ ™   ˜ › œ À  £ ¤ ¬ › ˜  
ž ¤ § ¤ ž ¤ Á   ¥ ¤ ¦ §  §  ˜ §  ž  š › ¢  ¥ › ž ¯ § ¤ ¥   ¥ ¤ › §  ª ²
 ª £   œ ˜  ¥ ¤  § ¢ › ¯ § ¯ ž œ š   ˜ ž à ¼ ¤ ž › ¢  ¢  ª œ   ˜   § °
¥  ›  § £ š  ª ¯ œ ° š  ¢  ª ¶ Ä ¤ §  ž œ   š ¹ › ²  ¼ ¤ £  §   ™ ˜ ¤ °
¥   ¥ ¤ › §  ª ¢ › § ¢   ª £  ž › ¢  ˜ ›  ª ¤ § ª ¯ Æ ¥ ¤  § £  ² »  
´ ¯    ž œ › ª › œ À  £ ¤ ¬ › ª ¢  œ  § ª  š ¥ › § ª ¤ ¢  š   ¢ › ª ¢ 
¤ ¹ ¯   ˜ ¤ ž ™ › š £   § ¥ ¤   ¶ — ª £  £ š   œ   À › š  ª ¯  ˜ ¬   ª £ 
™ š › œ ˜  ž   ž  ¢ ¤   § £  ˜     ¢   ™ £   ¥ ¤ ¦ § ¢  ¢ ¤ ³  š  § £  ª
ž  £   ° È  ¯ š É ª £ ¤ ¥   ª ž ¯ ˜ £ ¤ ° › œ À  £ ¤ ¬ › ¶
Ê Ë Í
– Î Ï Ð Ñ “ Ò Ò Ó Ô –
— ˜  ª £ ¯ ¢ ¤ › ¢  ¹ š   § ™   š £  ¢  ˜ › ª ™ š › œ ˜  ž   ª
¢  ˜   ¬ ¤ ¢   š    ˜ ¥ › § ˜ ˜  ¬   ¥ › § ª ¤ ¢  š   š ¬   š ¤ › ª › œ °
À  £ ¤ ¬ › ª ª ¤ ž ¯ ˜ £   §    ž  § £  ¶ — § ˜   ž   » › š É   ¢  ˜ › ª
¥   ª › ª ²  ª › ª › œ À  £ ¤ ¬ › ª ª › § ¥ › § £ š   ™ ¯  ª £ › ª ² ™ › š ˜ ›
´ ¯  ˜   ž  À › š    § ¯ § › ¢   ˜ ˜ › ª ¥ › § ˜ ˜  ¬    ˜ ¢  £  °
š ¤ › š › ¢  › £ š › ª ¶ Ö › š ž   ˜ ž  § £  ² ˜ › ª ™ š › œ ˜  ž   ª ¢ 
› ™ £ ¤ ž ¤ Á   ¥ ¤ ¦ § ž ¯ ˜ £ ¤ ° › œ À  £ ¤ ¬ › ª  š  ª ¯  ˜ ¬  § ¥ › §
£ ½ ¥ § ¤ ¥   ª ž › § › ° › œ À  £ ¤ ¬ › ¯ £ ¤ ˜ ¤ Á   § ¢ › ¬  ¥ £ › š  ª ¢ 
ª ¯ ž   ¢  ™  ª › ª ¶ Ø  ¥ ¤  § £  ž  § £  ²  ˜ ¥ › § ¥  ™ £ › ¢ 
Ù   š  £ › ° › ™ £ ¤ ž   ˜ ¤ ¢   ¢ Û Ü Ý È   ª ¤ ¢ › ž ¯ » ¯ £ ¤ ˜ ¤ Á   ¢ ›
 § ˜   š  ª › ˜ ¯ ¥ ¤ ¦ § ¢   ª £  £ ¤ ™ › ¢  ™ š › œ ˜  ž   ª ¶
Þ   ™   š £ ¤ ¥ ¤ ¦ § ¢  š  ¢  ª  ª ¯ § ™ š › œ ˜  ž   š    ˜
´ ¯  È   ª ¤ ¢ ›   §   ˜ ¤ Á   ¢ ›  § ˜   ª  ˜ £ ¤ ž   ª ¢ ½ ¥   ¢   ª ¶
— ª £  ™ š › œ ˜  ž   ¥ › § ª ¤ ª £   § ¢ ¤ ¬ ¤ ¢ ¤ š ¯ §   š  ¢  §
¬
  š ¤   ª ª ¯ œ ° š  ¢  ª ¢  ž  § › š £   ž   ß › ¥ › § ¯ §   ¥   š °
¹     ™ š › ¼ ¤ ž   ¢   ² ¢  £   ˜ ³ › š ž   ´ ¯   ˜ §  ž  š › ¢ 
˜ ¤ §    ª ¢  ¥ › ž ¯ § ¤ ¥   ¥ ¤ ¦ §  § £ š  § › ¢ › ª ¢  ¢ ¤ ³  š  § °
£  ª ª ¯ œ ° š  ¢  ª ª    ž ¤ § ¤ ž ¤ Á   ¢ › ¶ Ä  È    ª £ ¯ ¢ ¤   ¢ ›
 ˜ ™   š £ ¤ ¥ ¤ › §   ž ¤  § £ › ¢  ž  ˜ £ ¤ ™ ˜  ª £ ¤ ™ › ª ¢  š  °
¢  ª ² ¥ › ž › š  ¢  ª ¢  ¥ › ž ¯ § ¤ ¥   ¥ ¤ ¦ § È  £  š › ¹  §    ª
Û à Ý ² ¥  ˜ ¯ ˜   š  ª Û á Ý ² â ¤ š  ˜  ª ª Û ã Ý ² ä Þ Ä å Û æ Ý ² §  ¯ °
š › §   ˜  ª Û ç Ý ²  £ ¥ ¶ Ä ¤ §  ž œ   š ¹ › ²  ˜ £ š   £   ž ¤  § £ ›
ª ¤ ž ¯ ˜ £   §  › ¢    ž œ › ª › œ À  £ ¤ ¬ › ª  ª ¯ §   ¬ É   ¢ 
 ª £ ¯ ¢ ¤ ›   œ ¤  š £   ¶
— ª £  £ š   œ   À ›  ª £ ¯ ¢ ¤   ¥ ¦ ž › š  ª › ˜ ¬  š  ª £ 
™ š › œ ˜  ž    § ¥ ¯   ˜ ´ ¯ ¤  š £ ¤ ™ › ¢  š  ¢ ² È   ¥ ¤  § °
¢ › ¯ ª › ¢  ˜ ™   š   ¢ ¤ ¹ ž   ¢  ™   š £ ¤ ¥ ¤ ¦ § ¢  ¹ š   ³ › ª ²
™   š   ˜ › ¥ ¯   ˜ È  ž › ª   ¢   ™ £   ¢ › ¬   š ¤   ª ì  £   °
í  ¯ š É ª £ ¤ ¥   ª ì ¯ ˜ £ ¤ ° î œ À  £ ¤ ¬ › ï ì î ì í ª ð œ   ª   ¢   ª
 § › ™ £ ¤ ž ¤ Á   ¥ ¤ ¦ § ¢  Ù   š  £ › ¶
Þ   Ä  ¥ ¥ ¤ › § à ¢  ª ¥ š ¤ œ  ¥ ¦ ž › š  ™ š  ª  § £   š š  °
¢  ª ž  ¢ ¤   § £  ¹ š   ³ › ª » ª ¯ ™   š £ ¤ ¥ ¤ › §   ž ¤  § £ › ž  °
¢ ¤   § £   ˜ ž › ¢  ˜ › ¢  ™   š £ ¤ ¥ ¤ ¦ § ¢  ¹ š   ³ › ª ¶ — §
˜   Ä  ¥ ¥ ¤ ¦ § á ª  ¢  ª ¥ š ¤ œ  § ˜   ª ì î ì í ª ´ ¯ 
È  ž › ª ¤ ž ™ ˜  ž  § £   ¢ › ™   š   š  ª › ˜ ¬  š  ª £  ™ š › °
œ ˜  ž   ² ž ¤  § £ š   ª ´ ¯  ˜   Ä  ¥ ¥ ¤ ¦ § 㠙 š  ª  § £   ˜ › ª
š  ª ¯ ˜ £   ¢ › ª › œ £  § ¤ ¢ › ª  § ¬   š ¤   ª ¤ § ª £   § ¥ ¤   ª ¢ 
™ š ¯  œ   ²   ª É ¥ › ž › ˜   ª ž ½ £ š ¤ ¥   ª ¯ £ ¤ ˜ ¤ Á   ¢   ª  § ˜  
 ¬   ˜ ¯   ¥ ¤ › § ¶ Ù › š  ˜ £ ¤ ž › ˜   Ä  ¥ ¥ ¤ ¦ § æ ¥ › § £ ¤  § 
˜   ª ¥ › § ¥ ˜ ¯ ª ¤ › §  ª › œ £  § ¤ ¢   ª ¢   ª £   ª £ ¯ ¢ ¤ › ¶
ó Ë õ ö
Ï Î Ó Ò Ó Ð –
ö
– Ñ Ð  ‘ Ñ ‘ ’ ” ‘ Ñ Ó
ö
– Î ‘
ù
Ï
ö ú
Ð ’
Ä  ª   œ  ´ ¯  ˜ › ª ¹ š   ³ › ª ™ ¯  ¢  § ž › ¢  ˜   š
ž  ˜ £ ¤ ™ ˜  ª ™ š › œ ˜  ž   ª š    ˜  ª Û ý Ý ¶ þ ¢  ž à ª ˜   ™   š °
£ ¤ ¥ ¤ ¦ § ¢  ¹ š   ³ › ª ª  ¯ £ ¤ ˜ ¤ Á   ™   š   › £ š › ª ™ š › œ ˜  ž   ª
¥ › ž ›  § ™ š › ¥  ª   ž ¤  § £ › ¢  ¤ ž à ¹  §  ª Û ÿ Ý ² ™ ˜   § °
(b)
(a) (c)

  

 
          

 
 

        
   

 
 

              &
' ( * + * ' / 0 2 4 6 + 8 4 + 9 :  ; = 4 6 * >
? 4 +   A    B C 0 E 8 + F G 0 G 2 ' 8 ' E ' 2 G = 2 G 0 2 4
 4 9 4 M * G 0 N C 0 6 G 2 4 R S 8 6 ' * 4 9 =
|

|
  = V  4 M
* G 0 N C 0 6 G 2 4 + 8 ' 9 6 + 9 Z C 4 2 4 6 4 8 \ ' 0 + M + * G 0 4 * ^
6 ' R ' 2 + 2 2 4  > a M c 8 G d M 4 \ + 2 4 c + 8 6 ' * ' / 0 2 4

8 + F G 9 A

c c B * G 0 9 ' 9 6 4 4 0 2 ' R ' 2 ' 8  4 0  
9 C d ^ E 8 + F G 9 d + M + 0 * 4 + 2 G 9 = 
1
 
2
 " " "  
SG
= 6 + M
Z C 4 9 4 \ ' 0 ' \ ' * 4 4 M 0 r \ 4 8 G 2 4 + 8 ' 9 6 + 9 Z C 4
* G 0 4 * 6 + 0 R S 8 6 ' * 4 9 u 4 8 6 4 0 4 * ' 4 0 6 4 9 + 2 ' F 4 8 4 0 6 4 9
9 C d ^ E 8 + F G 9 A ' ) + - / 0 B = R 4 8 ' ( * + 0 2 G Z C 4 
i∩

j 2
φ
=
∀ 3 =4 6
V
∪SG
sg=1Vsg 2
 > y + 8 4 9 6 8 ' * * ' / 0 2 4 8 / 0 9 : <
=
:  ' / ) 9 4 2 4 ( 0 4 u G 8 4 M u 4 9 G 2 4 M 9 C d ^ E 8 + F G \ | 9
E 8 + 0 2 4 = ~
2
\ +  A
|

sg|)
=
∀
0 B
∈[
€ =  
]
>
a 0 6 S 8 \ ' 0 G 9 2 4 u + 8 6 ' * ' / 0 2 4 8 4 2 4 9 = M G 9 R S 8 ^
6 ' * 4 9 4 0 4 M E 8 + F G 8 4 u 8 4 9 4 0 6 + 0 0 G 2 G 9 4 0 M + 8 4 2 =
\ ' 4 0 6 8 + 9 Z C 4 M + 9 + 8 ' 9 6 + 9 9 4 * G 8 8 4 9 u G 0 2 4 0 * G 0
* G 0 4  ' G 0 4 9 4 0 6 8 4 0 G 2 G 9 >
D 0 + + u M ' * + * ' / 0 ' 0 6 C ' 6 ' R + 2 4 u + 8 6 ' * ' / 0 M + 4 0 ^
* G 0 6 8 + \ G 9 4 0 8 4 2 4 9 * 4 M C M + 8 4 9 > y + F ' E C 8 + € A + B
\ C 4 9 6 8 + C 0 + 8 4 2 * 4 M C M + 8 2 4 6 + \ + ˆ G 8 4 2 C * ' ^
2 G = + 9 ‰ * G \ G 9 C E 8 + F G + 9 G * ' + 2 G = 2 G 0 2 4 M + 9 M ‰ ^
0 4 + 9 2 ' 9 * G 0 6 ' 0 C + 9 * G 0 4 * 6 + 0 * 4 M 2 + 9 * G 0 * + 8 + 9 4 0
* G \ r 0 > y + F ' E C 8 + € A d B \ C 4 9 6 8 + C 0 + u G 9 ' d M 4
u + 8 6 ' * ' / 0 2 4 M E 8 + F G + 9 G * ' + 2 G = * C V + 6 8 + 9 M + * ' / 0 +
M + 8 4 2 * 4 M C M + 8 4 9 8 4 u 8 4 9 4 0 6 + 2 + 4 0 M + F ' E C 8 + € A * B >
a 0 4 M \ G 2 4 M G 6 8 + 2 ' * ' G 0 + M 2 4 u + 8 6 ' * ' / 0 =
4 M G d N 4 6 ' R G 4 9 \ ' 0 ' \ ' Ž + 8 4 M 0 r \ 4 8 G 2 4
* G 8 6 4 9 = \ ' 4 0 6 8 + 9 Z C 4 4 M 2 4 9 d + M + 0 * 4 G 9 4 * G 0 ^
9 ' 2 4 8 + * G \ G C 0 + 8 4 9 6 8 ' * * ' / 0 = 2 4 F G 8 \ + Z C 4
9 ' 9 4 4 9 6 + d M 4 * 4 C 0 2 4 9 d + M + 0 * 4 G \ |  ' \ G
2 4 M J L = M + u + 8 6 ' * ' / 0 2 4 d 4 R 4 8 ' ( * + 8 Z C 4
~
≤
A A  M O B P A A € Q Q R J B T € Q Q B B > a  ' 9 6 4 C 0 E 8 + 0
0 r \ 4 8 G 2 4 + M E G 8 ' 6 \ G 9 u + 8 + 8 4 9 G M R 4 8 4 9 6 + F G 8 ^
\ C M + * ' / 0 \ G 0 G ^ G d N 4 6 ' R G : € Q ; >
a M u 8 ' 0 * ' u + M ’ + 0 2 ' * + u 2 4 4 9 6 4 \ G 2 4 M G 4 9
p2
p1 p1
p2
42.9%
%desbalanceo
#comunicaciones
8 9
(a) (b) (c)

  
“  
 ” • W 

  – — ˜ —
   — ˜  

  — 

    ˜   —    
       — ˜ 
  —   
  — &
9 C E 8 + 0 2 4 u 4 0 2 4 0 * ' + 2 4 M + 8 4 9 6 8 ' * * ' / 0 2 4 2 4 9 ^
d + M + 0 * 4 G > ? C u G 0 E + \ G 9 Z C 4 2 4 9 4 + \ G 9 u + 8 6 ' ^
* ' G 0 + 8 M + 8 4 2 Z C 4 \ G 9 6 8 + \ G 9 4 0 M + F ' E C 8 + ™ A + B
4 0  
2
™ 9 C d ^ 8 4 2 4 9 > y + F ' E C 8 + ™ A d B \ C 4 9 6 8 +
2 G 9 u G 9 ' d M 4 9 u + 8 6 ' * ' G 0 4 9 2 4 4 9 6 + 8 4 2 C 6 ' M ' Ž + 0 ^
2 G E 8 + F G 9 > c G 8 G 6 8 G M + 2 G = M + F ' E C 8 + ™ A * B 8 4 u 8 4 ^
9 4 0 6 + 4 9 + 9 u + 8 6 ' * ' G 0 4 9 4 0 4 M 4 9 u + * ' G 2 4 9 G M C ^
* ' G 0 4 9 > ? ' 4 M 2 4 9 d + M + 0 * 4 G \ |  ' \ G 4 9 
2
› Q L =
M + u + 8 6 ' * ' / 0 \ ^ 9 4 9 4 M 4 * * ' G 0 + * G \ G M + \ 4 N G 8 =
2 4 d ' 2 G + Z C 4 = + u 4 9 + 8 2 4 6 4 0 4 8 C 0 0 r \ 4 8 G 2 4
* G 8 6 4 9 \ 4 0 G 8 = \ a 6 ' 4 0 4 C 0 2 4 9 d + M + 0 * 4 G u 8 G ^
’ ' d ' 2 G > ? ' 0 4 \ d + 8 E G = 9 ' 4 M 2 4 9 d + M + 0 * 4 G \ |  ^
' \ G 4 9 2 4 M 
2
œ Q L = M + u + 8 6 ' * ' / 0 \ a 9 4 8 ‰ + 9 4 ^
M 4 * * ' G 0 + 2 + * G \ G M + \ 4 N G 8 > ? ' 6 8 + d + N + \ G 9 4 0
C 0 * G 0 6 4  6 G \ C M 6 ' ^ G d N 4 6 ' R G = 4 M E 8 + 2 G 2 4 2 4 9 ^
d + M + 0 * 4 G 6 + \ d ' S 0 9 4 * G 0 9 ' 2 4 8 + C 0 G d N 4 6 ' R G +
\ ' 0 ' \ ' Ž + 8 = u G 8 M G Z C 4 + \ d + 9 2 4 d 4 0 9 4 8 * G 0 ^
9 ' 2 4 8 + 2 + 9 >  + 9 6 + + ’ G 8 + = 4 M 0 r \ 4 8 G 2 4 F G 8 \ C ^
M + * ' G 0 4 9 \ C M 6 ' ^ G d N 4 6 ' R G 2 4 M

c c ’ + 9 ' 2 G \ C V
8 4 2 C * ' 2 G : € € = € ™ ; > a 0 : € ™ ; 9 4 * G \ u 8 G d / Z C 4 4 M
C 9 G 2 4 d r 9 Z C 4 2 + M G * + M A y ? B \ 4 N G 8 + + + 2 + u 6 + ^
* ' G 0 4 9 d + 9 + 2 + 9 4 0 + M E G 8 ' 6 \ G 9 4 R G M C 6 ' R G 9 A a ž B
u + 8 + 4 9 6 4 u 8 G d M 4 \ + >
d Ÿ f
 
¡ g
¢
¡
£ ¤ ¥ ¦   § i k i n ¨
g ¡
©
¡
g ¡
© ¢ ¤ £ ¤ ¥ ¦   § ª §   § ¨ o
«
©
¡ ¬
­ ¨
? 4 + q C 0 u 8 G d M 4 \ + 2 4 G u 6 ' \ ' Ž + * ' / 0 \ C M 6 ' ^
G d N 4 6 ' R G A ~ ¯ ¯ B = * G 0 O
≥
™ G d N 4 6 ' R G 9 > a 0 M C E + 8
2 4 2 + 8 C 0 R + M G 8 4 9 * + M + 8 2 4 * + M ' 2 + 2 u + 8 + * + 2 +
9 G M C * ' / 0 = 9 4 2 4 ( 0 4 C 0 G 8 2 4 0 u + 8 * ' + M 2 4 + * C 4 8 ^
2 G + 8 4 M + * ' G 0 4 9 2 4 c + 8 4 6 G ^ 2 G \ ' 0 + 0 * ' + = * G \ G
2 4 6 + M M + \ G 9 + * G 0 6 ' 0 C + * ' / 0 > D 0 + 9 G M C * ' / 0 0
1
9 4 2 ' * 4 Z C 4 2 G \ ' 0 + + G 6 8 + 0
2
A 0
1≺
0
2
B * C + 0 ^
2 G 4 9 \ 4 N G 8 4 0 + M \ 4 0 G 9 C 0 G d N 4 6 ' R G V 0 G
656 Aplicaciones
     
    
 
              !
" 


  
  $ 
1∼

2
%   "      
1
  (  !
 " " 
2
+   
2
  (   " " 
1
 .
   0      

          (   "  "      (   "    0   !
  8 "     ! =   (   ? @   +
"    (  C "   = 
( 
  !  E 0    G    "  "          "     K  L      +
   " "   N  ( "   =   
(  (   .  
  E
 ( "
  "  "          " E " 0  +
  E 0    G  " (    !
(  C "    
 T (           U 
    


   
.  
 0  (
  
"   X   " Y $  % +
" 
 !
       U        L       +  
 _  
" ( E "        G a
  "   L     =   
" "
 !
 "   =    "
_      (   G "
 "     d    X " !
(  _        (         0        !
       G      K  (  X     _   _     ( 
"  X  "  "  "  "  E !    "  "   "
 C "    "   !
   (   "  "  "   " +   
 C "      "        (  !
   "   =  (  U
   " $ "   K    E "   "         +
"
 "
"      " +    %   " 0    "        "    " +
"
(    (  C "   =      (     "              "
  L "     ( a  (    "    _   
  E "
"    
 
"  "  X " + U
"    =     @ " 
 X   "  8   

     "    + 
   G                 U

"  "
  "   
"     "
 " +   @ " ( a "     !
0 " E
 (    (  C "  
  E "
"     +  
 _  
"
"      =     ( a "     "  " 
   " L   ( " +

  "  " (      ( 
  !  E 0    G         E
 !
( "   (     E      "
    "   G " G "   "  "  

"   ( "           
.        G   n o p + o q r K "    (    "   

E      (    " (       
.  L   " (      d  (  !

"   $ d ? % U  T _    "  " E  $  d %     E

 !
( "   "      =   ?        "   =       E  ( 

" t u t v _   K  (  "  "  "   "

  E
 ( " 

            "   $ &  (   +  . / 1 1 +   1 4
. & 7 + 9 1  < &   & / ?
.
.  L   " (      d  ( 
"   $ d  ( 
"    ?  !
  "
  X + d ? % n o w r +    "  x     "    
" 0 "   = 
    a    " E " "  "  
" "  "
 X @ " "
    
L @        L   " (          (   "
 .  
   !
  N   (    !  E 0    G  + d ? "    "    "
" 
 !
     G     " _   (  0   "  "
" "         +
(      " _  
" _    (    "   "    "    
  "   E " E 
  "       (   "  "   
       
  t     
 n o | r + _   "  G  C        
  "  a (         (   "    @     B    .  

     N   ( 
  !  E 0    G  K " U _          "   
   G   "    "    " ( E " 
      +
"      "

U
" G     "  E      "   

"       L       
} "   (   " "  "  "   =  ( 
  !  E 0    G    d ?
L        "   d   " ~   $ d t u d ? n o € r %  . !
 "  x     "   
 C "   " T    " 
   =     "    

       E T _    " + "
" G  C _      " E
   
G "   "   E " E 
  "       "     =    
 C "   
L          "
"      ( "     

 C           "   $ &  (   +  . / 1 1 +   1 4
. H   1 4  < H   & / ?
u   "  (    "    t u t v E " "  "   d ?
L        "   $
  X  $ $ t u d ? % n o † r 
$ t u d ?   
 C " 
          L         !
 "
"   +   L   ( " _   

 G "  "  " E    L  !
      0              L            " !
 "  E 0    G  
   " L   ( "   "
X   "  0    !
             "  ( a  (    "         
 E 0    G  _   
     ?
~  "
 C "     "
"
 0                 "
" 
          !
(   "  "  E      "   "  "  "  0      =   .
 
       0    
  ~       (       G     
    (    X   "  
       E T _    "  
G "   "           +   L     =   
 E 0    G  _  
    " (    (  C "   .      
     + $
  !
X   X       (    G    X "   =  L     " +
"   ( !
"  "   =        "   X  " L      "    "   ( 
n o & r + "     _     "  " (         " E " 0  


 L + 7  N &  (   +  . / 1 1 +   1 4 .
O Q S Q
+ T < L & / ?
$  "        " "  "  "   =    d ? E " "  "
   E
"      L        "   X C U C " Y
U [ " C Y   ‹   C  .   ( x     +

" ( "   '    
* @ B

   \

 


, ] ' * \ ^ n o & r +   "  "      C "
    
 C "    "  E
"   =       "
U   "   K  !
G   N      $ ? %       "
( "    " 
" (  0   

             "  "  
"  E
"   =     !
  "
 ?   ( a + 8 d ?      
"    a (   " (    

    
" L     =   E 0    G  +   
 _  
       "     " 
" 
       E      " 
}    
 "     8 d ?     ( "  "   L     
" d t u d ?     " L   ( 
"   =  ( 
  !  E 0    G 
 
  E
 ( "  
" (   K 
" $ G   n o & r %  d    ( !
E "  X  +      ( "  "    t u t v E " "  "  
   "  x     "   E T _    "
  "

XVI Jornadas de Paralelismo, JP '2005 657
         
                
   
"
   $
 %   
  '  
 '  
       '   
!
  # $   $ '  ( )         (    
  0 #   0  

3 # ) 6    9 #  3    =  $ ) $ ) ? 
(   $   3 ) (  C
  # 0
 ) E ( = #  # $    
?   ) (   ) #   9 #  C
3  
 $   $    ? ) $   
    $   =  #  (

( E = $ ) 3 # 0 #   0  3  )  ( $   0
 # 
(  0 )  $ 
 3 # ? ) 3 )  ( $ #  $  
P Q  (   ( =  # =
 # S
0 $ ) C
U  V   $ ) ?  '  
       S U '    \ !  
 $   C
  V   # (
(  # ( V
( $ #   # 0
 ) # (   
  # (
3  V #     3  )  ( $   0
 # 
(   ) $   ) # 
   = $   ) E (     #  ( '  P c ( S U '   0 #  =  C
 #      #  V  $ ) ? #  # (   = $  #   9 #  3 
) ( f 3 )     0 ) g
 0 
  ( i  k P k
( 
 0 #   m C
=   ) 3  ( $ #  
!  ?  0
 ( 0  ?   )   ) E (  ( 0    0 ) C
  0    # 0
 ) # (     
  #  0  0 # ( g ) $

 0  0 )  $  $  
 ( #   # 9      # 3 =    $ ) ?   # (
# $  #  3 ' $ # #  P
 p 
q r s t u v

w
 
x u y v
   V  
 ) # (     (  ) #    0 ) {     (
(
=  #     #  } ( $  0   # ( *
 0 P ~

 {   # (  \
S % 3  3 #  )   k S P c 0 ,
  # \     )   0  
=  ) (  ) =  0        $   ƒ  $ )     0 #  g   9 #   $   $

$ ) 0 ) {  #    # ( ) ( 9 #  3   ) E (  #     0 (  3   #
 ? '  $ )    …   )  $    3 f m ) 3   # (   $ ) ? ) 
-    (  3   # ?   $ )    ?   ) ( #   0 ? '  $ )    # (
3  … #  ?   ) (    3 ) ( ) 3   # (   $ ) ? )  -

 …
 # (   $ ) ? )  3  )     P c  $ #  g   9 #    # C
3 ) ( ) # =   0 )  #  \
!   # ( 9   
 ( $  3  ( $ 
$ ) 0 ) {  C
#  =     # 3 =      0 g #  ) $ 3 #  3 # ( # C #  V  $ ) ? #
 =   $ )  ) E (  g   9 #  P
,
  # \ 

  9 #   $   $
    
| | | |  ! " 
 $  & 
( ) ) + , - / 1 3 4 5 6 - 7 7 - / 6 9 - /
: < = >
5 4 - ? 7 / 4 - - / 1 3 9 A 7
B C 5 A - 5 6 A / 4 7 / - 9 A /
( ) )
:
+ 5 1 6 ? 1 5 6 - 7 / 7 / 9 A -
D E ( D C 7 ? - 5 ? / ? / A ? / 1 3 9 1 /
F H J K J L ) (
=
7 ? 1 / 4 4 3 5 A A 3 - A 7 / 9 A ?
k  # ( $ ) (
  ) E (     )  ) 3 #  0 #  =   f 3  C
$  # 
$ ) 0 ) {  #   ( 0 #   m =   ) 3  ( $ #  P    # 0
C
 ) # (   ) ( )  )  0     (  ) # #  $  ( )   3  )  ( $ 
 0 =  #   ) 3 )  ( $ #
 
k  ! P , # 3 #  # 3  ( $  C
3 #   # (  ( $   ) #  )    S U  k …  S U  k
$ ) C
0 ) {  (
(   # 0   # 0
 ) E (

  ( $  0     
  
3 )  ( $    
 i  k … S U ' 
  (
(  # ( V
( C
$ #   # 0
 ) # (    ) ( )    
   $  ?  0 #    6 C
V #  ( i  k … ?   )   0   ( S U '   P c (  3 C
 #     #    0 $  3  Ž #  0  = #  0   ) E (    
  $   0   ) #  (
|
i
|
\

P c 0     ) ? #   # 0
C
 ) # (   ( # # 3 ) (    ( #    ) # 0 ) 3 ) $  #
 ( $  3  Ž # P #  =   f 3  $  #    ( 9  )  3 )  ( $ #
=     S U  k   S U  k  … i  k  # (
{
' )

\


' 9   $ # 


P   
}
P c (  S U  k   0 (  3   # 
 V  
 ) # (    # ( ) 9    ( $   =   #     ) #   C
$   0   ) #  ( \

λcutsize
\ P
=    0  =  ) 3   
 V  
 ) E ( 
λcutsize

P  =    0    g
(   …   ƒ
   =   $ ) ?  3  ( $     $ 
λcutsize

P
=    0 
'  ) 3  …  0 $ ) 3    )  ( #
λimb 
\ P
C
λcutsize
 P
c 0 =  #    #   ( 9  )  3 )  ( $ # 6 (  0 ) {  
 ( # 0 
$  3 =    $
     = #     V #  


P
\   # ( 0 #

  0 (  3   #   ?  0
  ) # (        V  
C
 ) E (    \ • – • P #  g   9 # 
$ ) 0 ) {  #    ?  (
 =   $ )  ) # (    (  

\ — 
 C g   9 #  P k  3 f  
= 0  ( $   3 #  0  = #  )  ) 0 )    # 3 =     0    0 ) C
  0   =   $ )  ) # (   #  $  ( )   = #  0   ?   C
 ) # (   =    0  0   9   ( $   0    =  # m ) 3   ) # (  
3 # ( # C #  V  $ ) ? #  \
!  =    0 # 
 0  Ž  ) 3 # 
( 
   $  )   ) E (  )  ) # (  0  # (  )  $  ( $   (      $  
 
 0 0    # 0
 ) # (    # (     0  (   # 
=   ) # 
 0    M
≤
\ P
  P
 0 
O      6  R   6  :     <
   0 )   0    # 0
 ) # (        ?  0
 #
3  )  ( $  0   3 ' $  )    =  # =
  $    (  – ! P
S U W X Z [ \ Z _ a X d Z X e [ X f h i k
P  9
(  ) E ( m
3  =   #   # ( V
( $ #    # 0
 ) # (       p   (
 0 ) ( $   ?  0 # 
 \ ! 
C(X, X

)← |a
∈X
;∃a∈X:aa
|
|X|
 \ 
c 0 ?  0 #  m     p 

\  ) g ( ) 6   
 $ #   0  
 # 0
 ) # (     p  # ( # 3 ) (    = #   0 g
( 
 # 0
 ) E (   P c ( 0   ) g
  –    = #  3 #  #  C
   ?    # 3 #  
    0  3  … #  =   $   0  
 # 0
 ) # (     p P
u Z X _ x X a { _ a X ~ X f  _ € { U € \ W { X Z [ U h † k
P
   

 m
1
 m
2
 P P  m
n

(  # ( V
( $ #   # 0
C
 ) # (   P  9
(  ) E (      ?
 0 ?   0     3  C
)   (       = #   0  # ( V
( $ #   # 0
 ) # (   ( #
# 3 ) (       # 3 #     )   0   ) g
  –    P
658 Aplicaciones
max max
(a) (b)
Solucion de X’
#cortes
#cortes
%desbalanceo
%desbalanceo
desb.
desb.
max_cortes max_cortes
Peor Solucion Inicial Solucion de X

  






 

   
 
 
 

 


  
S(X)←
|X|
i=1
(
|K|
k=1
fk(xi)
max(fk(X))
)
|ND|
(2)
" % & ( * , . 0 1 & , 3 5 7 9 . 0 : 0 ; 3 = , 9 , = , &
A : 9 . , & C = , & ( 7 % 7 3 : , F . 0 , 3 , 3 = 0 H , 9 , 3 . , & , & L
: 7 % 7 & N = , O 3 0 " & , % R 9 , 7 = , . 9 7 ( 7 * : " 5 9 , 3 L
= 0 = 7 5 9 , % " R Y 0 " = , & ( 7 % 7 3 : , A [  F N C , %
3 _ " , 9 = , : 9 . , & = , % 7 5 , 9 & % b : 0 ; 3 0 3 0 : 0 7 % d
e 7 & & % b : 0 3 , & 0 3 0 : 0 7 % , & & 3 % 7 & " 0 & " 7 & , 3 . L
= 7 & % 7 & 0 " 5 % , " , 3 . 7 : 0 3 , & 5 7 9 7 % , % 7 & d


   
             
 
k % b 7 = 9 m " b , & . 9 7 % 7 : " 5 7 9 7 : 0 ; 3 , 3 . 9 ,
% 7 & = 0 H , 9 , 3 . , & o q o r & b & 7 3 = % 7 " t . 9 0 : 7  N
: 3 & 0 = , 9 7 3 = % & w 9 7 H & = , . , & . , 3 , % " 0 & " 9 L
= , 3 y b , , % 9 ,  , * 7 = , 3 , % b 7 = 9 | d " & ,
5 b , = , ( & , 9 1 7 9 N % 7 & & % b : 0 3 , & 3 = " 0 3 7 = 7 &
( . , 3 0 = 7 & 5 9 o q ~  & b , % , 3 = " 0 3 7 9 7 % 7
" 7 C 9  7 = , % 7 & ( . , 3 0 = 7 & 5 9 % 7 & . 9 7 & , & . 9 7 . , L
w 0 7 & d ‚ 9 , % : 3 . 9 7 9 0 N o q  ~ ( . 0 , 3 , % 7 & & % b L
: 0 3 , & = , " , 3 9 : 7 % 0 = 7 = d
 : 3 . 0 3 b 7 : 0 ; 3 N , 1 7 % b 7 " & % & 9 , & b % . 7 = &
( . , 3 0 = & , 3 % 7 " t . 9 0 : 7
d e 7 & = & 5 9 0 " , 9 7 &
: % b " 3 7 & 3 b " t 9 0 : 7 & = , % b 7 = 9 ‡ " b , & . 9 7 3
, % 7 9 , 7 : b ( 0 , 9 . 7 , 3 . t 9 " 0 3 & 7 ( & % b . & C 9 , % 7 L
. 0 1 & N 9 , & 5 , : . 0 1 7 " , 3 . , d ‚ = , " & ( & , 9 1 7 9 : L
" % & " , * 9 , & 9 , & b % . 7 = & 5 7 9 7 , & . 7 " t . 9 0 : 7
& 3 ( . , 3 0 = & 5 9 o q ~  C ‚ ~  d e 7 _ % . 0 L
" 7 O % 7 = , , & . 7 : b 7 = 9 " b , & . 9 7 % 7 " , = 0 7 = ,
9 , & b % . 7 = & 3 9 " 7 % 0 Š 7 = & d ‹ , & b % . 7 , 1 0 = , 3 . , y b ,
o q ~  , & , % " , * 9 N " 0 , 3 . 9 7 & y b , ~ o q ~  C
‚ ~  " , * 9 7 3 7 o q  ~ d ! 0 : Ž 7 & : 3 : % b & 0 3 , &
1 7 3 , 3 , % " 0 & " & , 3 . 0 = y b , % 7 & ( . , 3 0 = 7 & , 3
% 7 " t . 9 0 : 7  d  = , " R & N % 7 & = & _ % . 0 " 7 & : % b " L
3 7 & = , , & . , : b 7 = 9 . 7 " ( 0 , 3 " b , & . 9 7 3 0 3 H 9 " 7 L
: 0 ; 3 & ( 9 , , % "  3 0 " 3 _ " , 9 = , : 9 . , & = , . L
b 7 = 9 m
" 5 7 9 7 . 0 1 7 , 3 % 7 o t . 9 0 : 7  d
               
   
   


  

  

 ‘ 
 " "


  
 "
’
$ & ( $ *
    


 " "

 +



  

“
+

 "
 

”
"
      " ,


  

  

  

  

”  

’ 


  

‘  

  

 “ 

  

“
+
-
& ( $ *


”
"


” . 

  

  
 "
 
 "



“ “ 

  

“ “ 

  

“  

 

 " +


‘  

  

  

  

’ 
/
$ *


  

  

“ ” 
 "
 

’
"


 


“ “ 

.
+


  

  
 +
 

’ 


” ” 

”  

‘



 "
 


"


 “
& ( 1 $


”
"


” . 

+







  

 







  

  

  

  

 
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
2000 2500 3000 3500 4000 4500 5000
%
desbalanceo
# cortes
SMOSA
UMOSA
PSA
MOTS

  
‘

–  
—  
˜ 
    

 
” 

= 7 & % 7 & & % b : 0 3 , & 3 = " 0 3 7 = 7 & N : 3 = , & ( 7 L
% 7 3 : , = , % [  d ~ 0 & , : " 5 7 9 7 3 : 3 % 7 & " , * 9 , &
& % b : 0 3 , & ( . , 3 0 = 7 & , 3 ™ |  š & , ( & , 9 1 7 y b , & 3
" b C 7 5 9 Y 0 " 7 = 7 & d
r 7 C : 7 & & = 3 = , % & 9 , & b % . 7 = & , & . 7 =  & . 0 : &
H 9 , : 0 = & 5 9 % 7 & " t . 9 0 : 7 &  C
5 b , = , 3 3
& , 9 & b O : 0 , 3 . , " , 3 . , : % 7 9 & d k & 5 9 , % % N y b ,
9 , & b % . 7 0 3 . , 9 , & 7 3 . , , & . b = 0 7 9 w 9 R O : 7 " , 3 . , % 7 &
& % b : 0 3 , & ( . , 3 0 = 7 & d e 7  0 w b 9 7 › " b , & . 9 7 % 7 &
& % b : 0 3 , & 3 = " 0 3 7 = 7 & ( . , 3 0 = 7 & 5 9 % 7 &
o q o r & : " 5 7 9 7 = 7 & N , 3 % 7 5 7 9 . 0 : 0 ; 3 = ,     3
, 3


| œ & b ( L w 9 7 H & d k & . 7 O w b 9 7 3 & 7 C b L
= 7 7 : " 5 9 , 3 = , 9 % & 9 , & b % . 7 = & H 9 , : 0 = & , 3
: b 7 = 9 & 7 3 . , 9 0 9 , & d ‚ 9 , * , " 5 % N & , ( & , 9 1 7 : L
" o q ~  ( . 0 , 3 , , % : 3 * b 3 . = , & % b : 0 3 , &
3 = " 0 3 7 = 7 & y b , = " 0 3 7 3 7 % 7 " 7 C 9  7 = ,
% 7 & ( . , 3 0 = 7 & 5 9 . 9 & " t . = & N C 7 = , " R & ( L
. 0 , 3 , b 3 3 _ " , 9 = , : 9 . , & " b C 9 , = b : 0 = d
‚ 9 _ % . 0 " N 0 3 = 0 : 7 9 y b , % 7 & 7 5 9 Y 0 " 7 : 0 3 , &
XVI Jornadas de Paralelismo, JP '2005 659

   
                
#     
$ % ' )
   
n.
*
+
% - . / *
+
% - . /
n.

 

2
3
4
5 . 5
4 "
6 6 5
"
5
"
6
4
6 7
8  

2
3
4
6 9 . 6
4
; ; 5      

    


2
3
4
7 6 5
4
9 5 ; 3 6
4
3 9 5
  =

 
  


.
+
; 6
4
7 9
"

 

2
3
4
3
" +
9
4
3 3 3     

8  

2



  


. 5 5 6
4
5 ; ;
   


2
3
4
3
+
. .
4
9
"
7
+
; 6
4
3 6
  =
 3
4
5 7 . .
4
9
"
5 . 9 . ;
4
3 ;

 

2
3
4
3 7 9 6
4
5 7 . 5 ; . 6
4
3 7 9
8  

2
3
4
6 7 7 5
4
. 3 6 ; 6 3 6
4 +
; 7
 


2


  



  

  =
 3
4
5 6 6
4
;
"
.
+
. 7 5
4
7 . .

 

2
3
4
3 ; 6
4
3
+
5  !   

8  

2
3
4
3 . 3 5
4
9 6 3 ; ; 3 5
4
3 ;
  




2



  


3 . 6
4 +
6 9
  =
 3
4
3 . 5 5
4
7 3
+ " "
9 5 9
4
. . ;

 

2
3
4
6 . 9
4
6 7
+
5
+
7 3 6
4
7 ;
8  

2


   


 #
  

$ &  $ 


2
3
4
3 ; 6 5
4
; 6 5 6 7
+
6 6
4
6 ; .
  =
 3
4
3 ; 7 5
4
7
+ "
5 5
4
6 7
"

 

2
3
4
6
"
6 6 5
4 "
9 6
+
.
" +
6
4 +
3 6
8  

2


   



# * *  

+ - / 0 1 / 3 


2
3
4
3 ; 9 ;
4
3 3 3 6
"
7 ;
"
6
4
; 9 7
  =
 3
4
3 9
"
7
4
3 9 ; ; 7
4
5 ; ;

 

2
C
4
6 3
C
6
4
3 5
+
8  

2
C
 

C
6
4
6 6 5
    


2
C
5
4
3 7 7
C
 

  =

C
" 4 +
3 6
C
" 4
9 ; 6
  E G     G  I I   L I  L     I N
 G  I
 E G     G  I  
         W   
 Y [ 
  I G I  I I ^ G I      I    a 
 b  I 
     I  
  f     G   
       C
I                 Y
4 i 6
j l n 7 o p q j l s p
[ I      E  a  I     I    I  I    I
       G  I Y z            ^        G   
 {  } I       I G   
    
G   b  
G   C
E a       G   E G            b        I ^
  G 
 G I   I       I  
G            I
E a     I        …  
 G   I E  G        W 
# G           G
     
      I Y z 
  G   ^  G
I        I      I  G          I ^
   G  
        b     ‰        f I
    I ^
 I   b      G  …             C
   Y ‹ I   I
G    I E      I       I W    I
    I  N
    G       I ^       N
 G  I
 {  } I E  I    I   Ž    a    G   G      
G  I         I E       I    G  I  
I   
Ž Y
        G       W 
    I      W   I ^
  { Ž   I G  N
 E     
   a           C
 ^   E    N
 G   …       I  a 
   I 
         I   W
     I           I Y [  G 
  #  ‰    G I  I I ^ G  I   a   I I G
   I
E       I         I    ’         I I 
   “      G  I   a   I I G
   I     I
N
 I  f   E        G    
G   b    C
E a     Y [ I   I  G
I    I             C
 b    W   
  G      G  f    
  f       C
 f  E      b      f I     I Y z    G  C
 ^  I     L G  I  I    E       G     G          C
 
G   C E a         I   E G    I      C
  …   b  Y
 9
”
•
– s n q — q s l ˜ j p
™    I   W   b             G     I      
     #    G Y š  ™ ›   › C   › › œ  Y ‹ I 
C
   I         G   #   G   W     ; Ž  
C

   W  f  [
     ž  I    f     ; ^ ž Ÿ Ÿ  C
 C ›    C    ¡  ¢  ^          G    I  b 
[
    Y ž Y   £ I  W       G  
       C
  G
‰  G    I  b   
  E    z ™ Y
¤ s
¥
s ” s l n q
•
p
¦ Ÿ §  Y [ Y

G  E   W ^    

 

  

= 



 !   = $ ? %
  @
!

  !  &  !  =

  B  !   (

  š     I  C C  I G  # ^ Ÿ  œ   Y
¦ › § Y C  G I f  ¨ ^  Y  I I ^ 
G   G    G   I f
z          W   }     W   
I  
C
      ª   ¨  " I Y E # #        !

 
  % -
G  - ^ Ÿ ¢ š    š ›   Ÿ  ¡  Ÿ C ¡ ›  Y
¦  § ™ Y

Y  G G  I ^ {      G z          W   G G
C
G   ª   ¨  " I ^ 0    - I    -   
%
-     (
# 

 !

   ^ Ÿ   ¡ ^ K ^ Ÿ  ¢ ¢ C Ÿ  œ Ÿ Y
¦ « § } Y f   ^ M Y N   W ^  Y  W   ¨  G ^  ª   G
{      G f     G z          W  G W    f 
  ™    W      C    G  I I     E  G  ª   C
¨  " I ^ Q

 

   R  T   V  ^ Ÿ  š    š ›   « 
   ¢ C   Ÿ ¢ Y
¦   § Y z   " ^ W Y z   " ^   [ X      G W    f 
  ¯ ‹ Ž ™ ª   ¨  " z          W z  E G  

I   W  I  
    ¨   f   G     W
660 Aplicaciones

   
  
 
   


 

     


     





       

  

  

$    

        ' '          '  
  "  $  '
) +
)
 -
 0   2  4  2   2 
$  '  
$ : < 4
$ 2 @ B D
  :  :  ) : ) + G 2 H 
@ G 2  K    4
B  
 + 2  ' 2   + ) :  :  )
    
*
       

  '    ' ' P    R P      

 R '  : 2 4  2 @
,   


     2 T  4 : ) V
 - 
2 <
 :  4
$ X  : ) + 2   Z 2  @
+
G 2 K   
 ' ' R 
    $ - :
  V
@ : 
G   <
@ : ^ 2 _  H 
) _ a < 

+ 2 $ 2 + < 2 ) 
 :  )
  
 
 . 
/     



*
 

 
   


 
* *

 
 
    
  3 3 3      ' 3 P 
 ' d  d @ 2 

    _ : )

  $
)  - 2 ^
d 
4
 ) ^

@ 2 ^

4

X -  D
  :  :  ) : ) + 
4 2 _ a ) 4   H   :  )
$  - 2 _ H @ : ) + B    @ H 4  2  2 _ D    2 4 4   4
/    .

   . $ 
 . 


     
.
 3 3 
 P 3   P ' 
  3 -   X  8 8 4 
K 2 i   < 4  +  2 
  H  8 
  K
@ 4 -
K 8 X
  :  :  ) 8
     $  - @  2 + 2 @

4
 
 j X : 4
Z   H <

d
G 2 K d @ +   :  - < B   V H @  :  m i n 2   : o 2
4

X -
D
  :  :  ) : ) +
/    . 

    /   


. 9   

$ X  : ) + 2   p G  $
   P
X X         
   d  ' H < < @ 2 
d  d X 2   2 :

4

X - D
  : 
 :  ) : ) + ' 2 o : 4 2 _ 
V H @  :  i n 2   : o 2 D 2  4 X 2  
 : o 2
/    . 
 

 
*





. 
$    . =  
>  
. 



.
 3 3  
    
4
: @
  m   2 +

V 
4
 V  )   j


) _ ' 

r  4
d V : T 2 _ " 2 H  : 4  :  B    :   H :  D
 
 :  :  ) : ) +

   .   



 
. 
   
*

   .
 .
       3 3         3 
   '  
r  4
 
4
: @
V 
4
 V  )   j

  m  
 2 +

d G 2 K D
 2    i
4 2 _ d @ +   :  - < B  
V H  :  m i n 2   : o 2
4

X - D
  :  :  ) : ) + 


9  

  
 



*
$ 
  




   
  



 
 


$ 


  
 d j 
)
 2 

@  2 _ 4  
 2 < 2   d ) 
@ j

 3 3 
$ X  : ) + 2  
p G  $    3
X X  R R '  R   
  P $   :   X
  :  
  
4
2 @
 
V  D  Z 2  
 - :
m X  : < : ^
 :  ) i j $ : < H @
 2 _ d ) ) 2
@ : ) +

$ 


 
  3   P '     '     R     3 
   G  V 2    X  @ : 4
d  '  4 2 ) i @ H  -
V  '  4 2 ) 
i @ H  -
d  2 @ @ 2 
0  2 @
@ 2 
0 z H
 :  )  B
$ 
 2 
@  H @
 :  ) 4 i j
4    < X H  : ) + V

 - : ) 2 4
 . 



. /
  .
       ' P  
 3  R   3 '  
  R D  $ 2 
~ ) :
$ : < H @
 2 _ d ) ) 2
@ : ) + B   V H @ 
 :  i n 2   : o 2 m X  : < : ^
 :  ) D   i @ 2 < 4   a )
V H @  : X @ 2   :  2  :
2  : 4 :  ) V
 : ) +  0 T 
X
) _
) _ 0 )  :  -  - 2  <
: ) 4  B - : )  
: ) +
) _ d X X @ : 
 :  )

4
 "  ^ 2 ) +
2 _ 

$ X  : ) + 2 
 ' '   
   0  C @ H ) + H
  2 + - 2 <
D     2 < X 4

) _
 H j j  2 ) 4
V m $ d V 2  -  _  d   @ B  
$  @ o : ) + V H @  :  i n 2   : o 2   < i : )
   :
@ m X 
 : < : ^
 :  ) D   i @ 2 < 4
   

*


 
*





  

   






*
 


      ' ' ' 
       
  ' D   ^ j ^

d  
4 ^  : 2 K :  ^
D
 2   $ : < 
H @
 2 _ d ) ) 2
@ : ) + 
V 2 
- 2 H  : 4  :  2  - 
) : z H 2 B   V H @  : X @ 2   i n 2   : o 2   < i : )
   : 

@ m X  : < : ^
 :  )
   

*


 
*


 

  


  






*
 


R   ' '       R 
  3 
4
@  o 2 
V  p
+ H )


i H $ 2
  -
a )
V  _ 2  ) " 2 H  : 4  :  2  - ) : z H 2 4 B     < i : 
)
   :
@ D   i @ 2 < 4
  '  ' 2 2 o 2 4 2 _ 
 @
  
K 2 @ @
p  ) _  )
X X  R 3   P 3
 ' '  
   D  "  "
) 4 2 )

i H $ 2
  - B   V H @  : 
 i n 2   : o 2 m X  : < : ^
 :  )  V m $
/    .
 .



. 
 
*



*
 

  

   




   



 ' ' R 
  
4
 
 j X : 4
Z   H <

     
 




 
*

   
*


*
  
*
$ 



  /   






    
*
  ,   

$ a d V   H  )
@  ) $  : 2 ) 
 : ~    < X H  : ) +
 3      ' '    P '   '  
   0   :  ^ @ 2 
p  - : 2 @ 2  V H @  :  i n 2   : o 2 0 o  
@ H  :  )
 j d @ +   :  - < 4  d   < X

 : o 2 
4 2
$  H _ j
) _  - 2 $   2 ) +  - D
 2   d X X  
 -

  
 
   


 
  
*
 


   

    



      ' ' '   P R   R  
XVI Jornadas de Paralelismo, JP '2005 661
PARALELISMO Y COMPUTACIÓN EVOLUTIVA EN
OPTIMIZACIÓN MULTIOBJETIVO. APLICACIONES EN
ARQUITECTURA DE COMPUTADORES
Francisco Jesús de Toro
Departamento de Teoría de la Señal, Telemática y
Comunicaciones
ETS Ingeniería Informática
Universidad de Granada
18071 Granada
Julio Ortega, Eduardo Ros, Sonia Mota
Departamento de Arquitectura y Tecnología de
Computadores
ETS Ingeniería Informática
Universidad de Granada
18071 Granada
Resumen
En este artículo, tras una descripción de los
problemas de optimización multiobjetivo y de las
posibilidades de los algoritmos evolutivos para
abordar su resolución, se propone un
procedimiento paralelo para abordar su
resolución. El trabajo termina analizando el
interés de la optimización multiobjetivo en el
ámbito de la arquitectura de computadores.
1. Introducción
Un método de optimización es un procedimiento
para encontrar la mejor solución dentro de un
espacio de soluciones factibles de un problema.
Las soluciones son buenas o malas en función de
un objetivo que puede ser un costo de fabricación,
la eficiencia de un proceso, el grado de fiabilidad
de un producto u otros factores.
La mayoría de los problemas de optimización
que aparecen en aplicaciones reales son problemas
multiobjetivo. Así, la presencia de varios
objetivos en conflicto, como por ejemplo la
minimización del costo de fabricación a la vez
que la maximización del grado de fiabilidad o de
prestaciones de un producto, es natural en muchas
situaciones y plantea nuevas dificultades en la
resolución del problema de optimización. Esto se
debe a que, en general, no habrá una única
solución que optimice al mismo tiempo los
diferentes objetivos, estos problemas de
optimización multiobjetivo dan lugar a un
conjunto de soluciones que representan distintos
niveles de compromiso.
Aunque la formulación matemática de la
optimización multiobjetivo tiene sus orígenes en
el periodo que va de 1895 a 1906, durante el cual
se expusieron las bases de los espacios ordenados
de dimensión infinita, fue en 1951 cuando la
optimización multiobjetivo se convirtió en una
disciplina matemática por sí misma. En ese año,
Harold W. Kuhn y Albert W. Tucker [1] hablan
por primera vez del “problema de maximización
de un vector” y de “solución con eficiencia
adecuada” en el contexto de la optimización
multiobjetivo. Las primeras aplicaciones aparecen
en la década de los 60 [2], en la que los problemas
de inversión pública multiobjetivo se hacen
bastante populares entre gestores y personal
dedicado a la toma de decisiones y a la
planificación de tareas [3]. Así que esta área
surgió de manera natural dentro de la matemática
aplicada a la economía, donde los analistas de
sistemas desarrollaron muchas técnicas tanto en el
sector público como privado. De igual manera
estos principios fueron aplicados entre otros a
problemas de diseño de ingeniería [4]. Por
ejemplo, en [5] se revisan las técnicas de
programación matemática existentes para
optimización multiobjetivo.
A continuación se presenta la diferencia
existente desde el punto de vista matemático entre
los problemas de optimización de un único
objetivo (abreviado en inglés como SOP) y los
problemas de optimización multiobjetivo (MOP),
asimismo se define el concepto de Pareto-
dominancia, el cual posibilita la búsqueda de
soluciones de compromiso en el segundo tipo de
problemas.
Un problema de optimización multiobjetivo o
MOP puede definirse como el problema de
encontrar un vector de variables de decisión
n
x ƒ
Ž
)
 ,que satisface un conjunto de
restricciones y optimiza un vector función cuyos
elementos representan objetivos. Estas funciones
pueden corresponder a una descripción
matemática de los criterios de rendimiento de un
sistema determinado. Estos criterios de
rendimiento están normalmente en conflicto entre
sí, tal como se ha anunciado antes, de forma que
optimizar uno de ellos se debe hacer a costa de
empeorar los valores de otro, debiendo por tanto
establecerse un compromiso. Así, en términos de
formulación matemática, hay que encontrar un
vector de variables de decisión x* = [x1
*
,x2
*
, ... ,
xn
*
] que satisfaga un conjunto de restricciones
establecidas y p restricciones de igualdad y
optimice el vector función (minimice/maximice
cada uno de los elementos del vector)
> @T
k
2
1 )
(
f
),...,
(
f
),
(
f
)
( x
x
x
x
f (1)
k
)
( ƒ

.
f
El vector función f(x) relaciona el conjunto )
(llamado también espacio de vectores de decisión)
con otro conjunto k
ƒ
Ž
F (espacio de valores
objetivo) que engloba todos los posibles valores
de los vectores función. Los componentes del
vector f(x) representan los k objetivos a tener en
cuenta en el problema. El vector x* denota una
solución del conjunto de soluciones óptimas. En
el contexto de los MOPs, el significado de óptimo
no coincide con la definición clásica, ya que en
estos problemas es difícil encontrar un único
vector de decisión x* que optimice todos los
objetivos del vector función. Aquí se aplica el
concepto de Pareto-optimalidad. En un problema
de optimización multiobjetivo donde hay que
minimizar todos los objetivos, un vector de
decisión x*) se dice que es una solución Pareto
óptima (u óptima en el sentido de Pareto) si:
)
x
(
f
)
x
(
f
/
}
k
,..,
1
{
i
, i
*
i 



 )
x
(2)
)
x
(
f
)
x
(
f
}
k
,...,
1
{
i
j
y j
*
j d

z

Esto significa, tal como se ha indicado antes, que
x* es una solución Pareto óptima si no existe
ningún vector de decisión factible, x, que mejore
un objetivo sin causar un empeoramiento de al
menos uno de los otros objetivos. Normalmente
hay muchos vectores en el espacio ) que son
óptimos en el sentido de Pareto. A estas
soluciones se les llama no dominadas. También
puede hablarse de soluciones no dominadas en un
subconjunto de ). El conjunto de todas las
soluciones no dominadas cuando se tiene en
cuenta a todo el espacio de decisión )
determinan el frente de Pareto en el espacio de
objetivos F .
F2
F1
Frente de Pareto
Soluciones en el frente de Pareto
Soluciones dominadas
Figura 1. Soluciones en un problema de optimización
con dos objetivos
2. Computación evolutiva y optimización
multiobjetivo
La optimización multiobjetivo se ha abordado con
numerosas técnicas, entre las cuales son de
especial importancia los algoritmos evolutivos.
Así, existe toda una línea de investigación en
algoritmos evolutivos para optimización
multiobjetivo, denominados abreviadamente
MOEA (“Multiobjective Optimization
Evolutionary Algorithms”). Estos algoritmos
fueron utilizados por primera vez por Rosenberg
en su tesis doctoral [6]. Los MOEA pueden
encontrar varias soluciones en una única
ejecución, en vez de tener que realizar una serie
de ejecuciones por separado como ocurre en el
caso de las técnicas de programación matemáticas
tradicionales [7]. Esta habilidad para hacer
converger una población de soluciones de manera
concurrente utilizando técnicas de búsqueda
cooperativa es muy apropiada para resolver
problemas de varias soluciones como el caso de
los problemas de optimización multiobjetivo. Al
mismo tiempo, los MOEA son menos susceptibles
664 Aplicaciones
a la forma o a la continuidad del frente de Pareto.
Así, pueden tratar sin problemas frentes de Pareto
cóncavos o discontinuos que son situaciones
difíciles de afrontar con otras técnicas.
Por otra parte, un estudio de la
descomposición en tareas de un MOEA muestra
que de forma general el esquema de estos
algoritmos presenta pocas diferencias con respecto
al esquema de un algoritmo evolutivo para
problemas de optimización de un único objetivo.
En la Figura 2 se comparan los pseudocódigos de
un EA para problemas de un solo objetivo (SOP)
y un EA para problemas de varios objetivos
(MOP), es decir un MOEA. En el primer caso, en
la primera acción dentro del bucle (Figura 2.a) se
lleva a cabo la evaluación de los individuos
mediante la obtención de un valor escalar
(idoneidad) para cada individuo utilizando para
ello una única función. En un MOP no existe una
función sino un vector función.
1. Crear población aleatoriamente;
Repetir.
2. Evaluar los individuos de la población:
a) Asignar un valor de idoneidad a
cada individuo
3. Selección competitiva
4. Aplicación de los operadores de variación
Hasta satisfacer el criterio de convergencia.
(a)
1. Crear población aleatoriamente;
Repetir.
2. Evaluar los individuos de la población:
a)Asignar un vector de idoneidad a
cada individuo
b)Convertir cada vector de idoneidad
en un valor de idoneidad
3. Selección competitiva
4. Aplicación de los operadores de variación
Hasta satisfacer el criterio de convergencia.
(b)
Figura 2. Algoritmo evolutivo para un problema con un
objetivo (a), y con varios objetivos (b)
Se puede considerar que la evaluación se hace por
tanto en dos pasos. Primero, utilizando el vector
función del problema, se obtiene un vector de
componentes escalares (vector de idoneidad) para
cada individuo de la población. La dimensión de
cada uno de estos vectores de idoneidad es igual al
tamaño del conjunto de las funciones objetivo. En
un segundo paso se convierte el vector de
idoneidad de cada individuo en un valor escalar
(idoneidad) mediante la aplicación de alguna
técnica, específica para cada algoritmo. Esta fase
usualmente incorpora algún método de
mantenimiento de diversidad para procurar que las
soluciones encontradas se extiendan
uniformemente a lo largo de toda la frontera de
Pareto. Por tanto, los EAs son especialmente
apropiados para resolver MOPs ya que son
capaces de mantener muchas soluciones
convergiendo de manera concurrente a lo largo de
la ejecución del algoritmo. De hecho, es una
creencia generalizada la idea de que este tipo de
algoritmos funciona mejor en estos problemas que
otras estrategias de búsqueda, como lo demuestra
la gran cantidad de trabajos en este campo [8]. En
http://lania.mx/~ccoello/EMOO/ se mantiene una
lista de Algoritmos Evolutivos para Optimización
Multiobjetivo. Un buen algoritmo evolutivo para
optimización multiobjetivo a posteriori debe
abordar las siguientes cuestiones:
- La distancia entre las soluciones no dominadas
encontradas por el algoritmo y la frontera de
Pareto debe minimizarse.
- Las soluciones encontradas deben de representar
la totalidad de la región Pareto-óptima.
- La distribución de las soluciones encontradas a
lo largo de la región Pareto-óptima debe ser lo
más uniforme posible.
Con vistas a satisfacer los tres objetivos citados,
surgen dos cuestiones a considerar. Por un lado, la
forma de realizar la asignación de bondad y
selección de forma que se guíe de manera efectiva
la búsqueda hacia la región Pareto-óptima, y
satisfacer así el primer reto. Precisamente, el
procedimiento de asignación de bondad y
selección sirve de base para clasificar los MOEAs
en diversas categorías. En este ámbito,
recientemente se ha puesto de manifiesto
experimentalmente el efecto beneficioso de
introducir el elitismo en el diseño de los
algoritmos evolutivos [9, 11, 12]. Este concepto
hace referencia a la conservación a través de las
generaciones del EA de los mejores individuos de
la población [9]. La atención de los investigadores
se ha centrado de igual manera en el desarrollo de
algoritmos con población secundaria [13]. Por
otro lado, existe el problema de cómo mantener un
XVI Jornadas de Paralelismo, JP '2005 665
conjunto de soluciones uniformemente distribuido
y bien extendido a lo largo de la búsqueda. Esto
plantea el estudio de posibles técnicas de
mantenimiento de diversidad en la población.
3. PSFGA: Optimización multibjetivo
paralela
En esta sección se describe el procedimiento
PSFGA, un procedimiento paralelo basado en
algoritmo de optimización multiobjetivo de frente
único SFGA (Single Front Genetic Algorithm).
Este algoritmo utiliza de manera inédita un
esquema de selección elitista conjuntamente con
un método de aclarado que facilita una
implementación paralela eficiente. De esta forma,
mediante el uso del paralelismo se amplía el
ámbito de aplicación de la optimización
multiobjetivo a problemas realistas de gran
complejidad. La idea básica de SFGA es copiar en
la siguiente población, no la totalidad del conjunto
de élite, entendido como el conjunto de todos los
individuos no dominados de la población actual
sino un conjunto representativo de dicho conjunto
de élite con elementos homogéneamente
distribuidos a lo largo del espacio de objetivos. Si
el número de individuos del primer frente de
dominancia, debido al efecto acumulativo de
sucesivas iteraciones, aumenta por encima de un
determinado porcentaje del cardinal de la
población total, se aplica entonces un
procedimiento basado en un modelo de aclarado
en el espacio de objetivos para obtener el conjunto
de élite diversificado a partir del conjunto de élite
de la población actual. El algoritmo SFGA utiliza
elitismo de primer frente aplicado en dos
vertientes:
x El conjunto de elite diversificado se copia en
la población siguiente
x La población de progenitores utilizada para la
generación del resto de individuos necesarios
para completar la siguiente población está
formada únicamente por los individuos del
conjunto de élite diversificado.
Los parámetros del algoritmo SFGA se muestran
en la Tabla 1, y el pseudocódigo, en la Figura 3.
La Figura 4 ilustra el funcionamiento del
procedimiento de aclarado que se utiliza.
PSFGA está basado en un modelo de
población estructurada en forma de un conjunto de
islas. Cada una de las subpoblaciones que
evolucionan por separado, tienen asignadas una
porción diferente del espacio de búsqueda del
problema de optimización. Los segmentos de
cómputo en paralelo, realizados con las
subpoblaciones, se alternan con segmentos de
cómputo serie realizados con la población total. El
algoritmo PSFGA se utiliza dos tipos de procesos:
un proceso maestro, del cual se ejecuta una única
copia y un proceso trabajador, del cual se ejecuta
un número de copias igual al de subpoblaciones.
El pseudocódigo de ambos procesos se muestra en
las Figuras 5 y 6 respectivamente. El significado
de los parámetros utilizados por el algoritmo
PSFGA se muestra en la Tabla 2
Tabla 1. Parámetros utilizados en SFGA
Notación
Usada Significado
Npob
T
Sigma
Ucl
pm
Tamaño de la población
Número de generaciones
Radio de aclarado
Umbral de aclarado
Probabilidad de mutación
Figura 3. Procedimiento SFGA
Entrada:
Npob (tamaño de la población)
T (máximo número de generaciones)
pm (Probabilidad de mutación)
Salida:
A (Conjunto de soluciones pareto-óptimas)
Iniciar aleatoriamente población Pt=P0
(p. ej. con una distribución normal)
Evaluar Pt para cada uno de los objetivos
Calcular primer frente de dominación de Pt , Pfrente=NoDominados(Pt)
Obtener conjunto de elite, Ptelite=Pfrente
Obtener conjunto de elite diversificado,
Ptelitediversificado=Aclarado1(Ptelite)
Incluir Ptelitediversificado en población de descendencia
Dt= Ptelitediversificado
while (tamaño de Dt<Npob)
Elegir dos individuos al azar xi, xj de Ptelite.
Recombinar xi y xj generando individuo xk.
Mutar xk con probabilidad pm generando xk’.
Hacer Dt=DtU{xk’}.
end while
Hacer t=t+1 y Pt= Dt.
If t<T ir al paso 02
else hacer A=NoDominados(Pt) y terminar
666 Aplicaciones
En PSFGA la partición del espacio de búsqueda se
hace en el espacio de los objetivos, en lugar del
espacio de decisión. Este criterio refuerza los
efectos de la función de aclarado que incorpora el
algoritmo SFGA y que funciona sobre este mismo
espacio de objetivos.
F2
F1
Frente de Pareto
Soluciones no dominadas que permanecen
Soluciones no dominadas que se eliminan
F2
F1
Frente de Pareto
Figura 4. Procedimiento de Aclarado
Tabla 2. Parámetros utilizados en PSFGA
Notación
Usada Significado
pop_size
subpop_size
n_workers
n_epoch
gen_epoch
genser
genpar
obj
n_obj
Tamaño de la población global
Tamaño de cada subpoblación
Número de procesos trabajadores
Número de épocas
genser+genpar
Número de generaciones con la
población total por época
Número de generaciones en cada
una de las subpoblaciones por
época
Función objetivo usada para el
particionamiento del espacio de
búsqueda
Número de funciones objetivo
utilizadas en la partición del
dominio
Por otra parte, en PSFGA se lleva a cabo una
selección Pareto-local, como muestra la Figura 7.
Como se puede ver, se tienen cinco
subpoblaciones con el mismo tamaño. La solución
en negro en la Figura es no dominada localmente
en la población P2, pero es dominada cuando se
tiene en cuenta la población completa. Así pues, el
trabajo concurrente de los procesadores hace que
puedan seleccionarse para la siguiente generación,
y para la reproducción, individuos localmente no
dominados, pero globlamente dominados.
Figura 5. Procedimiento maestro en PSFGA
Figura 6. Procedimiento trabajador en PSFGA
Proceso Maestro
Iniciar todos los parámetros del algoritmo de las Tablas 1 y 2
Crear e iniciar aleatoriamente población total P de tamaño pop_size
Crear n_workers procesos trabajadores
objÅ0
Ordenar los individuos de P
según los valores de la función objetivo fobj
for i:=1 to n_workers
Crear subpoblación SP[i] de tamaño subpop_size
for j:=1 to subpop_size
SP[i][j]ÅP[i*j]
end for
Enviar parámetros a proceso trabajador i-ésimo
Enviar subpoblación SP[i] a proceso trabajador i-ésimo
end for
for k:=1 to n_epoch
for i:=1 to n_workers
Recibir subpoblación SP[i] de proceso i-trabajador
endfor
for j:=1 to subpop_size
P[i*j]ÅSP[i][j]
endfor
Ejecutar algoritmo SFGA en
la población P durante n_iter_ser generaciones
objÅ(obj++)%n_obj;
Ordenar los individuos de P
según los valores de la variable de decisión fobj
for i:=1 to n_workers
for j:=1 to pop_size
SP[i][j]ÅP[i*j]
endfor
Enviar subpoblación SP[i] a proceso i-trabajador
endfor
endfor
Proceso i-Trabajador
Recibir parámetros del proceso maestro
Recibir subpoblación SP[i] del proceso maestro
Ejecutar algoritmo SFGA con subpoblación SP[i]
durante genpar iteraciones
Enviar subpoblación SP[i] al proceso maestro
for k:=1 to n_epoch
Ejecutar algoritmo SFGA con subpoblación SP[i]
Enviar subpoblación SP[i] al proceso maestro
endfor
XVI Jornadas de Paralelismo, JP '2005 667
Individuos localmente dominados
f2
f1
Individuos localmente no-dominados
P1
P2
P3
P4
P5
Figura 7. Dominancia local y dominancia global
En [10] se compara el procedimiento SFGA con el
procedimiento SPEA [9], previamente propuesto.
Los programas de prueba considerados (ZT1-ZT6)
se utilizan ampliamente en ésta línea de
investigación y se describen también en [9].
SFGA proporciona mejores resultados que SPEA
en la mayoría de los casos. Además, a diferencia
de SFGA, SPEA tiene una gran variabilidad en las
soluciones obtenidas para los problemas ZT4 y
ZT6.
Tabla 3. Prestaciones de PSFGA con genser=10 y
genpar=10
Tabla 4. Prestaciones de PSFGA con genser=0 y
genpar=20
Las Tablas 3 y 4 muestran los resultados
obtenidos por PSFG para 2, 4, 6, y 8 procesadores
en un cluster con Gigabit Ethernet. Los resultados
de la Tabla 3 corresponden a la situación en que
se consideran 10 generaciones en un sólo
procesador por cada 10 generaciones ejecutadas
en los procesadores considerados (configuración
(10,10)), mientras que en la Tabla 4 se realizan 20
generaciones en paralelo en todos los
procesadores entre cada sincronización
(configuración (0,20)). En [10] se proporcionan
resultados para PFSGA considerando fijos los
tiempos de ejecución y se muestran gráficas de los
frente de Pareto obtenidos para los distintos
problemas de prueba y para las dos
configuraciones, (10,10) y (0,20).
De los resultados obtenidos se pueden extraer
una serie de conclusiones. En primer lugar,
cuando se fija el número de generaciones, el
algoritmo PSFGA obtiene soluciones de mejor
calidad que SFGA en ZT1, ZT2, y ZT3, y peores
668 Aplicaciones
en ZT6 y, sobre todo, en ZT4. En este último caso
se observa un comportamiento peor a medida que
aumenta el número de procesadores (sobre todo en
la configuración (0,20)). Cuando se fija el tiempo
de ejecución, PSFGA obtiene mejores soluciones
que SFGA en todos los casos. La calidad de las
soluciones es mejor en la configuración (10,10) y,
lógicamente, la ganancia de velocidad es mayor
para la configuración (0,20), donde se obtienen
ganancias superlineales en algunos casos. Por otra
parte, PSFGA proporciona una buena distribución
de soluciones en el frente de Pareto [10].
4. Optimización Multiobjetivo en
Arquitectura de Computadores
Los problemas de optimización multiobjetivo
aparecen frecuentemente en Arquitectura de
Computadores. En esta sección se describen
algunos ejemplos [14,15].
Las prestaciones de una microarquitectura,
que incorpora un conjunto prefijado de recursos
(unidades aritméticas y de coma flotante,
capacidades de emisión de instrucciones, buses,
tamaños de las caches internas, etc.) pueden
diferir bastante según sean las necesidades
computacionales de la aplicación que se
considere. Mediante la optimización multiobjetivo
se pueden determinar aquellas configuraciones
que definen el frente de Pareto, para seleccionar
entre ellas la que más convenga según el coste, el
consumo, o el mayor interés por unas aplicaciones
frente a otras. Para implementar el procedimiento
de optimización multiobjetivo, la evaluación de la
idoneidad de los individuos de la población se
puede recurrir bien a simuladores, bien a modelos
analíticos que permitan estimar las prestaciones
del diseño que codifica cada individuo. En el caso
de espacios de diseño complejos (son muchos
parámetros, con gran cantidad de alternativas, los
que definen el diseño de una microarquitectura)
sería necesario disponer de un procedimiento lo
suficientemente rápido para evaluar la idoneidad
(modelo analítico lo suficientemente preciso y
fácil de generar y evaluar para una
microarquitectura) habría que recurrir al
procesamiento paralelo para acelerar el proceso de
optimización [16]. En [14] se describe el proyecto
PICO para la síntesis automática de computadores
de propósito específico. El sistema de síntesis
(Figura 8) consta de una descripción
parametrizada de las arquitecturas que define el
espacio de diseño, un sistema que construye los
diseños a partir de una biblioteca de componentes,
un procedimiento para evaluar la idoneidad del
diseño, y un procedimiento que permite explorar
el espacio de diseño (un procedimiento evolutivo
de optimización multiobjetivo).
Figura 8. Optimización multiobjetivo en el diseño
automático de arquitecturas de propósito específico
Otro ámbito en el que se utilizan técnicas de
optimización multiobjetivo [15,16] es el diseño de
arquitecturas para procesadores de red y
dispositivos embebidos para comunicación. En
estos sistemas se combinan tanto elementos
hardware (microprocesadores, procesadores de
propósito específico, módulos hardware
reconfigurables, módulos de memoria, etc.), como
componentes software para los que existen
diversas alternativas de implementación en los
diferentes elementos hardware. Además, los
requisitos pueden ser muy diferentes según el tipo
de aplicación de comunicación. El espacio de
diseño de estas aplicaciones de procesamiento de
paquetes es complejo, y se define a partir de las
diversas alternativas de partición de tareas, de la
asignación de recursos hardware/software a las
funciones de procesamiento de cada paquete, y de
las distintas políticas de planificación para cada
recurso. Además hay que tener en cuenta los
aspectos relacionados con el coste, el consumo,
las necesidades de memoria, los retardos de los
paquetes, y los anchos de banda necesarios. En
[15,16] se utiliza un procedimiento evolutivo de
optimización multiobjetivo para explorar el
espacio de diseño de un procesador de red en
Parámetros (y rangos) de la
Arquitectura
(Definen el espacio de Diseño)
Exploración del Espacio de Diseño
(Procedimiento evolutivo de
optimización multiobjetivo)
Evaluación del
Diseño
(Simulación
Diseño
Biblioteca de
Componentes
Especificaciones
de diseño
Tiempo
Coste
Diseños Pareto-Óptimos
Parámetros (y rangos) de la
Arquitectura
(Definen el espacio de Diseño)
Exploración del Espacio de Diseño
(Procedimiento evolutivo de
optimización multiobjetivo)
Evaluación del
Diseño
(Simulación
Diseño
Biblioteca de
Componentes
Especificaciones
de diseño
Tiempo
Coste
Diseños Pareto-Óptimos
XVI Jornadas de Paralelismo, JP '2005 669
aplicaciones de procesamiento de paquetes
considerando los tres objetivos de coste, y
prestaciones en dos escenarios de aplicaciones de
red. En el primero de ellos (backbone networks)
existen se requieren valores elevados de ancho de
banda por paquete, aunque los requisitos de
procesamiento de cada paquete son pequeños,
mientras que el segundo tipo de aplicaciones
(access networks) los requisitos de ancho de
banda son pequeños pero el coste computacional
de cada paquete es elevado. En estos trabajos
[15,16], la evaluación de los individuos de la
población en cada iteración se realiza con ayuda
de un procedimiento de evaluación analítica de las
arquitecturas de procesamiento de paquetes, en
lugar de basarse en herramientas de simulación.
5. Conclusiones
En este artículo se ha descrito un procedimiento
paralelo de optimización multiobjetivo basado en
la computación evolutiva. Se trata de un
procedimiento que utiliza selección elitista y un
frente único y pone de relieve el interés del
procesamiento paralelo tanto para mejorar la
calidad de las soluciones encontradas como para
acelerar su obtención.
También se han descrito algunas aplicaciones
del ámbito del diseño de arquitecturas de
computadores en los que parecen problemas de
optimización multiobjetivo. Dada la complejidad
de los espacios de soluciones que han de
explorarse en estos casos, los procedimientos
paralelos de optimización multiobjetivo
constituyen una clara alternativa para mejorar la
calidad de las soluciones alcanzadas en tiempos
razonables.
Agradecimientos. Este artículo se ha realizado
bajo la financiación del proyecto SINTA-CC
(TIN2004-01419).
Referencias
[1] Kuhn, H.W. and Tucker, A.W, “Nonlinear Programming”.
In Neyman, J.,editor, Proceedings of the 2nd
Berkeley
Symposium on Mathematical Statistics and Probability,
pages 481-492, Berkeley, California, University of
California Press.
[2] Hurwicz, L. “Programming in Linear Spaces”. In Arrow,
K.J., Hurwicz, L., and Uzawa H., editors, Studies in Linear
and Nonlinear Programming, pages 38-102. Oxford
University Press, London, England.
[3] CohoonJ.P., and Marks, D.H., “A review and Evaluation of
Multiobjective Programming Techniques”. Water
Resources Research, 11(2):208-220
[4] Zadeh, L.A., “Optimality and Nonscalar-Valued
Performance Criteria”. IEEE Transations on Automatic
Control, AC-8(1):59-60.
[5] Miettinen, K.M. “Nonlinear Multiobjective Optimization”.
Kluwer Academic Publishers, Boston, Massachusetts, 1998.
[6] Rosenberg, R.S.:“Simulation of genetic populations with
biochemical properties”. PhD thesis, University of
Michigan, 1967.
[7] Coello Coello, C.A. “A Comprehensive Survey of
Evolutionary-Based Multiobjective Optimization
Techniques”, Knowledge and Information Systems. An
International Journal, 1(3):269-308, August 1999.
[8] Fonseca C.M. and P.J. Fleming. Multiobjective
optimization and multiple constraint handling with
evolutionary algorithms-part i: A unified formulation. IEEE
Transactions on Systems, Man, and Cybernetics 28(1), 26-
37.
[9] Zitzler, E.; Thiele, L.:”Multiobjective optimisation using
evolutionary algorithms: a comparative case study”. Proc.
PPSN-V, Springer-Verlag, pp.292-301, 1999.
[10] Toro, F.; Ortega, J.; Ros, E.; Mota, S.; Paechter, B.;
Martín, J.M.:”PSFGA: Parallel processing and evolutionary
computation for multiobjective optimisation”. Parallel
Computing, 30, pp.721-739, 2004.
[11] Parks, G.T. and I. Miller ”Selective breeding in a
multiobjective genetic algorithm”. In A.E. Eiben, T. Bäck,
M. Schoenauer, and H.-P. Schwefel (Editos).5th
International Conference on Parallel Problem Solving from
Nature (PPSN-V), Berlin, Germany, pp.250-259. Springer.,
1998.
[12] Coello Coello, C.A, Van Veldhuizen, D.A, Lamont, G.B.
“Evolutionary Algorithms for Solving Multi-Objective
Problems”. Kluwer Academic Publishers, 2002
[13] Laumans M., Zitzler E., Thiele L.: On the Effects of
Archiving Elitism, and Density Based Selection in
Evolutionary Multi-objective Optimization. 1st Conference
on Evolutionary Multiobjective Optimization, pp 181-197.
Springer-Verlag, 2001.
[14] Kathail, V.; et al.:”PICO: Automatically Designing
Custom Computers”. IEEE Computer, pp.39-47.
[15] Thiele, L.; Chakraborty, S.; Gries, M.; Künzli, S.:”A
framework for evaluating design tradeoffs in packet
processing architectures”. Proc. 39th
Design Automation
Conference (DAC), ACM Press, 2002.
[16] Chakraborty, S.:”Performance evaluation of network
processor architectures: combining simulation with
analytical estimation”. Computer Networks, 41, pp.641-
665, 2003.
670 Aplicaciones
Distributed Simulation of Ecologic Systems
D. Mostaccio, R. Suppi, E. Luque
Computer Architecture and Operating Systems Department
University Autonoma of Barcelona
08193, Bellaterra, Barcelona, Spain
Diego.Mostaccio@aomail.uab.es, {Remo.Suppi, Emilio.Luque}@uab.es
Abstract
The simulation of ecological models for
individual oriented models presents multiple
advantages for the biologist since it enables the
more accurate reproduction of species behaviour.
However, the drawback of this type of simulation
is the large amount of computing needed to
accomplish real simulations (thousands of
individuals). Distributed simulation is an excellent
tool for solving this type of problem. In the
present paper, a model of these characteristics
(Fish Schools) is analyzed and the corresponding
distributed simulator based on MPI and using
conservative algorithms is developed. In order to
verify the goodness of this simulation, a set of
experiments is accomplished and the speedup with
respect to a sequential simulator is computed.
1. Introduction
Simulations of such complex systems as, for
example, certain ecological systems, require a
high processing capacity. DES (Distributed Event
Simulation) enables users to obtain efficient
solutions in acceptable time periods as long as the
parallelism of the simulated model allows for a
reasonable degree of concurrency.
Fish-Schools were the ecological model used
for this work, which enabled us to simulate fish
movements in an open environment. Two models
can be used for the simulation of this type of
system: aimed at population and aimed at
individual. In the first, the modelling of the
system is a complex task although the computing
requirements are fewer. In the individual oriented,
have a reduced cost in the modelling phase and
gives better (more accurate) results, but the
simulation time increases considerably when the
quantity of individuals is increased.
In this sense, DES reduces the simulation
times in individual oriented models through the
distribution of the simulated individuals in
different computing nodes. Simulation distribution
implies communication between the different
processes in order to exchange data and update the
global state of the simulation. Experiences with
ecological model simulation using PVM [1] as a
communications library presented certain
problems with simulation scalability and the size
of the population to be simulated. This work
presents the design, implementation and
validation of a Fish-School DES simulator for
individual oriented models using MPI [5] as a
communication library.
Event synchronization in a distributed
simulation (DES) can be accomplished in two
possible ways: optimistic simulation and
conservative simulation. In accordance with the
previous experiences of the group, the present
work is aimed at distributed and conservative
simulation, since the excessive optimism
(generally in the frontier zone of the model) of the
first algorithms notably prejudices the efficiency
of the simulation. [9, 6]
The paper is organized as follows: section two
concentrates on Individual oriented Models (IoM).
Section three focuses on Distributed Event
Simulation as well as the design and
implementation of the Fish-School DES
simulator. Section four presents the experiments
carried out to validate the results of the simulation
and shows the performance obtained. Section five
summarizes the conclusions obtained and outlines
future work.
2. Individual oriented model (IoM)
Biologists and ecologists need to study and
analyze the behaviour and system dynamics of
ecosystem populations. The ecosystems studied
are essentially dynamic systems with feedback
behaviour. Ecological systems contain auto-
regulation mechanisms but the many different
studies of them have not obtained results
comparable with those obtained for other
disciplines (automatic control, traffic networks...)
Lotka and Volterra [8-4] represent the
interaction between preys and predators and the
most common ecologic models are developed
using these definitions. These models are based on
the interaction between species and describe their
behaviour through differential equations,
obtaining very good results for very limited, small
models.
Individual Oriented Models (IoM) are an
acceptable solution with considerable reference to
the previous models. These models are based on
the individual’s behaviour and not on the
community or group. IoM is based on the
individual being considered through simple rules
and the observation of the interaction between
them in an ecosystem. There are two important
advantages to these models: they are independent
of the quantity of individuals and can simulate a
very complex ecosystem from a simple element
(individual) without describing the community
analytically.
Moreover, in the Volterra model when the
individuals’ number is increased, the equations to
be resolved are highly complex. IoM scalability is
only limited by the computing capacity of the
system and can to obtain very good results in
acceptable times. Recent advances in cluster
technology and communications provide us with
the large computing capacity for IoM simulation.
2.1. Characteristics of Fish Schools
One of the most representative applications of
IoM is used to describe the movement of given
species. IoM use allows us to determine the
movement of a group of species by using the
movement of each member.
IoM uses very simple, biologically definite
rules that are applied to each member to obtain the
movement of the colony. Movements in Fish
Schools are governed by three basic postulates
from the point of view of the individual: a)
avoiding collisions, b) speed coupling and c)
obtaining a position in the centre of the group
These rules express both the individual’s need
for survival and its instinct for protection (the
need to escape from predators). Each fish in the
model is represented as a point in a three-
dimensional space with an associated speed. And
each fish changes position and speed
simultaneously after a certain period ǻt. The
actions that the model describes for each fish are:
x
x
x
x
x
x
x
Each fish chooses up to X neighbour fish
(X=4 seems sufficient for most schools),
which will be those nearest and with direct
vision. (Figure 1).
Each fish reacts in accordance with the
direction and distance of each neighbour.
Three influence radios and three possible
reactions are established. The final reaction
will be the average of the reactions
experienced by each neighbour.
If the neighbour is found within the
smaller radio, the fish will carry out an
“opposed to address” movement –
repulsion action – (to avoid collisions).
If the neighbour is within a second
influence radio, the fish will adopt the
same direction as the neighbour.
If the neighbour is within a third radio, the
fish will move towards it.
Each fish calculates its news position
according to the new direction.
This generates a very simple model that
enables the description of complex behaviour.
However, very high computing power is
necessary, since the complexity algorithm is
O(N2
), where N is the number of fish (each fish
attempts to find the neighbouring fish by
inspecting all other fish in the school). [4, 2]
Each fish Fi is defined by its position pi and
velocity vi, and chooses its potential neighbours
by watching concentric zones of increasing radio
until finding X Fish. The potential neighbours are
chosen using the algorithm of front priority.
Each fish Fi, once they have selected the X
neighbour, must then determine the reaction
(rotation of the vi) to each fish Fj. Eij will be the Fi
reaction with respect to Fj expressed in spherical
coordinates. Each fish Fj can be found within one
of three possible areas of influence with respect to
Fi (R1,R2,R3):
If Dist(Fj, Fi) d R1, Fi has a repulsion reaction
with respect to Fj.
672 Aplicaciones
If R1<Dist(Fj, Fi) R
d 2, Fi adopts a parallel
position with respect to Fj.
x
x If R2< Dist(Fj, Fi) R
d 3, Fi is guided toward
Fi.
Finally, reaction E (mean value for all Eij) and
vi is rotated according to E value.
3. Distributed event simulation (DES)
The development of the simulation involved
determination of a set of logical processes (LP)
inside the architecture of the distributed system.
Each LP generates and shares events that are
interchanged in the computing systems as
messages. The information contained in these
messages is event type, specific data of this event
and the time of occurrence.
Each LP simulates a section of the simulation
world and this LP is assigned to a computing node
in the cluster. Fish movement in the same section
does not generate events for other LP (there is no
message exchange) but if a fish goes from one
section to another, there is a migration message
from the LP when the fish leaves for the LP where
the fish enters.
This situation of event exchange (messages)
with time-stamped can generate causality errors
(the LP simulated time at which a message arrives
- event - is superior to the time-stamped of the
new event). In order to solve this problem, there
are two mechanisms in the DES: Conservative and
optimistic algorithms. The conservative approach
uses synchronization to avoid causality errors. In
this algorithm, the events are processed when it is
sure that the execution order is correct. On the
other hand, in optimistic algorithms, each LP
processes the events as soon as they are available
and this execution, in some instances, can involve
causality errors. Nevertheless, the algorithm has a
detection mechanism for avoiding these errors and
recovering causality. [7, 9]
Fig. 1. Neighbour selection in the Fish Schools model
3.1. Conservative and distributed simulator:
design and development
As mentioned previously, our work is based on
conservative simulation due to the fact that the
optimistic simulation presents, for this type of
model, low efficiency due to excessive optimism
(the algorithm generates rollbacks chains).
The conservative distributed simulator for
IoM was designed and developed using the MPI
communication library. The use of PVM presents
certain problems with the scalability (size of
colonies) and simulator stability for a huge
number of individuals (thousands of individuals).
[1, 5]
A very important aspect of these models is
individual distribution in the distributed
computing architecture. Loret et al. [4] propose a
model distribution that assigns static group
partitions of fishes to each processor and the
selection of candidate neighbours is implemented
using centralized data structures.
Our solution is based on the dividing the
problem division into a set of logical processes
(LP), which will be executed in the different
processors. For each LP, an initial partition of the
problem (number of fish) and this number will
change dynamically during the simulation. The
LPs have a physical zone of the problem to
simulate (spatially explicit simulation) and the
fish movement will imply migrations between the
LPs.
Two possible interactions are used in the
simulation run that consider fish position:
information exchange and migration. The actual
design implements three messages types
(EvRequest, EvAnswer, EvMigration) and two
XVI Jornadas de Paralelismo, JP '2005 673
internal events (NextStep, EvResume) in order to
control the simulation state machine (figure 2).
The event sequence is: simulation start
consuming the EvNextStep event (initial event is
added to the event list during simulation start up
and initial fish distribution). In the simulation
loop, the new fish positions are calculated but it is
necessary to know the position and speed of all
potential neighbours (the possible neighbours in
the same LP or in the LP of the contiguous block).
The request for information from the
neighbour block (if necessary) is performed by
sending an EvRequest message and in the
conservative simulation this LP is blocked waiting
for an answer (Wait for Answer). The answers are
generated for the neighbour’s LPs as EvAnswer
and the simulation is restarted in the waiting LP
by consuming an EvRessumeStep event and then
EvNextStep.
When the fish position update generates a
situation in which the placement of this fish is in
another block (LP), a migration event is produced
(EvMigration) and a sequence of operations is
called in order to send a message (fish) to the
contiguous block (fish migration) and to update
the data structures of the current LP. The
EvLastStep event is generated in order to end the
simulation in the DES.
Fig. 2.
Fig. 3.
. Machine state of the DES Fish Schools
4. Experimental results
The verification and validation of the model and
simulator were made using a Beowulf cluster with
Linux and Fast Ethernet. A sequential simulator
was developed to analyze the scalability and
performance of the DES simulator. This simulator
has only one event list and runs on a single
computer (one processor). As a performance
measure, frame time generation was selected. This
measurement is the time necessary to compute the
next position and speed for all individuals in the
simulated world.
The experimentation framework was made
using a different configuration of the simulator
parameters: fish number (100 to 25,000
individuals), computing nodes and LP processes
(1 to 32), and ecosystem size (300x300x300) and
fish density are constants for all experiment sets.
Figure 3 shows the frame time using the
sequential simulator with the fish population in
the range of 100-25000 individuals.
0,11 0,34 1,08 3,33 10,27 32,01
101,79
431,18
1350,52
0
200
400
600
800
1000
1200
1400
Time/frame
[sec/frame]
10 200 400 800 1600 3200 6400 1280025000
Number of fish
Time per frame in the sequential simulator
The sequential simulator can carry out animations
in real time only for 100 fishes (§10 frames/sec).
An increase in the number of fish implies that the
simulator can not generate data in real time (400
fish § 1 frame/sec).
Init
Simulation
CalcNextSep
End
Wait For
Answer
Resume
EvNextStep
EvNextStep EvMigration
EvLastStep
EvRequest
EvAnswer
EvRessumeStep
/
The second step of the experiment set was the
execution of the DES for a different fish number
configuration (100-25000) and for a different
number of computing nodes (2-32). In order to
compare the distributed and serial simulator, the
speedup was obtained (fig. 4). As can be
observed, there are values higher than the
linearity.
This situation is due to calculation of the
neighbour position. In the sequential algorithm
there is only one block and all individuals are
computed, but in the DES only the individuals of
the same block and the contiguous blocks are
computed. In the first case, the algorithm
complexity is O(N2
) and in the second it is
O(N2
/n) where n is the number of LPs.
Figure 5 shows the speedup obtained
considering the communication time and the LP
blocking time (waiting for the answer from the
674 Aplicaciones
neighbour). The time per frame in the sequential
simulator for a colony size of 6400 individuals (or
smaller) is always smaller than in the DES and
independent of the number of processors. The
advantage of DES is the huge number of
individuals and computing nodes (i.e. 8 processors
and 25000 individuals). The simulation time in the
DES was reduced by a factor of 3.45 with respect
to the sequential simulator (considering
communication and waiting time) for the same
(simulated) frame number.
0
100
200
300
400
500
600
700
1 2 4 8 16 32
Number of Processors
Speedup
100
200
400
800
1600
3200
6400
12800
25000
Fishes
Fig. 4. Speedup
0
200
400
600
800
1000
1200
1400
1600
100 200 400 800 1600 3200 6400 12800 25000
Number of fishes
Time/frame
[sec/frame]
1
2
4
8
16
32
Processors
Fig. 5. Time per frame including communication and
waiting time
In order to analyse the communications impact
and the causality control, the simulator was
instrumented to obtain the average times for
computing and communication. Figure 6 shows
the results using from 2 to 8 processors and 6400,
12800 and 25000 fishes. The main conclusion is
that the communications is most important part in
the simulation time and this factor is imposed by
the conservative synchronization layer.
18,51 15,33 13,97
74,99
81,49 84,67 86,03
25,01
0
20
40
60
80
100
Communication
Calculation
25000 Fishes
8 LPs
12800 Fishes
8 LPs
6400 Fishes
8 LPs
25000 Fishes
2 LPs
[%]
Fig. 6. Communication-Computing ratio
The figures 7 and 8 show visualizations (with and
without texture respectively) of the graphical
interface used to analyze the results in post-
mortem mode. This interface was developed in
UAB group under Linux and OpenGL. [10]
Fig. 7. Post mortem visualization with texture
Fig. 8. Optimal animation form DES data.
XVI Jornadas de Paralelismo, JP '2005 675
5. Conclusions
The ecological systems simulation is a field that
requires large computing capacity powers when
individual oriented models are used. The
Distributed Event Simulation (DES) is an
excellent tool for solving this type of problem.
The present work analyzes the DES in
Individual oriented models (specifically fish
movement) using a distributed simulation based
on conservative algorithms. The results obtained
demonstrate that it is a viable option but that
conservative algorithms impose a strong limitation
on the method possibilities.
In order to measure the benefits of DES a set
of experiments has been performed. These
experiments were performed using a sequential
simulator and the results were compared with the
distributed simulator. In conclusion we can
observe that the DES is recommendable for large
simulation environments (7000 individual or
more) but there are also acceptable results for a
smaller number of individuals. The main
restriction of DES conservative simulation is its
communication and blocking time but even with
these times, the simulation speedup is acceptable.
Future work will be aimed at:
x
x
x
x
Improving the conservative distributed
algorithm in order to reduce the restrictions
imposed by the communication and blocking
time.
Analysing the possibilities of optimistic
algorithms with optimism control in order to
control rollback chains.
Developing a simulation environment in order
to execute interactive DES simulation with
real time animation.
Improving the Fish School model in order to
include predators, obstacles, more than one
species, energy control, and individual ages in
order to be able to serve the different analysis
needs of biologists and ecologists.
References
[1] Geist, A., Beguelin, A., Dongarra, J, Jiang,
W., Manchek, R., Sunderman, V. Parallel
Virtual Machine. A Users' Guide and Tutorial
for Networked Parallel Computing. The MIT
Press, 1994.
[2] Husth, A., Wissel, C. The simulation of
movement of fish schools, Journal of
Theoretical Biology, 156, 365:385, 1992.
[3] Kreft, J. Booth, G, Wimpenny, W. T. J.
BacSim, a simulator for individual-based
modelling of bacterial colony growth,
Microbiology Journal, 144, pages 3275-3287,
1998.
[4] Lorel, H, Sonnenschein, M., Using Parallel
Computers to simulate individual oriented
models: a case study, Proceedings of the 1995
European Simulation Multiconference (ESM),
pages 526-531, June 1995.
[5] Message Passing Interface Forum. MPI: A
Message-Passing Interface standard.
Technical report, 1995. http://www.mpi-
forum.org.
[6] Remo Suppi, Daniel Fernández, Emilio Luque.
Fish Schools: PDES Simulation and Real
Time 3D Animation. Lecture Notes in
Computer Science 3-540-21946-3, ISSN
0302-9743 Springer-Verlag EC. Vol.: 3019,
pages: 505-512, 2004.
[7] Serrano, M., Suppi, R., Luque, E. Parallel
Discrete Event Simulation, State of art.
Computer architecture and Operating Systems
Department. University Autonoma of
Barcelona. 2000. http://pirdi.uab.es
[8] Smith, M. J. Models in Ecology, Cambridge
University Press, 1994.
[9] Suppi, R., Cores, F, Luque, E., Improving
Optimistic PDES in PVM Environments,
Lecture Notes in Computer Science ISSN
0302-9743, Springer-Verlag, Vol. 2329(1),
pages 107-116, 2002.
[10] Francos, D., Aplicaciones de simulación y
animación distribuidas utilizando cluster de
Linux, PVM, OpenGL. Trabajo de Graduación
dirigido por R. Suppi. Universidad Autónoma
de Barcelona. España, 2002
676 Aplicaciones
Algoritmos evolutivos en Java: resolución del TSP
usando DREAM.
Víctor Martín Molina
YDilo
victorm@ydilo.com
Juan Julián Merelo
Guervós, Juan Luis
Jiménez Laredo
Dept. de Arquitectura y Tecnología
de Computadores
ETS Ingeniería Informática
Univ. de Granada
18071 Granada
{jmerelo,juanlu}@geneura.ugr.es
Maribel García Arenas
Dept. Informática,
Universidad de Jaén
mgarenas@ujaen.es
Resumen
Una de las tendencias actuales es el uso de redes a
nivel de aplicación (Application Level Networks,
ALN) para la realización de tareas de cálculo.
Estas redes superponen sobre la red física y lógica
una capa adicional que la abstrae, y permite
trabajar con una topología y una serie de
funciones totalmente “ad hoc”. En este trabajo se
realizan mediciones sobre una red de este tipo,
que utiliza el entorno DREAM y hace uso de la
librería de computación evolutiva JEO para la
resolución del problema TSP, produciéndose un
incremento de velocidad aceptable en el sistema
multicomputador con respecto a la ejecución
secuencial del mismo, se corroboran así la
características de DREAM como entorno para el
desarrollo de algoritmos evolutivos distribuidos.
1. Introducción.
El objetivo de este trabajo es la medición del
incremento de velocidad que permite DREAM en
un multicomputador. Dicha medición se ha
realizado mediante la creación de un experimento
para resolver el clásico problema del viajante de
comercio (Travelling Salesperson Problem,
-TSP-) [1,2] usando la biblioteca Evolutionary
Objects (JEO) [3,5,6,7], incluidas las clases
recientemente integradas para este propósito; y
lanzando dicho experimento en una máquina
virtual distribuida (Distributed Resources
Evolutionary Algorithms Machine, -DREAM-)
[8,9].
JEO permite programar algoritmos de
Computación Evolutiva (CE) que serán
posteriormente ejecutados de forma distribuida
[13] utilizando los recursos que Internet ofrece.
Esta librería está incluida como parte de un
proyecto mayor denominado DREAM cuyo
principal objetivo es el desarrollo de un entorno
completo para ejecutar experimentos de CE de
forma distribuida, robusta y escalable. Este
sistema de computación soporta aplicaciones que
cumplen las siguientes características:
o Paralelismo, es decir, que el
experimento pueda resolverse utilizando
un conjunto de computadoras.
o Asincronismo.
o Volúmenes de comunicación no muy
grandes entre procesos.
o Robustez, es decir, que la solución
global dependa del éxito del sistema en
su conjunto y no de cada proceso
concreto.
De las diferentes capas en las que se organiza
DREAM [8-9] JEO está orientada a
programadores familiarizados con conceptos de
CE y Programación Orientada a Objetos sin
necesidad de preocuparse de aspectos más
relacionados con el nivel físico. EASEA y
GUIDE son otras capas del proyecto DREAM
para usuarios no programadores que comienzan a
trabajar con CE. Por último CONSOLE da
servicio a cualquier usuario anterior para
controlar sus experimentos.
El resto del trabajo está organizado como
sigue: A continuación se expone el estado del arte
en implementación de sistemas distribuidos para
computación evolutiva (sección 2). A
continuación se define el problema del recorrido
del viajante y se detallan los pasos dados para
implementar el experimento en el entorno
JEO/DREAM (sección 3), para finalizar con los
resultados obtenidos y la ganancia de velocidad
conseguida (sección 4). La última sección (5)
discute tales resultados y presenta posibles líneas
de trabajo futuro.
2. Estado del arte.
JEO está inspirada en Evolutionary Objects,
EO [13-16]. EO es una biblioteca de objetos C++
diseñada para evolucionar cualquier estructura de
datos; su principal premisa es ser lo
suficientemente flexible para permitir la
evolución de cualquiera de estas estructuras. Sin
embargo, EO está desarrollada en C++ y utiliza en
muchas de sus clases técnicas de programación
relativamente avanzadas por lo que no es la
herramienta más adecuada para principiantes o
para investigadores no expertos en C++. EO tiene
una versión paralela, ParadisEO, basada en MPI.
Esta librería sigue un paradigma tradicional que,
no se ajusta demasiado bien a un entorno
autoadaptativo y multiplataforma.
Además de EO existen otras bibliotecas
desarrolladas también en C++ como GAlib [17]
que utiliza PVM [18,19] (Parallel Virtual
Machine) para paralelizar procesos. Sin embargo
GAlib presenta algunas características que no son
modificables como la adición de nuevos
operadores, por lo que dependiendo de la
necesidad del usuario puede ser poco flexible. Por
último también hay que mencionar otras
herramientas como EvolC [20], ECLib [21] y
Open Beagle [22]. EvolC es una librería de
funciones desarrollada en C pero no es
comparable en extensión ni madurez a ninguna de
las comentadas. ECLib es una herramienta
realizada en C++ al igual que Open Beagle pero
ninguna de las tres últimas librerias mencionadas
ofrecen recursos para paralelización de procesos.
El principal problema que plantean las bibliotecas
de funciones o de objetos realizadas en C o en
C++ es la portabilidad portabilidad.
Además de C++ también Java es ampliamente
utilizado como lenguaje de desarrollo. Algunas de
las bibliotecas de objetos que utilizan Java son
JDEAL [23], ECJ [24], JRGP [25], DGP [26][27],
GPSYS [28], MAFRA [29] y GJGP [30]. De
todas estas opciones, sólo JDEAL y ECJ son
comparables con JEO puesto que el resto están
diseñadas para Programación Genética (PG),
excepto MAFRA que es una herramienta
especializada para Algoritmos Genéticos (AG)
Híbridos por lo que tampoco se trata de una
herramienta de CE sino más bien una herramienta
de AG que solo evoluciona individuos binarios.
De las herramientas citadas anteriormente,
JDEAL permite a los usuarios distribuir algunas
tareas a través de redes de computadoras
heterogéneas; además, posee un paquete
estadístico que facilita la recolección de
resultados pero el paradigma de computación
distribuida que utiliza está basado en el modelo
cliente-servidor por lo que cuando la cantidad de
procesos paralelos aumenta, la ganancia del
modelo en redes masivamente paralelas, debido al
cuello de botella que representa el servidor
central, decrece presentando grandes problemas
de escalabilidad. Otra característica a tener en
cuenta de JDEAL es que está especialmente
diseñada para Algoritmos Genéticos (AG) y
Estrategias de Evolución (EE).
Por otro lado, ECJ es una herramienta de CE
desarrollada íntegramente en Java, posee una
amplia variedad de herramientas para la
construcción de experimentos y tiene una
arquitectura ampliable por el usuario. Sin
embargo, al igual que JDEAL, el paradigma de
computación que utiliza no es altamente escalable
puesto que los procesos están organizados
jerárquicamente y en cuanto a la robustez, el éxito
del experimento depende de un servidor que
678 Aplicaciones
permite continuar la evolución. Los procesos
hijos obedecen a un proceso servidor del cual
dependen por lo que si la ejecución del servidor
se detiene los procesos hijos también lo harán.
Otra característica que puede condicionar esta
herramienta es el hecho de que cada proceso que
forma un experimento debe evolucionar la misma
especie de individuos por lo que no es posible el
desarrollo de experimentos de coevolución en los
que se suelen presentar varias especies de
individuos (lo que, en principio, si está previsto
en JEO).
En resumen, DREAM (JEO+DRM) presentan
una serie de características de escalabilidad y
flexibilidad, que, actualmente, son difíciles de
encontrar en otras implementaciones de entornos
para programación de algoritmos evolutivos.
3. Resolviendo el problema del recorrido
del viajante.
Se ha utilizado la biblioteca JEO para resolver
uno de los problemas de optimización
combinatoria más conocido: “el viajante de
comercio” (en adelante TSP, Travelling
Salesperson Problem), creando un experimento
DREAM que será lanzado en DRM.
En este problema, se dispone de un conjunto
de N = {1, ..., n} ciudades, las cuales han de ser
visitadas una sola vez, volviendo a la ciudad
origen, y recorriendo la menor distancia posible.
La versión que se ha implementado es simétrica,
es decir, que la distancia de la ciudad i a la j es la
misma que la de la ciudad j a la i. El fitness o
valor de adecuación es un número real que mide
la distancia total del viaje.
Los datos para ejecutar los experimentos han
sido obtenidos de la biblioteca TSPLIB, en la
dirección web http://www.iwr.uni-
heidelberg.de/groups/comopt/software/TSPLIB95
Se ha trabajado con las instancias de los
problemas cuyo formato indica las coordenadas
cartesianas de cada nodo; a partir de ese formato
es necesario construir la matriz de costes
calculando la distancia euclídea entre cada par de
nodos.
Para la resolución del problema se han
utilizado 6 ordenadores con procesador Pentium
MMX 233MHz, 62368KB de RAM, Sistema
Operativo Linux Red Hat Realease 9.0 y el jsdk
1.4.2_07 conectados en una LAN con Ethernet
Gigabit.
Además, se ha utilizado, como se comenta en
la sección anterior, el framework DREAM, con el
componente DRM para hacer el experimento
distribuido y JEO como librería para la
programación del algoritmo genético, JEO
también es el encargado de abstraer el mecanismo
de comunicación de DRM mediante el modelo
isla [8].
En el proceso de análisis del problema se
detectó que JEO, entre sus múltiples operadores,
no definía los cruces OX y CX, por lo que ambos
fueron añadidos a la librería, demostrando la
flexibilidad de la misma para la adición de nuevos
componentes. Así también, se ha añadido una
nueva configuración para establecer el criterio de
parada del AG, consiste en fijar el coste de la
solución mínima a alcanzar y servirá como
referencia para comparar tiempos entre distintas
ejecuciones y ganancia con distinto número de
nodos.
Las decisiones de configuración en cuanto a
los componentes, operadores y esquemas
utilizados para la resolución del AG son las
siguientes:
o Esquema de codificación: la
representación se basa en un esquema
de orden. Las soluciones posibles se
representan mediante una permutación
del conjunto {1, ..., n}, codificada en un
vector de dimensión n (siendo n el
número de ciudades).
o Generación de la población inicial:
aleatoria con distribución uniforme.
o Esquema de evolución: generacional
con elitismo.
o Operadores de selección.
o Selección por torneo binario.
o Selección proporcional.
o Selección basada en orden.
o Reemplazo: los descendientes del cruce
sustituyen a sus padres. Cada individuo
XVI Jornadas de Paralelismo, JP '2005 679
mutado es sustituido por su
descendiente.
o Operadores de cruce: OX y CX.
o Operadores de mutación: permutación
de genes (2-opt).
o Comunicación de las islas.
o Topología Aleatoria.
o Emigración. migra el mejor individuo
de cada isla, esto proporciona mucha
más importancia, en términos de
presión selectiva, a la emigración que si
se mandase un individuo aleatorio, así
las distintas islas tendrán poblaciones
diferentes pero con los mejores
elementos en común. En cuanto a la
topología es aleatoria de tal forma que
que cualquier isla podrá recibir una
emigración con probabilidad P (dicha
probabilidad es establecida por DRM),
así se establece un mecanismo para
mantener la diversidad en el espacio
global de soluciones.
Los individuos emigraran al final de
cada generación con una frecuencia
determinada por el usuario. De esta
forma las islas cooperan continuamente
sin producir un retardo importante en la
comunicación y tiempo de
procesamiento para dicha
comunicación;
o Inmigración: se ha optado por dejar la
estrategia de inmigración por defecto de
JEO que elige a los inmigrantes que
llegan a una isla de forma aleatoria y los
añade a la población.
Por último, la función objetivo a minimizar es
la siguiente:
Min C(S) = ]]
1
[
],
[
[
]])
1
[
],
[
[
(
1
1
S
n
S
D
i
S
i
S
D
n
i
+
+
∑
−
=
Donde n es el número de nodos del grafo que
define el problema del TSP, Si define un nodo y D
[Si,Sx] define la distancia euclídea entre el nodo
Si y Sx.
4. Ganancia en velocidad.
Para determinar la ganancia en velocidad con
distintas configuraciones de nodos, se ha
trabajado sobre la instancia de problema
berlin52.tsp, cuya solución óptima tiene un
coste de 7542. Se trata de una instancia simple del
TSP, puesto que el experimento no consiste tanto
en determinar la eficacia resolutiva del AG sino la
ganancia en velocidad del mismo conforme se le
añaden unidades de computo.
Se han elegido los siguientes valores de los
parámetros:

La probabilidad de mutación es de 0.1

La probabilidad de cruce es de 0.79

La probabilidad de emigración es de 0.1

Se ejecuta una isla por nodo
Para la elección de tales parámetros se han tenido
en cuenta los estudios previos sobre la resolución
del TSP [1,2], de nuevo no se ha priorizado el
conseguir una optimización de nuestro algoritmo,
como el justificar la capacidad del framework
DREAM para el desarrollo de AG distribuidos.
Con estos parámetros, se han obtenido los
resultados expuestos en la Tabla 1, donde se
muestra la ganancia de velocidad con distinto
número de islas-nodo, para ello se ha tomado la
decisión de que el sistema en su conjunto tenga
siempre una población de 6000 individuos, así en
la ejecución secuencial serán 6000, en la
ejecución en dos Islas 3000 individuos por isla,
etc.
Nodos Tamaño
población
Msec. Ganancia
velocidad
1 6000 338502 1
2 3000 229639 1,47
3 2000 191134 1,77
4 1500 172596 1,96
6 1000 141905 2,39
Tabla 1:Resultados en tiempo y ganancia de
velocidad en el experimento, de 1 a 6 nodos.
680 Aplicaciones
En este experimento, no se consiguen
ganancias de velocidad lineales aunque si que se
consigue un incremento paulatino de las mismas,
los principales factores que influyen en estos
resultados son el carácter probabilístico de DRM
en las comunicaciones [9], la granularidad del
modelo isla (grano grueso)[8] y por tanto que el
algoritmo distribuido posee ciertos componentes
secuenciales que limitan el incremento de
velocidad, así como el retardo típico debido al
tiempo de comunicación.
Los resultados anteriores se muestran
gráficamente en la ilustración 1.
Ilustración 1Ganancia en velocidad del
experimento del recorrido del viajante para
un número de ordenadores (diferentes) que
oscila entre 1 y 6.
También resulta interesante ver cómo convergen
las soluciones en el algoritmo secuencial, de tal
forma que se puede extrapolar el resultado
secuencial al resultado distribuido. La gráfica
correspondiente se muestra en la ilustración 2,
donde se han usado los siguientes parámetros:

Selección basada en orden, OX,

Emigración a islas aleatorias.

Tamaño de población 6000: número de
cromosomas en relación al apartado anterior.

Probabilidad de mutación de 0.1

Probabilidad de cruce es de 0.79.

La condición de parada se ha fijado en
alcanzar la solución óptima.

Probabilidad de emigración es de 0.1.
Ilustración 2Convergencia media del
algoritmo secuencial.
Como se puede apreciar en la ilustración 2, al
principio el algoritmo converge más
rápidamente, aunque luego, se requieren muchas
generaciones para conseguir el alcance del
óptimo. Se repitió el experimento con el operador
cambiando el operador de cruce OX por el CX. Se
ha podido comprobar que el operador CX
converge más rápidamente en las primeras
generaciones pero no encuentra el óptimo puesto
que se queda estancado en un mínimo local, por
ello se descarto como operador de cruce, puesto
que no resultaba válido para el experimento que
se ha desarrollado. El operador OX conlleva una
mayor lentitud pero alcanza la solución óptima.
5. Conclusiones.
Este trabajo muestra cómo aumenta la velocidad
que permite DREAM en un multicomputador, a
XVI Jornadas de Paralelismo, JP '2005 681
través de la creación de un algoritmo paralelo
robusto para la resolución del TSP usando el
mecanismo de distribución de información
utilizado por DREAM y las clases recientemente
incluidas en dicha biblioteca relacionadas con el
experimento anterior. Estos trabajos abren la
puerta a una linea de investigación futura en
cuanto a la optimización del framework DREAM
y configuración del mismo para resoluciones más
eficientes.
6. Referencias.
1. E. L. Lawler, J. K. Lenstra, A. H. G. Rinnooy
Kan, and D. B. Shmoys, “The Travelling
Salesman Problem: A Guided Tour of
Combinatorial Optimization”. New York:
Wiley and Sons, 1985.
2. G. Reinelt, “The Travelling Salesman:
Computational Solutions for TSP
Applications”. Vol 840 of LNCS, Springer-
Verlag, Berling, Germany 1994.
3. M. G. Arenas, Brad Dolin, J. J. Merelo, P. A.
Castillo, I. Fernández De Viana y Marc
Schoenauer. JEO: Java Evolving Objects. In
W. B. Langdon, E. Cantú-Paz, K. Mathias, R.
Roy, D. Davis, R. Poli, K. Balakrishnan, V.
Honavar, G. Rudolph, J. Wegener, L. Bull, M.
A. Potter, A. C. Schultz, J. F. Miller, E.
Burke, and N. Jonoska, editors. Proceedings
of the Genetic and Evolutionary Computation
Conference, page 991, New York, 9-13 July
2002. Morgan Kaufmann Publishers.
4. M.G. Arenas, L. Foucart, J. J. Merelo, and P.
A. Castillo. JEO: A Framework for Evolving
Objects in Java. En la Universidad Politécnica
de Valencia, editor, Durante las XII Jornadas
de Paralelismo, pp 185–191, Valencia, Sep.
2001. REPROVAL, S.L.
5. M.G Arenas, L. Foucart, M. Shoenauer, and
J.J. Merelo. Computación evolutiva en Java:
JEO. En actas del I Congreso Español de
Algoritmos Evolutivos y Bioinspirados, pp
46–53, Mérida, Badajoz, Febrero 2002.
6. M.G. Arenas, P.A. Castillo, G. Romero, y J.J.
Merelo Distribución de Información en
Algoritmos Evolutivos P2P. En Congreso
Español sobre Metaheurística, Algoritmos
Evolutivos y Bioinspirados (MAEB'03), pp
85-92, ISBN:84-607-65-26-1. Gijón, Spain,
Febrero, 2003.
7. Ben Paechter, Thomas Baech, Marc
Schoenauer, Michèle Sebag, A. E. Eiben, J. J.
Merelo and T. C. Fogarty. Dream distributed
resource evolutionary algorithm machine. In
Proceedings of the Congress on Evolutionary
Computation 2000, Vol 2, pp 951–958.
8. M. G. Arenas, P. Collet, A.E. Eiben, M.
Jelasity, J.J. Merelo, B. Paechter, M. Preuβ,
and M. Schoenauer. A framework for
distributed evolutionary algorithms. In
Proceedings of the 7th Conference on Parallel
Problem Solving from Nature, Vol 2439 of
LNCS, pp 665–675, Granada, Spain,
September 7-11 2002. Springer-Verlag.
9. Mark Jelasity, Mike Preuβ, and Ben Paechter.
A scalable and robust framework for
distributed application. 2002 Congress on
Evolutionary Computation, May 2002.
10. Mark Jelasity, Mike Preuβ, Maarten van
Steen, and Ben Paechter. Maintaining
connectivity in a scalable and robust
distributed environment. In 2nd IEEE
International Symposium on Cluster
Computing and the Grid (CCGrid2002), May
2002.
11. George Coulouris, Jean Dollimore, and Tim
Kindberg. Distributed Systems: Concepts and
Design. Addison-Wesley, 2a edition, 1994.
12. J. G. Castellano, P.A. Castillo, J. J. Merelo, y
G. Romero. Paralelización de evolving library
usando MPI. En las XII Jornadas de
Paralelismo. ISBN: 84-9705-043-6, Valencia,
pp 265–270, Septiembre 2001.
13. J. J. Merelo, M. G. Arenas, J. Carpio, P.A.
Castillo, V. M. Rivas, G. Romero, and M.
Schoenauer. Evolving objects. In Proceedings
JCIS 2000 (Joint Conference on Information
Sciences), Vol I, pp 1083–1086.
14. J. J. Merelo, Maarten Keijzer, and Marc
Schoenauer. EO evolutionary computation
framework. Available from
http://eodev.sourceforge.net
15. M. Keijzer, J. J. Merelo, G. Romero, and M.
Schoenauer. Evolving objects: a general
682 Aplicaciones
purpose evolutionary computation library. In
Procedings Evolution Artificielle 2001, pp
231–244.
16. M. Wall. Overview of matthew’s genetic
algorithm library. Available from
http://lancet.mit.edu/galib-2.4 , 1995.
17. M. Feeley and J. S. Miller. A parallel virtual
machine for efficient scheme compilation. In
Proceedings of the 1990 ACM Conference on
LISP and Functional Programming, Nice, pp
119–130, New York, NY, 1990. ACM.
18. V. S. Sunderam. PVM: A framework for
parallel distributed computing. Concurrency:
practice and experience, 2(4):315–339,
December 1990.
19. Marc Schoenauer. Evolc. Available from
http://www.eark.polytechnique.fr/EvolC.html
Dr. Kenneth De Jong. Ec lab ec++.
20. C. Gagn e and M. Parizeau. Open BEAGLE:
A new c++ evolutionary computation
framework. In W. B. Langdon, E. Cantú-Paz,
K. Mathias, R. Roy, D. Davis, R. Poli, K.
Balakrishnan, V. Honavar, G. Rudolph, J.
Wegener, L. Bull, M. A. Potter, A. C. Schultz,
J. F. Miller, E. Burke, and N. Jonoska,
editors, GECCO 2002: Proceedings of the
Genetic and Evolutionary Computation
Conference, page Late breaking papers, New
York, 9-13 July 2002. Morgan Kaufmann
Publishers
21. Joao Costa, Nuno Lopes, and Pedro Silva.
Jdeal, the Java distributed evolutionary
algorithms library. Available from
http://laseeb.ist.utl.pt/sw/jdeal .
22. Sean Luke. A Java-based evolutionary
computation and genetic programming
research system. Available from
http://www.cs.umd.edu/projects/plus/ec/ecj .
23. Pietro Berkes and Samuele Pedroni. Jrgp.
Available from http://jrgp.sourceforge.net .
24. Fuey Sian Chong. A Java based distributed
approach to genetic programming on the
internet. In Procedings of Evolutionary
Computation and Parallel Processing, I:163–
166, July 1999.
25. Fuey Sian Chong. A Java based distributed
approach to genetic programming on the
internet. In Proceedings of Genetic And
Evolutionary Computation Conference, ISBN
1-55860-611-4, II, July 1999.
26. Adil Qureshi. A Java genetic programming
system. Available from
http://www.cs.ucl.ac.uk/staff/A.Qureshi/gpsys
.html .
27. Natalio Krasnogor and Jim Smith. MAFRA:
A Java memetic algorithms framework.
Genetic And Evolutionary Computation
Conference, First International Workshop On
Memetic Algorithms - Workshop
Proceedings. William Hart and Natalio
Krasnogor and Jim Smith Editors. Las Vegas,
Nevada, USA, pp 125–130, Agoust 2000.
28. Robert Baruch. Groovy Java genetic
programming.
https://sourceforge.net/projects/jgprog
XVI Jornadas de Paralelismo, JP '2005 683


 

 
  

 
 



  
  

  

  

   !
"




 
 
  

 
 


    !

"#$ $%&$





  

 






    







 

 
 

 

 
  



 
 

 
 


  

    

 


 
 

 



 

  
   

 

     




 



   

   
 

  

!
 
 
   
   
 
 







 





  
 



  

 


 


"

 
 

      
"

# "$%
 ! 
 

 
 
   
 

   





  


 


 & 
     

  


 
'  


  
!  
 
 


   
  
  
 






 &   


 











 
  
 (
 
 

 

 )
 

  
   (  
 

      




   ! 

 
   
 
 
  

 
   

 


 
#
 
 



     
  
 



% 








 




 
 
 

  

 
   



 

 

 
  


 
 *


   


 



 






(

 

  
  
 
 
  
  

  
 
"$
&


 

 




 
   



"$ $
     









 




 


 
 #


 
 

 
% 



 
 
 
  



  
 

  +

 "$ 

  



 
 


 





 ! 
(
 


  




  

   



  ,   !  

 


 



  



 




 
   
 

 

  


 
  

  
  


-  $

i = 1, n cuerpos

j = nnlist(i), nnlist(i + 1) − 1


f(i)+ = interacciona(

x(i),

x(nlist(j)))





  
  


  



 
 calculafuerza()

  

  


   




  
  
   

 

      

 

  
 

  
   


    
  

    
     
 


  
  !


  
"  

  #


 

    

   $

  
 
 

 



  $    

 $

 

% %

   
  

  

 

   
   


  
 


  
  &


  
 & 
      
 $

  '    
 


 
 


   


  $

  
%   $
" 

 (

    )

  

   
   
   *)
 +    
 nnlist &
nlist    
      $


 
  



 
%  ,
     
  

" 

 interacciona      

  
   

   
 
   
  - 
  


x. 

  

     
 
  
   


f   

    !


      
 

f
  
  !

  


 
  
  (
   
 

 / $   
   

 
 ) ' 012


        

 

 t = 1, n tiempo


xnl ←− solicita coordenadas(nlist, nnlist)


fl ←− calcula fuerza(nlist, nnlist,

xnl,

xl)


xl ←− actualiza posiciones(

fl)



   

 



  !
 
  "  3
   
  

   
 (
   
 
 *)
  '  
 

 

  

 -


x.   


    


    

   
  &   
  

!
  # 
  )  '  
 
 -    
 




 solicita coordenadas.   



  -

xnl.    
  


  
  
 

 
4 

  
 


   

!
  
  
 -

fl. &


  


5   
       



 %     


  



  

 
% 


#  
  

nlist & nnlist ,    
  #

   
#

  
  

  )$ &    



   

 )
   


( / $ 

    


   
 
   

 + 67 +667 667 & +8 
 
) '  
 


 16


 " *)
  
      
  

        +
&+667 4    
   -x1, x2.
 

 

 x1 
%
 x2 
    )
   
  (
   )

 
9     


  -/     8  
  
   625022
  
 . &   

    

    

 " )
 


 
 
 

   


$
   !     
    
686 Aplicaciones

 t = 1
 t = 100K

  

    

 
 





 
   


 



   


      
 

  
  
 
 

   


 
 
  
 
 

   
 
 
!

 
"#$%  
 
   
 



  
 
&

  
 '

  







  %  &  
  



  
 

  


   

  


    





  
 
 
 

 
 
 
    
%   

 



   ( 


 
  
  &


 
 '

   
 %
)
   



 




 
 
      
   
   

x *  
      
 
%
)
+ &
, 
 
   







    ,
 

 -      &

 
 
  

   !% $
  


.      
 
  
 
 offset   


 
     

xl   


 
 


  
 
/



    (  
%
0



 

  ! ! 
        
 i 

(
  
 ' 
  
 

 p    
i
 
 

 
   

p 

  
i 
 
  solicita1coordenadas()%
2






 
   &
   
 
  

 SETP 





 
 


  


   
 
 
/  ( 
    

  



   % )
+ &
XVI Jornadas de Paralelismo, JP '2005 687

 
 


list, nnlist
 
 


 


SETP ←− subconjuntoprocesadores(nlist,nnlist)
  ∀p ∈ SETP
selecp ←− marcaacceso(nlist, nnlist, SETP )
     (selecp)
     (

x, selecp)
  

   


 
  
   
    
    

 
 
  

   

   
   

  
         

 


 
  
 
     
 
   
    SETP       

      
 


    ! 
"    
   
   

xl +

xnl    
 
      SETP   
    

x #

  Np  
        !   "

SETP = i : Np      
  i  Np $    i = 1  
      $  
      
!   !
  i  !   

x  
     
 SETP  % ! 
     

x   &
 SETP    
     
&
SETP = i − 1 : Np    

'
     !    


x  
  SETP (   ')
 
 
  

  
   


  

      

 
 
       
   * 
     
   
  

xl +

xnl  

  


   



  
+    

x 
   
     
   
   SETP     
  

" &  !  

   
     !
  ,
   
 $      !   
 
   
   !   

 selec         
       
&
 
 !     
&
   


x    
 
"    
 !   
  
 -

  
   
 !
     .#

  
     
 

 / 
   !  

xl 

xnl0  

    
   selec


 
 
"     
   
 
  ! 
   
   


!
 
  
      
     
   

  
  selec 

  
  '
   ! '
   
 "  
     
   SETP       

 
        


  

x   
 
 
!   
   
    

   &   )   !
  
  selec    )
1
      SETP / 

i0 *    
    
selec
2

    "

   
688 Aplicaciones

   
 


  



 
    selec 
 
 
    
  
 


  

   
 

 
      

   
  

  
 !

 " 
"
  
 SETP   
 
 



 
# $

 
       
  

xl   
 %


     

  

 

  !   
selec



 
 ! 
    
  
  

 
   

     


  
    
    
selec !    &   

   
  
"   

x
' 

  

 (
  
   
  ()    

   *
  +,



  
"    

 
  -. /

  -.  "
  
  +,  

 




 -#. /  
 -0. 1   *
 



  
 
  23453 -6.
 4'553

  

     

"
    

  " ()
 " 
 7
)     

( 


   /
  
  

  
  

 *        


 
  () "   


 
    
 7  
  
  
  

  

 ()  " 
 

  / 
      
&

 

"

 " 
 
 
+,  
    
    
   

  ! 
  
 
 
  " 
  8 (

  


 selec  
 

    
 t = 100K
 
 
   


    

 
 

 

8 






   

  


      


 
   / 
 7 
 

   
    

  





  
   
  

 





 /  
    
    





     +, 
 

  
 %
 

 


    

   "    
 
  
   
    
    

x  
  
      
"  
   

  
  &    

  
  

   
   *
 
    

  
  
   

%  

   selec 4


 )
     

  !   
  
  
"  
  
 
 

    " 
    


 / 
   
   




 !
  offset  
  
  
 $ 

    

  
      
 
XVI Jornadas de Paralelismo, JP '2005 689

  


 selec  
 


   
 t = 100K

 









 
    
   






 

 

  


 
     


 




  


  
 

   

 
 selec 



  
  

  
      

 


 


!   


  
  
   



 1 : 2 ∗ 104
 " #  
   
 
  SETP  

    
      


   
  selec  
   









 

     




 
$   
 %
    




   




& 


 
    

  

 



   

 
  







    
 

 
 
'  
  
    (    






x 


 

   bytes
 


 

 



  (

 ) 

 
 
 




 
*) 






  +, -$.  "  /* 

 
   round − robin 

*)  
    
 
 01
& 


   
  
 


 
  
 2Np3  

  


 "



 
% 
     2NE/S3 

 
4   

' 

 

%    
    

5 3  
 
  
  


#MSGtodos6 73 



' /  

 
 
 #MSGord6 83  



' /     


 #MSGno−ord &
 



  9+:;& 








 /
' 
%



    )  
   

   5  '    
 
     NP = 32  NE/S = 4


      ' 

  
  NP = 256  NE/S = 64   


 NP = 32  NE/S = 4 
 
<
  

'  
 





   



 

 

 


 
* 
    

   #    

 




  

  
  
# 
 


 


' 
  




 

  
  
 

xnl  


  
 '  
 ½
  


 
 
  

  
   
'  
 


 


    ;
 

'     



 
   
  *



'  
%   
 
 2 
42
33     
  



  
 




 

  
 


   


%  
   ;
 
'
   

2 
4233 

½
   
  
 

  nlist  
   

         
690 Aplicaciones

 NP = 32  NE/S = 4
 NP = 64  NE/S = 16
 NP = 256  NE/S = 64

  
   
 

 
 
  


  
 



  




   








   
   





 #MSGtodos  
   

   
 





 


 

  

 
 


 





 
   

     
 
    
 
 

 
 
   

  
  
  

   

  
 
  

      
 

   !   

 !
    
  
"

#  






$






 %






$ &''(       


    
  "

)  
 




*
    




 
    
 



 

 

+
 




*

$ 



 








 
!

 
 ,  


 
  




!

 

$ 


$   
 

 

 


$   
    

 

*
 


$       +
  
  
  
 




    
+ 

  
  
   -  .
 
 


 
   


  




$  


    
 


  
 

   

 




  + 

   

 


$  
$  
 

.

 




 ,
 



  
 
   
  $ 
 


*
  
  .
  
  
 

  

 +  
    


*
  

   $
 
XVI Jornadas de Paralelismo, JP '2005 691





 
 
     

 
 
   


 



 
 
    
 !
  "
 #$$$%& #
 '

   
   

 (

)*


+))*,
+ -, #
  , "
 


 

 
 



"
 #$$$ #
 !  
 
 (
 ../.*. +)).,
. 0, 1  
 
   


  , !   -
 2'$3#4
',  5
 ' 0
 
#

66*,
* 7,  
 , 89  ,  
 
 
   

      , !
#'    #%5
 
  '
66.,
: , "  ,   $,  
 !  "

  # 
 , !   ; '
    -

 ! &
  

(

<+
<6
666,
/ ', 7, 
 $  

 
 !
 # 
  
 7 ! 
  

(


6
66:,
; ,=,  ,8, 
 ### , 8,  
, "  $!   $ ! 

 %& "'  
 !   *
 
> ' 9   ! 
  +))),
692 Aplicaciones
Docencia en Arquitectura y
Tecnología de Computadores
Gestión de la interconexión de una red de múltiples tecnologías:
planteamiento práctico en el laboratorio
Xabier Subijana1
A900466@alumni.tecnun.es
Nuria Rodríguez1,2
nrodriguez@ceit.es
Nuria Cañamares1,2
ncanamares@ceit.es
Enrique Reina1
ereina@tecnun.es
Paul Bustamante1,2
pbustamante@ceit.es
1 Tecnun (Universidad de Navarra) Manuel de Lardizábal 13, 20018 San Sebastián, Spain
2 CEIT, Manuel de Lardizábal 15. 20018 San Sebastián, Spain
Resumen
Aunque la tendencia actual de las redes es la
convergencia hacia redes completamente IP, la
actualidad nos muestra redes diferentes sobre las
que se ofertan todo tipo de servicios. La
convergencia de redes de diferentes tecnologías
sigue planteando hoy en día serios problemas. El
laboratorio que se presenta en este artículo
permite a investigadores y alumnos configurar
entonos de análisis de gestión de un conjunto de
redes interconectadas. Para presentar las
múltiples posibilidades de simulación y de
docencia de este laboratorio se presenta la red
implementada gracias al trabajo de los alumnos.
La configuración de este proyecto de red les ha
permitido experimentar tanto los problemas
técnicos derivados de la configuración como los
problemas comunes de un ingeniero en cuanto a
fechas límite, conflicto de intereses o problemas
de gestión.
1. Introducción
La tendencia actual en las redes de comunicación
es la convergencia en la transmisión de datos para
proporcionar servicios sobre diferentes terminales
de comunicaciones. Sin embargo, en las redes ya
instaladas se observa una falta de integración de
tecnologías siendo necesario el empleo de equipos
de interconexión para posibilitar la comunicación
entre usuarios de diferentes redes.
El objetivo en el diseño de una red es el
dimensionamiento de la misma para que
transporte cualquier tipo de tráfico,
proporcionando un servicio con los requisitos de
calidad necesarios y de modo transparente a las
redes que se conectan a ella. Por este motivo la
interconexión de redes se realiza a través de
dispositivos que soportan múltiples protocolos y
permiten la conversión entre ellos adaptando los
parámetros de calidad de servicio a las diferentes
redes.
Todos estos problemas se afrontan en el
laboratorio de Modelado y Dimensionado de
Redes Telemáticas, mediante la construcción y
simulación de una red que incluye diversas
tecnologías como ADSL (Asymmetric Digital
Subscriber Line), RDSI (Red Digital de Servicios
Integrados), Frame Relay, ATM (Asynchronous
Transfer Mode) o accesos inalámbricos.
El objetivo de la asignatura es definir y
configurar un esquema de red que abarque
diferentes tecnologías y que incluya los diversos
agentes que pueden intervenir en el marco del
mercado de telecomunicaciones de datos actual.
El escenario propuesto, está constituido por un
proveedor de servicios de Internet (TECNUN-
Telecom), un proveedor de contenido
(MIIEurope) y varias empresas (R&R Asociados)
y clientes particulares que le han contratado a
MIIEurope el acceso a internet, el correo
electrónico y unos cursos de formación vía
streaming de video. Cada una de estas entidades
ficticias está integrada por un grupo de estudiantes
que interpreta el papel asignado por el
administrador de la red. Este administrador,
compuesto por tres alumnos, se encarga de la
organización que permite crear una red de redes
interconectadas que ofrecen los servicios
contratados a los diferentes usuarios finales.
2. Estado del arte
2.1. Tecnologías actuales
Hoy en día, las empresas combinan diferentes
tecnologías para satisfacer sus necesidades de
comunicación y obtener una red de información
de buena calidad. En la vida laboral diaria es
habitual la comunicación entre ordenadores de
distintas redes, por ejemplo, un PC conectado a
una red inalámbrica en una oficina y un cliente
particular llamando desde su casa a través de una
línea RDSI o ADSL. Por este motivo el objetivo
del laboratorio es configurar y analizar las
distintas tecnologías disponibles en el mercado
para formar una red de interconexión global. Las
tecnologías de comunicación presentes en el
laboratorio son:
1) ATM: es una tecnología para redes
troncales basada en la conmutación de celdas que
ofrece un formato común para servicios de
diferentes anchos de banda. Permite definir
calidades de servicio (QoS) lo que le convierte en
una tecnología muy apropiada para transmisión de
video, voz y datos. Se implementará en el núcleo
de la red porque proporciona conmutación de
celdas de gran velocidad y es apropiada para la
interconexión de múltiples redes IP, Frame Relay,
Ethernet, xDSL, acceso inalámbrico y
SONET/SDH que transportan servicios de banda
ancha [1], [2], [3].
2) Frame Relay: se emplea en los enlaces de
alta capacidad entre dos sedes de una misma
empresa o entre diferentes compañías cuando se
requiere establecer una comunicación de datos
fiable punto a punto. Frame Relay hace un mejor
uso del ancho de banda compartido que su
predecesor, X25, empleando una técnica de
conmutación más rápida. [4].
3) ADSL: permite la transmisión de vídeo por
la línea de teléfono tradicional y se va a emplear
para dar conectividad banda ancha de acceso a
Internet a los clientes particulares. También se
utiliza como línea de back-up para mantener la
comunicación cuando falla la conexión principal
permitiendo encauzar provisionalmente el tráfico
hasta solucionar el problema. El término
“asimétrico” significa que el ancho de banda
empleado para el enlace descendente es mayor
que para el ascendente. [5].
4) RDSI: permite la transmisión de voz, datos
y vídeo sobre el canal digitalizado de la red
telefónica. Se utiliza para videoconferencias y
para el acceso a Internet de los clientes
particulares que dispongan de esta tecnología. Es
importante destacar que, con la aparición de
ADSL, RDSI tiende a desaparecer. Sin embargo
RDSI es una tecnología presente en el mercado
actual y se implementa en el laboratorio porque
desde un punto de vista pedagógico permite
comprender mejor la evolución de las redes de
datos [6].
5) La tecnología de acceso inalámbrico está
adquiriendo un papel cada vez más importante en
las comunicaciones, donde se valora la movilidad
y la ausencia de cableado. Estas características no
sólo facilitan la conectividad sino también
aumentan la versatilidad de las redes de oficina.
En el laboratorio se incluyen redes locales
inalámbricas (WLAN) para que cualquier
ordenador portátil con una tarjeta Wi-Fi
(Wireless-Fidelity) pueda acceder a esta red,
asignándole una dirección IP temporal al
registrarse en ella.
6) Radioenlace de microondas: permite crear
enlaces punto a punto que sustituyen a los cables
serie. Su alcance es mayor que el de los accesos
Wi-fi y su aplicación inmediata es en
comunicaciones de visibilidad directa entre
edificios próximos.
7) Para dar una visión global de las diversas
opciones de acceso a internet disponibles en el
mercado así como de las implementadas
internamente en cada empresa, se configurarán
redes locales tipo Ethernet y conexiones
analógicas de un PC a través de un módem.
La utilización de las diferentes tecnologías
para construir una red ofrece a los estudiantes la
oportunidad de aplicar el conocimiento adquirido
previamente en asignaturas teóricas del área de
redes y telemática. Además, la opción de trabajar
directamente con los equipos, tanto con el
hardware como el software disponible en el
laboratorio, les permite enfrentarse a situaciones
reales.
2.2. Otros laboratorios de referencia
Este laboratorio es comparable al laboratorio de
redes telemáticas de la Universidad Politécnica de
Madrid, en el que se emplean tecnologías
similares para las prácticas que realizan los
alumnos [7]. Sin embargo en el laboratorio de la
UPM se han establecido estructuras de red
predefinidas y entornos de configuración para las
diferentes tecnologías, lo cual hace que sea un
laboratorio menos versátil que el que se propone
en este artículo.
696 Docencia en Arquitectura y Tecnología de Computadores
3. Planteamiento del problema
Una vez que se han presentado las diversas
tecnologías es necesario presentar el papel que
realiza cada uno de los agentes que forman parte
de la red para orientar el planteamiento general
hacia el trabajo de configuración a realizar.
Además, con idea de dotar de mayor realismo a
las prácticas que llevan a cabo los alumnos, se
asigna a cada empresa proveedora o cliente un
emplazamiento real, con un equipamiento propio
y en algunos casos una Intranet establecida
previamente que debe ser tenida en cuenta a la
hora de diseñar la interconexión. El escenario a
configurar es el siguiente:
IIEurope es la compañía que oferta acceso a
Internet, correo electrónico e información
audiovisual de pago a sus clientes, permitiéndoles
descargar cursos de formación pregrabados o
eventos en vivo desde su página Web. Esta
compañía tiene sus oficinas centrales en Bruselas,
donde tiene los equipos de red necesarios para
ofrecer sus servicios. También dispone de un
firewall, FW-1 Checkpoint, que protege la
Intranet de la empresa y la información
confidencial de posibles intrusos. MIIEurope
además tiene su sede social en Luxemburgo con
conexión directa a Bruselas a través de una línea
dedicada con backup por RDSI. Las llamadas de
voz entre ambas oficinas se realizan a través de
VoIP, haciendo uso de la línea directa entre ambas
sedes, sin necesidad de pagar cada llamada al
operador telefónico.
Por otro lado, se celebra una feria en Francia
en donde un empleado de MIIEurope tiene un
stand y necesita una conexión RDSI para hacer
demostraciones de los productos multimedia que
oferta la empresa. Esta conexión también se
utiliza para su teléfono IP. Además, se aloja en un
hotel donde necesita una red privada virtual
(VPN) con su oficina en Bruselas.
Uno de los mejores clientes de MIIEurope es
R&R Asociados en España. Este cliente contrata
un enlace punto a punto para conectarse a
MIIEurope con backup seguro por ADSL. Para
garantizar la confidencialidad de los datos de la
línea de backup se configura un túnel VPN.
Otro cliente particular de MIIEurope en
España se conecta a través de un módem
analógico para acceder a los servicios de
MIIEurope a través de su página Web.
TECNUN-Telecom es el proveedor de
servicios de Internet, y se encargará de establecer
las redes y las comunicaciones necesarias para las
empresas y los clientes particulares. Esta empresa
dispone de todos los equipos necesarios para
ofrecer un servicio de calidad entre todos los
agentes que participan en la red. Para realizar la
interconexión entre los diferentes usuario utiliza
un backbone ATM para dar servicio a clientes
ADSL y una central telefónica para los clientes
analógicos y RDSI. Ambos equipos se muestran
en la figura 1.
a) Backbone ATM
b) Centralita telefónica
Figura 1: Equipos del laboratorio
El gran reto de resolver el problema de
interconexión ha sido llevado a cabo dividiendo el
trabajo en pequeñas tareas y distribuyéndolas
XVI Jornadas de Paralelismo, JP '2005 697
entre los estudiantes que participan en el
laboratorio, de forma que cada grupo pueda
realizar su trabajo eficientemente y sin interferir
en el resto. Además la división de trabajo
posibilita la detección de problemas de forma más
sencilla antes de concluir el proyecto en su
totalidad.
4. Metodología
Para afrontar un proyecto de la envergadura del
trabajo presentado en el apartado 3, se divide a los
estudiantes en grupos de tres personas que
analizan los requerimientos de la red por separado
y plantean soluciones diversas. De las propuestas
viables se escoge la que se va a implementar, que
se recoge en la figura 2. El grupo responsable de
la red se erige como administrador de red para
coordinar, supervisar y establecer los criterios de
verificación del funcionamiento de la red.
4.1. Definición de la topología de red
El primer paso en el proyecto de interconexión es
la definición de la topología de red que cubra las
necesidades de comunicación explicadas en la
sección tercera del artículo, teniendo en cuenta el
equipamiento disponible en el laboratorio. Este
problema inicialmente teórico, adquiere cierta
complejidad práctica debido tanto a la
disponibilidad limitada de equipos en el
laboratorio, como a la imposibilidad de adquirir
otros nuevos. La solución real del proyecto debe
contemplar todos estos aspectos y los alumnos
deben encontrar la mejor solución posible.
Cada tecnología seleccionada y cada equipo
debe ajustarse a los servicios requeridos por cada
uno de los usuarios, tratando de emplear el
mínimo número de elementos en cada una de las
redes. Es imprescindible el empleo de routers que
convierten las tramas de datos de unas tecnologías
a otras y permiten la interconexión entre redes con
distintos protocolos y tecnologías. El diseño de la
red se muestra en la figura 2, donde pueden
observarse tanto los equipos empleados como los
enlaces entre las distintas entidades.
MIIEurope es una de las secciones más
importantes en el proceso de interconexión y la
base de prestación de servicios de la red. El
firewall, como elemento principal de seguridad en
Cisco 2503
Servidor Web Servidor de vídeo
Cisco 2503
Cisco 1760
CallMAnager
Red Local
DSLAM
Light Stream
Cisco 1720
Cisco 1601
Airlink
Cisco 2514
Cisco 801
PC WinXP
Cisco 1751V
Módem analógico
Red Local
MIIEurope
Bruselas
MIIEurope
Luxemburgo
TECNUN
Telecom
Cliente
Particular
Habitación de
hotel en París
Stand en la feria
de París
RDSI
RDSI
A
T
M
PBX
Cisco 3640
Airlink
Catalyst
Aironet 1100
Firewall
R&R
Asociados
Teléfono IP
Cisco 2503
Servidor Web Servidor de vídeo
Cisco 2503
Cisco 1760
CallMAnager
Red Local
DSLAM
Light Stream
Cisco 1720
Cisco 1601
Airlink
Cisco 2514
Cisco 801
PC WinXP
Cisco 1751V
Módem analógico
Red Local
MIIEurope
Bruselas
MIIEurope
Luxemburgo
TECNUN
Telecom
Cliente
Particular
Habitación de
hotel en París
Stand en la feria
de París
RDSI
RDSI
A
T
M
PBX
Cisco 3640
Airlink
Catalyst
Aironet 1100
Firewall
R&R
Asociados
Teléfono IP
Figura 2. Topología de la red construida por los alumnos en el laboratorio
698 Docencia en Arquitectura y Tecnología de Computadores
la empresa, debe instalarse con las correctas
políticas de seguridad para permitir a los clientes
y empleados acceder al servidor Web y al servidor
de vídeo. Además, los empleados también deben
poder acceder a Internet aunque evidentemente
por razones de seguridad, los clientes no deben
tener acceso a la red local interna de MIIEurope
[8].
El servidor de vídeo también se encuentra en
MIIEurope y debe configurarse para ofrecer
servicios multimedia Multicast y Unicast que
hacen posible la descarga de ficheros
audiovisuales y la transmisión de eventos en
tiempo real. Más información sobre configuración
en las referencias [9], [10], [11], [12].
Otra de las tareas a realizar es el diseño de la
página Web corporativa de MIIEurope, diseñada
para proporcionar acceso al correo Web, con los
correspondientes servidores POP3 y SMTP.
En cuanto a los enlaces de esta sede con el
resto de clientes, la compañía tiene dos
conexiones serie dedicadas de 2 Mbps sobre
Frame Relay con Luxemburgo y TECNUN-
Telecom, y un acceso a Internet a través de una
línea RDSI que se utiliza como backup.
MIIEurope en Luxemburgo también dispone
de enlaces serie y RDSI que deberán ser
configurados para establecer las conexiones
adecuadamente, aunque el equipo más importante
alojado en esta sede, es el Call Manager instalado
en un router 1760 de CISCO que gestiona los
teléfonos IP. Este equipo se combina con un
Catalyst 3500 imprescindible para crear las redes
locales virtuales necesarias en la gestión de los
teléfonos IP.
Por otro lado, R&R dispone de una conexión
Frame Raly con MIIEurope y realiza el backup
por ADSL. Además tiene una red local interna que
deberá ser tenida en cuenta a la hora de configurar
las conexiones. Debido a una ampliación de R&R,
esta red local se distribuye entre dos edificios
próximos conectados a través de un radioenlace
microondas. La segunda sede es una oficina de
comerciales sin puesto fijo, por lo que se ha
optado por configurar una WLAN.
El hotel y la feria en Francia dispondrán de
conexiones RDSI para acceder a MIIEurope a
través de TECNUN-Telecom sobre las cuales
serán implementados el acceso a Internet y el
servicio VoIP. Por otro lado el cliente particular
dispondrá de acceso a Internet a través de su
módem analógico.
Todos estos usuarios tienen necesidad de
conexión interna y externa por lo que contratan
los servicios de un proveedor de acceso a Internet
que cuente con los equipos y la infraestructura
necesaria para crear la red. Este proveedor debe
tener acceso a las redes internas de las diferentes
empresas privadas para terminar la configuración
de sus enlaces.
TECNUN-Telecom es el proveedor de
servicios de Internet que establecerá las redes y
ofrecerá servicios de comunicaciones tanto para
las empresas como para los clientes particulares.
Su equipamiento forma el núcleo central de la red
y está compuesto por el conmutador ATM,
LightStream 1010, el DSLAM 6015, el router
Cisco 3640 y una centralita telefónica para
usuarios analógicos y RDSI.
Una vez planeada cada sección de la red, se
debe definir el direccionamiento y
encaminamiento entre todos los equipos para
asegurar la conectividad. Las direcciones IP se
han asignado cuidadosamente a cada entidad de la
red en función de sus necesidades dividiendo la
red en subredes clase C. De esta forma, cada
compañía puede diseñar su red local en una clase
diferente simplificando así las tareas de
enrutamiento para dirigir el tráfico, y ofreciendo
además una visión más realista de la red, siendo
cada compañía independiente del resto.
Además de las direcciones IP, es necesario
establecer los circuitos virtuales privados (PVC)
necesarios para ATM y ADSL, los números DLCI
(Data Link Connection Identifier) para Frame
Relay, los números RDSI y analógicos y un plan
de numeración para los teléfonos IP. Además, es
necesario decidir los algoritmos de encriptación y
las contraseñas que se utilizarán en el
establecimiento de los túneles VPN. Toda esta
información debe ser elaborada por los
coordinadores de la red y debe ser explicada a
cada uno de los grupos de trabajo de forma que se
logre la correcta conectividad.
Finalmente las tareas deben ser divididas entre
todos los grupos de forma que no se solapen entre
ellos pero intentado asignar a cada uno, una única
tecnología. De esta forma, si un grupo está a cargo
de la conexión ADSL entre dos routers, ambos
deben estar libres al mismo tiempo para este
grupo, mientras que el resto están trabajando
sobre diferentes tecnologías en otros equipos. Este
aspecto condicionará la velocidad en el desarrollo
de la práctica ya que el trabajo en paralelo sólo
hace más rápida la finalización del mismo, si éste
está correctamente dividido.
XVI Jornadas de Paralelismo, JP '2005 699
4.2. Asignación de tareas
Una vez que el administrador de la red decide la
topología de la red y establece las tareas
apropiadamente, se transmite esta información a
los líderes de los demás grupos, distribuyendo el
equipamiento del que van a disponer durante la
práctica así como los parámetros a configurar
según la tecnología que implementan.
1) Un primer grupo estará a cargo de la
Intranet de R&R Asociados, lo que incluye la
configuración de los routers Cisco 1601, Cisco
2514, el radioenlace microondas y el punto de
acceso para la WLAN
2) Otro grupo configurará el enlace entre
TECNUN-Telecom y R&R Asociados, para lo
cual empleará los routers Cisco 3640 y 1720. Para
asegurar la conectividad en caso de que haya
algún problema en el enlace primario, también se
creará una línea ADSL como back-up, por lo que
la tarea, también incluirá la configuración del
DSLAM y el LightStream.
3) La tercera tarea consiste en configurar el
router Cisco 3640. Este es el equipo más
importante de la red ya que todas las
comunicaciones lo atraviesan. Por este motivo, la
tabla de rutas será crítica y deberá ser diseñada
cuidadosamente. Además hay una dificultad
añadida debido a que otros grupos también
necesitan este router para terminar sus enlaces,
siendo imprescindible una correcta coordinación
de las configuraciones sobre este equipo.
4) La Intranet de las oficinas de MIIEurope en
Bruselas y la configuración del firewall y del
servidor de vídeo estarán a cargo de otro grupo. El
firewall se debe configurar con los permisos
correctos. Por otro lado el router Cisco 2503 debe
conectarse a TECNUN-Telecom a través del
router 3640. En el servidor Web, se deberán
instalar un servidor POP3 y otro SMTP además de
un servicio de correo Web para permitir a los
clientes consultar el correo desde la página Web.
5) El enlace RDSI será implementado por otro
grupo, para conectar la feria en Paris a la PBX en
TECNUN-Telecom que proveerá VoIP sobre la
feria. La conexión de los clientes particulares a
través de módem analógico también estará a cargo
de este mismo grupo.
6) Otro grupo de trabajo estará a cargo del
enlace de 2Mbps sobre V35 entre Bruselas y
Luxemburgo. También configurarán las líneas
RDSI entre el hotel de Francia, con el router Cisco
801, y TECNUN-Telecom.
7) El último grupo se encargará de la
implementación de VoIP, configurando el
Catalyst, el router Cisco 1760 y el CallManager
con los teléfonos IP.
Distribuyendo de esta forma las tareas, cada grupo
es responsable de una pequeña parte de la red,
siendo la configuración de cada parte una tarea
esencial para obtener la conectividad básica.
Además se hace necesaria la colaboración entre
diferentes grupos de trabajo para realizar los
enlaces de extremo a extremo entre dos sedes y al
igual que en una red real, cada agente sigue sus
propios objetivos para terminar la conexión.
Evidentemente todos estos aspectos añaden una
mayor dificultad al proyecto ya que es necesario
llegar a acuerdos que satisfagan lo máximo
posible a las partes implicadas. Por lo tanto a
pesar de tratarse de una red implementada en un
laboratorio, se ha tratado de darle un enfoque
similar al de un caso real.
4.3. Configuración básica
Una vez asignadas las tareas, el siguiente paso
consiste en configurar la topología básica de la red
para obtener conectividad entre todos los
elementos que la componen. Cada grupo deberá
seguir las instrucciones dadas por el administrador
de la red, quien asegura la correcta realización de
las mismas.
En este paso, pueden aparecer múltiples
problemas en caso de que algunas tareas se
solapen con otras. Las previsiones realizadas no
siempre son adecuadas y es necesario que el
administrador de la red medie para llegar a un
acuerdo entre las partes implicadas. Como en una
situación real los plazos son importantes, cada
grupo de trabajo debe terminar su parte asignada
antes de la fecha límite lo que permite a los
estudiantes enfrentarse a problemas que afrontarán
en un futuro cercano.
Otros problemas encontrados que necesitan
una solución rápida son las posibles
incompatibilidades entre equipos y la necesidad
de actualizaciones de los sistemas operativos o de
alguna tarjeta nueva. La habilidad de resolver
estos problemas permite a los estudiantes poner en
práctica la teoría, buscando soluciones que
cumplan con las especificaciones buscadas de la
mejor forma posible.
700 Docencia en Arquitectura y Tecnología de Computadores
4.4. Configuración Avanzada
La configuración básica no es suficiente ya que la
red no es capaz de ofrecer los servicios propuestos
en el planteamiento inicial. La conexión entre
Bruselas y el hotel de Francia, así como entre
Bruselas y R&R en España debe ser segura y por
lo tanto se requiere la configuración de redes
privadas virtuales (VPN). La implementación está
basada en IPSec (Internet Protocol Security) [13],
un conjunto de protocolos que encriptan los datos
para hacer seguro el intercambio de información.
Para llevar a cabo esta tarea, se deben emplear
routers que soporten este protocolo, como son el
Cisco 1720 y el 3640. Para terminar las VPN en
un PC, éste debe disponer de un sistema operativo
con las herramientas necesarias para asegurar la
fiabilidad de los datos a través de la red, en
nuestro caso Windows XP. La configuración
puede obtenerse en la referencia [14].
Por otro lado, las llamadas de voz sobre IP
tampoco son posibles sólo con la configuración
básica aunque es necesario garantizar la
conectividad antes de implementar la
configuración de los teléfonos IP. Una vez que se
completa ésta, el grupo encargado de VoIP puede
llevar a cabo su tarea. La idea, es crear una
solución económica para las llamadas internas de
la empresa en lugar de tener que pagar a un
operador de teléfono, usando los enlaces de los
que dispone.
La única forma de hacerlo es digitalizando la
voz y transmitiéndola a través del enlace de datos
dedicado contratado por la empresa al operador de
servicios de Internet. Evidentemente se deberán
asegurar los parámetros de calidad de servicio
(QoS) necesarios que permitan mantener una
conversación, como puede ser los máximos
retardos admisibles. Este es el objetivo principal
que el grupo encargado de la configuración de
VoIP debe lograr. El mejor modo de solucionar el
problema será estudiando los parámetros
requeridos para una calidad de servicio mínima y
comprobando que el enlace cumple con las
previsiones.
4.5. Implementación del QoS
La definición e implementación de los parámetros
de QoS en cada una de las redes para difusión de
streaming de vídeo es la última etapa que debe
completarse antes de que puedan ofrecerse
correctamente los servicios a través de la red [15].
Se debe hacer un estudio en profundidad para
obtener los parámetros de calidad que requieren la
transmisión de vídeo y voz a través de la red.
4.6. Chequeo de la red y comprobación de
resultados
Cuando cada grupo termina la tarea asignada,
antes de la fecha fijada, es necesario realizar una
verificación final de toda la red. El administrador
de la red debe planificar una estrategia de
comprobación para detectar cualquier error o
punto débil en la red.
1) Operación en condiciones normales: cada
PC de la red debe ser capaz de visitar la página
Web de MIIEurope, consultar el correo desde su
propia cuenta y descargar ficheros de vídeo.
Además, cada usuario debe recibir en tiempo real
el streamming de video conectándose al punto de
publicación que incluye MIIEurope en su página
web.
2) Comprobación de backups: para asegurar
que las líneas de back-up de RDSI y ADSL están
operando correctamente, la línea principal se
desconecta y se comprueban todos los servicios.
La calidad de servicio ofrecida por la nueva red
debe ser la misma.
3) Acceso simultáneo a la red: todos los
clientes deben acceder a la página Web de
MIIEurope al mismo tiempo y conectarse al vídeo
que se está difundiendo en esos momentos en
tiempo real. Esto permitirá comprobar si la red
puede trabajar al máximo de sus capacidades.
4) Comprobación de las VPN: se debe poder
acceder a los ficheros compartidos desde ambos
lados de la red privada virtual.
5) Llamadas VoIP: comprobación de la
calidad en las conversaciones y multiconferencias.
5. CONCLUSIÓN
Este laboratorio ha permitido a los estudiantes
llevar a cabo un proyecto global con equipamiento
real para resolver un problema concreto de
interconexión posible con la tecnología actual. La
oportunidad de configurar diferentes equipos,
afrontar los problemas de hardware y software,
entender las características practicas de las
diferentes tecnologías estudiadas en la teoría,
XVI Jornadas de Paralelismo, JP '2005 701
considerar los requerimientos necesarios para
ofrecer un servicio concreto y conocer la
infraestructura necesaria para construir una red es
una experiencia muy enriquecedora que redondea
los cinco años de la carrera de
telecomunicaciones. Ofrece a los estudiantes una
experiencia real sobre los problemas que
encontrarán en el campo de la ingeniería.
El trabajo en grupo y la necesidad de un
coordinador dota al proyecto de un aspecto
humano donde se mezclan los intereses de las
diferentes compañías y la presión de un tiempo
límite para terminar el proyecto. Además estimula
habilidades como la gestión de proyectos, tan
importante en la vida de un ingeniero.
REFERENCIAS
[1] Historia de ATM, disponible en el ATM Forum
http://www.atmforum.com/aboutatm/history.html
[2] Aspectos generles sobre ATM disponible en el ATM
Foru
http://www.atmforum.com/aboutatm/guide.html
[3] Documentación sobre ATM disponible en Cisco
http://www.cisco.com/univercd/cc/td/doc/cisintwk/it
o_doc/atm.htm
[4] Documentación sobre Frame Relay disponible en
Cisco
http://www.cisco.com/univercd/cc/td/doc/cisintwk/it
o_doc/frame.htm
[5] Documentación sobre DSL disponible en Cisco
http://www.cisco.com/univercd/cc/td/doc/cisintwk/it
o_doc/dsl.htm
[6] Documentación sobre ISDN disponible en Cisco
http://www.cisco.com/univercd/cc/td/doc/cisintwk/it
o_doc/isdn.htm
[7] Laboratorio de Telemática de la Universidad
Politécnica de Madrid. http://www.dit.upm.es/lbrst
[8] Preguntas frecuentes sobre Firewalls
http://faqs.org.ru/en/lan/firewalls-faq.htm
[9] Information about Windows Media Encoder
http://www.microsoft.com/technet/prodtechnol/nets
how/evaluate/wencoder.mspx
[10] Teoría general sobre streaming de vídeo
http://nno.uni.lodz.pl/ftp/windows/windowsmedia/
mediaserver/wmserver/srvr_admin1.doc
[11] Implementación de Unicast
http://nno.uni.lodz.pl/ftp/windows/windowsmedia/
mediaserver/wmserver/srvr_admin2.doc
[12] Implementación de Multicast
http://nno.uni.lodz.pl/ftp/windows/windowsmedia/
mediaserver/wmserver/srvr_admin3.doc
[13] Configuración de seguridad de redes:
http://www.cisco.com/en/US/products/sw/iosswrel/
ps1831/products_configuration_guide_chapter0918
6a00800d981f.html
[14] “Configuring IPSec between a Microsoft Windows
XP professional (1NIC) and the VPN router”
http://www.inter-
comp.pl/pub/manual/IP3014_VPN%20.pdf
[15] Architecture for Voice, Video and Integrated Data,
http://www.cisco.com/warp/public/cc/so/neso/vvda/
iptl/avvid_wp.htm
702 Docencia en Arquitectura y Tecnología de Computadores
8QDDSUR[LPDFLyQDODHMHFXFLyQHQFDGHQDGHLQVWUXFFLRQHV
&DUORV5LRMDGHO5tR-RVp05RGUtJXH]&RUUDO$QWyQ&LYLW%DOFHOOV
'HSDUWDPHQWRGH/HQJXDMHV\VLVWHPDV,QIRUPiWLFRV
8QLYHUVLGDGGH&iGL]
FDUORVULRMD#XFDHVMRVHPDULDURGULJXH]#XFDHV
'HSDUWDPHQWRGH$UTXLWHFWXUD\7HFQRORJtDGH&RPSXWDGRUHV
8QLYHUVLGDGGH6HYLOOD
FLYLW#XVHV




5HVXPHQ

$EVWUDFW,QWKHSUHVHQWZRUNZHXQGHUWDNH
D ILUVW DSSURDFK WR WKH LQVWUXFWLRQV
SDUDOHOLVP  7KLV DSSUR[LPDWLRQ LV PDGH E\
WKH GHYHORSPHQW RI D WRRO RI VLPXODWLRQ E\
FRPSXWHURIDSURFHVVRULQFKDLQRUSLSHOLQH
7KLV ZLOO SHUPLW WR FDUU\ RXW DQ H[HFXWLRQ
VWHSE\VWHSRIWKHLQVWUXFWLRQVWRREVHUYHWKH
SURFHVV RI H[HFXWLRQ LQ FKDLQ DQG KRZ WKH
IXQFWLRQDOXQLWVJRFDUU\LQJRXWWKHGLIIHUHQW
SKDVHV LQ WKH H[HFXWLRQ  7KH WRRO RI
VLPXODWLRQ KDV WZR PDLQ XWLOLWLHV
(GXFDWLRQDO VDPSOH WKH H[HFXWLRQ FKDLQHG
VWHS E\ VWHS ZKLFK IDFLOLWDWHV LQ JUHDW
PHDVXUHWKHFRPSUHKHQVLRQRIWKHFRPSOHWH
SURFHVV  5HVHDUFKHU VHUYHV DV EDVH ZHOO
VXSSRUWHGWRREVHUYHDQGWRDQDO\]HGLIIHUHQW
FRQILJXUDWLRQV RI SURFHVVRUV DQG VHWV RI
LQVWUXFWLRQVIRUVHHWKHEHKDYLRURIWKHVDPH
RQH
5HVXPHQ(QHOSUHVHQWHWUDEDMRDERUGDPRV
XQ SULPHU DFHUFDPLHQWR DO SDUDOHOLVPR GH
LQVWUXFFLRQHV(VWDDSUR[LPDFLyQPHGLDQWHHO
GHVDUUROORGHXQDKHUUDPLHQWDGHVLPXODFLyQ
SRUFRPSXWDGRUGHXQSURFHVDGRUHQFDGHQD
R SLSHOLQH (VWR SHUPLWLUi UHDOL]DU XQD
HMHFXFLyQ SDVR D SDVR GH ODV LQVWUXFFLRQHV
SDUD REVHUYDU HO SURFHVR GH HMHFXFLyQ HQ
FDGHQD\FyPRODVXQLGDGHVIXQFLRQDOHVYDQ
UHDOL]DQGRODVGLVWLQWDVHWDSDVHQODHMHFXFLyQ
VHJPHQWDGD /D KHUUDPLHQWD GH VLPXODFLyQ
WLHQH GRV XWLOLGDGHV SULQFLSDOHV 'RFHQWH
PXHVWUDODHMHFXFLyQHQFDGHQDGDSDVRDSDVR
OR FXDO IDFLOLWD HQ JUDQ PHGLGD OD
FRPSUHQVLyQ GHO SURFHVR FRPSOHWR
,QYHVWLJDGRUD VLUYH FRPR EDVH ELHQ
IXQGDPHQWDGD SDUD REVHUYDU \ DQDOL]DU
GLVWLQWDV FRQILJXUDFLRQHV GH SURFHVDGRUHV \
GH FRQMXQWRV GH LQVWUXFFLRQHV SDUD YHU HO
FRPSRUWDPLHQWRGHOPLVPR
 ,QWURGXFFLyQDODVHJPHQWDFLyQ
/D VHJPHQWDFLyQ GH LQVWUXFFLRQHV WDPELpQ
FRQRFLGRFRPRSLSHOLQLQJIXHHQVXGtDXQD
UHYROXFLyQHQHODXPHQWRGHOUHQGLPLHQWRGH
ORVPLFURSURFHVDGRUHV8VDQGRHOHMHPSORGH
XQD FDGHQD GH HQVDPEODMH SRGHPRV
DFHUFDUQRV D OD VHJPHQWDFLyQ LPDJLQDQGR
TXH FDGD LQVWUXFFLyQ SDVD SRU XQD VXEHWDSD
HQ VX HMHFXFLyQ $O GLYLGLU OD HMHFXFLyQ GH
LQVWUXFFLRQHV GHO PLFURSURFHVDGRU HQ
GLVWLQWDVSDUWHVSRGUHPRVHMHFXWDUGHPDQHUD
FRQFXUUHQWH GLVWLQWDV VXEHWDSDV GH GLVWLQWDV
LQVWUXFFLRQHVFRQODFRQVLJXLHQWHUHGXFFLyQ
HQ HO Q~PHUR TXH GHWHUPLQD HO UHQGLPLHQWR
GHO PLFURSURFHVDGRU \ GHO VLVWHPD HQ
JHQHUDOHO&3,5HGXFLUHOQ~PHURGHFLFORV
SRULQVWUXFFLyQR&3,HVODILQDOLGDGSULQFLSDO
TXHGHEHPRVEXVFDUVLTXHUHPRVDSURYHFKDU
DOPi[LPRODVFDSDFLGDGHVGHOFRPSXWDGRU



 

1ž,QVW         
,QVWL ,) ,' (; 0(0 :%    
,QVWL  ,) ,' (; 0(0 :%   
,QVWL   ,) ,' (; 0(0 :%  
,QVWL    ,) ,' (; 0(0 :% 
,QVWL     ,) ,' (; 0(0 :%

7DEOD HMHFXFLyQLGHDOHQFDGHQD
7RGDV ODV HWDSDV HQ OD HMHFXFLyQ GH XQD
LQVWUXFFLyQ HVWiQ FRQHFWDGDV HQWUH Vt \ OD
LQVWUXFFLyQYDSDVDQGRGHXQDHWDSDDRWUD
FRPR VL GH XQD WXEHUtD SLSH VH WUDWDVH
3ULQFLSDOPHQWH WHQGUHPRV ODV VLJXLHQWHV
HWDSDV

• ,),QVWUXFWLRQ)HWFKHWDSDGHE~VTXHGDGH
LQVWUXFFLyQ \ SRVWHULRU SDVR D D OD FROD GH
LQVWUXFFLRQHV
• ,',QVWUXFWLRQ'HFRGHGHFRGLILFDFLyQ GH
ODLQVWUXFFLyQHQODTXHVHPLUDVXWLSR\VH
HQYtD D ODV XQLGDGHV IXQFLRQDOHV
FRUUHVSRQGLHQWHV
• (;R0(HMHFXFLyQGHODLQVWUXFFLyQ\DVHD
HQXQLGDGHVOyJLFRDULWPpWLFRRXQLGDGHVGH
FDUJDDOPDFHQDPLHQWR HQ PHPRULD SUHYLR
FiOFXORHIHFWLYRGHODGLUHFFLyQ
• :%:ULWH%DFNHWDSDILQDOGHILQDOL]DFLyQ
GHODLQVWUXFFLyQ\HVFULWXUDGHORVUHVXOWDGRV
FRUUHVSRQGLHQWHV

3RUVXSXHVWRDOJXQDVHWDSDVVRQPiVOHQWDV
TXHRWUDV\VRQHVWDVODVTXHGHWHUPLQDQHO
WLHPSRGHHMHFXFLyQGHELGRDORVEORTXHRV
TXHSXHGDQSURGXFLUVHSRUODVGHSHQGHQFLDV
GH GDWRV R SRU IDOWD GH XQLGDGHV
IXQFLRQDOHV,GHDVFRPRODVXSHUHVFDODULGDG
SXHVWD GH PDQLILHVWR HQ ORV SURFHVDGRUHV
3HQWLXP GH ,QWHO‹ \ SRVWHULRUHV /D
PHPRULD GH GHVWLQR GH VDOWRV R EUDQFK
WDUJHWEXIIHU>+(1@\ORVSURFHGLPLHQWRV
FRPRHOUHRUGHQDPLHQWRGHLQVWUXFFLRQHV\
UHQRPEUDGRGHUHJLVWURVVRQDYDQFHVHQHO
DXPHQWR GHO UHQGLPLHQWR GH ORV
SURFHVDGRUHV

/D KHUUDPLHQWD TXH VH SUHVHQWD SUHWHQGH
VHU XQ KtEULGR HQWUH OD GRFHQFLD \ OD
LQYHVWLJDFLyQ0HGLDQWH VXGHVDUUROOR \ VX
XWLOL]DFLyQ VH SXHGHQ FRPSUHQGHU PXFKDV
GHODVIXQFLRQDOLGDGHVSUHVHQWHVHQPDWHULD
GH DUTXLWHFWXUD GH FRPSXWDGRUHV$GHPiV
OD KHUUDPLHQWD GH VLPXODFLyQ QRV SUHVHQWD
XQFURQRJUDPDFRQODVGLVWLQWDVHWDSDVSRU
ODVTXHYDQSDVDQGRODVLQVWUXFFLRQHVHQVX
HMHFXFLyQORFXDOQRVSHUPLWHREVHUYDUODV
GHSHQGHQFLDV \ UHODFLRQHV H[LVWHQWHV HQWUH
HOODV8QYDORUDxDGLGRHVODPXHVWUDILQDO
GH ODV HVWDGtVWLFDV LPSRUWDQWHV HQ OD
HMHFXFLyQVHJPHQWDGDFRPRSXHGHQVHUHO
WDQWR SRU FLHQWR GH XVR GH ODV GLVWLQWDV
HWDSDVGHQWURGHODHMHFXFLyQ\HOQ~PHUR
PHGLR GH FLFORV QHFHVDULRV SDUD HMHFXWDU
FDGD XQD GH HVWDV 'H HVWD PDQHUD
SRGHPRV UHDOL]DU REVHUYDFLRQHV VREUH
FyPR FDPELRV HQ OD HVWUXFWXUD GHO
PLFURSURFHVDGRURFDPELRVHQHORUGHQGH
HMHFXFLyQ GH LQVWUXFFLRQHV SXHGHQ DIHFWDU
HQHOUHQGLPLHQWRJOREDO
704 Docencia en Arquitectura y Tecnología de Computadores


 (VTXHPDJHQHUDOGHOVLPXODGRU
(O VLPXODGRU GHO PLFURSURFHVDGRU
SUHVHQWDGRHQHVWHWUDEDMRHVWiEDVDGRHQXQ
VLVWHPD GH HMHFXFLyQ GH HYHQWRV GLVFUHWRV
OODPDGR '(63& HVWD HV XQD
KHUUDPLHQWD GHVDUUROODGD SRU HO 'RFWRU
-HURPH 'DUPRQW GH OD /,026 %ODLVH
3DVFDO 8QLYHUVLW\ &OHUPRQW)HUUDQG ,,
)UDQFH (Q HVWH WHQHPRV XQ PRWRU GH
VLPXODFLyQTXHYDHQFDX]DQGRORVGLVWLQWRV
HYHQWRV TXH VH SURGXFHQ HVTXHPDWL]DGRV
HQWUHFOLHQWHVTXHHMHFXWDQUHFXUVRVDFWLYRV
(VWRV UHFXUVRV DFWLYRV SXHGHQ GLVSRQHU VL
SURFHGH GH UHFXUVRV SDVLYRV SDUD
GHVHPSHxDUVXIXQFLRQDOLGDG

3DUD DFRQGLFLRQDU HVWH VLPXODGRU GH
HYHQWRV GLVFUHWRV D XQ SURFHVDGRU KHPRV
UHDOL]DGRXQVtPLOHQHOTXHORVFOLHQWHVGH
HMHFXFLyQVRQODVGLVWLQWDVLQVWUXFFLRQHVTXH
VH HMHFXWDQ /RV UHFXUVRV DFWLYRV YDQ D
UHSUHVHQWDU ODV HWDSDV VHJPHQWDGDV HQ OD
HMHFXFLyQSDUDOHODGHLQVWUXFFLRQHV(QHVWH
FDVR QR XWLOL]DPRV UHFXUVRV SDVLYRV 3RU
WDQWR YDPRV D WHQHU GLVWLQWDV FODVHV GH
REMHWRV SDUD ODV GLVWLQWDV HWDSDV VHDQ ,)
&2/$,'(;0(:%

(O VLPXODGRU UHFLEH XQ ILFKHUR HQ
HQVDPEODGRU FRQ ODV LQVWUXFFLRQHV D
HMHFXWDU\XQILFKHURGHFRQILJXUDFLyQFRQ
HO Q~PHUR \ ODWHQFLD GH XQLGDGHV
IXQFLRQDOHV\ODSUREDELOLGDGGHHMHFXWDUODV
LQVWUXFFLRQHVGHVDOWR8QDYH]SURFHVDGDOD
LQIRUPDFLyQGHHVWRVILFKHURVFRPLHQ]DOD
HMHFXFLyQ VHJPHQWDGD HVFULELHQGR ORV
GDWRVQHFHVDULRVHQXQFURQRJUDPDTXHVH
YXHOFD SRU SDQWDOOD $O ILQDOL]DU OD
HMHFXFLyQGHODVLQVWUXFFLRQHVVHPXHVWUDQ
ODV HVWDGtVWLFDV FRUUHVSRQGLHQWHV (O
VLPXODGRUHVWiSUHSDUDGRSDUDWUDEDMDUFRQ
WRGR WLSR GH FyGLJR HQVDPEODGRU 1R HVWi
OLPLWDGRDXQWUR]RGHFyGLJRHQSDUWLFXODU


)LJXUD 'LDJUDPDGHFRQWH[WRGHOVLPXODGRU
 8QVLPXODGRUGHSURFHVDGRU
VHJPHQWDGR
(O SULPHU DFHUFDPLHQWR DO TXH GHEHPRV
HQIUHQWDUQRV HV OD GHSHQGHQFLD OyJLFD
H[LVWHQWH HQWUH ORV GDWRV UHODFLRQDGRV GH
FDGDXQDGHODVLQVWUXFFLRQHV2EYLDPHQWH
QR SRGHPRV XWLOL]DU HO FRQWHQLGR GH XQ
UHJLVWUR GHO SURFHVDGRU DQWHV GH TXH RWUD
LQVWUXFFLyQKD\DHVFULWRHOUHVXOWDGRGHXQD
RSHUDFLyQSUHYLDHQHVHPLVPRUHJLVWURHV
OR TXH VH GHQRPLQD FRQIOLFWRV GH OHFWXUD
GHVSXpVGHXQDHVFULWXUD5$:5HDG$IWHU
:ULWH,JXDOPHQWHVLXQDLQVWUXFFLyQWLHQH
TXHHVFULELUXQGDWRHQXQUHJLVWUR\DVHD
IORWDQWH R HQWHUR GHEH HVSHUDU D TXH
LQVWUXFFLRQHVSUHYLDVUHDOLFHQHVFULWXUDVHQ
HOPLVPRUHJLVWUR:$::ULWH$IWHU:ULWH
(Q FDVR FRQWUDULR HVD HVFULWXUD VH YHUtD
LQXWLOL]DGD SRU SRVWHULRUHV HVFULWXUDV
VLHPSUH \ FXDQGR HVWDV HVFULWXUDV VH
HMHFXWDQSRUSDUWHGHLQVWUXFFLRQHVSUHYLDV
ODV FXDOHV SRU RWURV PRWLYRV KDQ YLVWR
UHWUDVDGDVXHMHFXFLyQ3DUDSUHYHQLUQRVGH
HVWRV \ RWURV FDVRV VLPLODUHV VH KDQ
SURJUDPDGR IXQFLRQHV PLHPEUR HQ &
SDUD PDUFDU \ GHVPDUFDU ORV UHJLVWURV GHO
SURFHVDGRU &RQVLGHUDUHPRV XQ UHJLVWUR
PDUFDGR FXDQGR XQD LQVWUXFFLyQ OR WLHQH
TXH XWLOL]DU FRPR GHVWLQR GH VX RSHUDFLyQ
DQWHV GH TXH QLQJXQD RSHUDFLyQ SRVWHULRU
WUDEDMH FRQ HO 'H HVWD PDQHUD XQD
LQVWUXFFLyQ DO PDUFDU XQ UHJLVWUR OR
LQKDELOLWD SDUD HO XVR GH SRVWHULRUHV
LQVWUXFFLRQHV3RUVXSXHVWRXQDLQVWUXFFLyQ
TXH PDUFD XQ UHJLVWUR HV OD HQFDUJDGD GH
XVI Jornadas de Paralelismo, JP '2005 705
 

GHVPDUFDUOR FXDQGR KD WHUPLQDGR GH
WUDEDMDU FRQ HO 'HVWDFDU DTXt TXH QXHVWUR
VLPXODGRU WUDEDMD FRQ  UHJLVWURV GH WLSR
HQWHUR\RWURVWDQWRVGHWLSRFRPDIORWDQWH

(Q ODV HWDSDV GH HMHFXFLyQ GH ODV
LQVWUXFFLRQHV\DVHDQGHWLSRUHJLVWURRGH
DFFHVR D PHPRULD XWLOL]DPRV ODV
GHQRPLQDGDVXQLGDGHVIXQFLRQDOHV1XHVWUR
SURFHVDGRU HVFDODU SXHGH VHU FRQILJXUDGR
SDUDWHQHUYDULDVXQLGDGHVIXQFLRQDOHVTXH
SHUPLWLHUDQHMHFXWDUGHPDQHUDFRQFXUUHQWH
OD HWDSD GH HMHFXFLyQ GH GRV R PiV
LQVWUXFFLRQHV GHO PLVPR WLSR 3RU WDQWR
WHQHPRV XQLGDGHV IXQFLRQDOHV GH ORV
VLJXLHQWHVWLSRV

• 8)B(;8QLGDGHVSDUDHMHFXFLyQHQWHUDGH
VXPD\UHVWD
• 8)B$'')6XPD\UHVWDHQSXQWRIORWDQWH
• 8)B08/) 0XOWLSOLFDFLyQ HQ SXQWR
IORWDQWH
• 8)B',9)'LYLVLyQHQSXQWRIORWDQWH
• 8)B0(0 8QLGDG SDUD
FDUJDDOPDFHQDPLHQWRHQPHPRULD
• 8)B:% 8QLGDG SDUD HVFULWXUD GH
UHVXOWDGRV


$ FRQWLQXDFLyQ PRVWUDPRV HO HVTXHPD
PRGXODU GHO VLPXODGRU KDVWD HO PRPHQWR
'HEHPRV WHQHU HQ FXHQWD TXH SRGHPRV
DxDGLUIXQFLRQDOLGDGHVDQXHVWURVLPXODGRU
GH PDQHUD TXH YD\D DMXVWiQGRVH FDGD YH]
FRQPiVSUHFLVLyQDODUHDOLGDG


)LJXUD 6LPXODGRU,QLFLDO
(O FyGLJR EDVH HOHJLGR SDUD FRQWUDVWDU ORV
UHVXOWDGRV GHO VLPXODGRU D QLYHO GH
FURQRJUDPDHVHOIUDJPHQWRGHFyGLJRTXH
FRQVWLWX\H HO SDVR IXQGDPHQWDO HQ OD
HOLPLQDFLyQ JDXVVLDQD  >+(1 @ 6H OH
GHQRPLQD '$;3< GHELGR D ODV
RSHUDFLRQHVTXHUHDOL]D

L        
GR^
\>L@ D [>L@\>L@
L
`ZKLOHL

 $ FRQWLQXDFLyQ VH PXHVWUD OD
YHUVLyQ HQ HQVDPEODGRU SDUD '$;3< /D
SVHXGRLQVWUXFFLyQ (1' ILQDOL]D OD
HMHFXFLyQGHOSURJUDPDGHSUXHEDXQDYH]
TXH pVWD KD GHMDGR DWUiV OD IDVH ,' \ ODV
LQVWUXFFLRQHV DQWHULRUHV KDQ FRQFOXLGR VX
HMHFXFLyQ /D SVHXGRLQVWUXFFLyQ 673
EORTXHDODHQWUDGDGHPiVLQVWUXFFLRQHVHQ
OD IDVH ,' \ VH XWLOL]D SDUD HYLWDU OD
GHFRGLILFDFLyQGHLQVWUXFFLRQHVLQH[LVWHQWHV
TXH \D QR IRUPDQ SDUWH GHO SURJUDPD GH
SUXHED

706 Docencia en Arquitectura y Tecnología de Computadores



68%555L 
/'555 
/'555 
/'))5) D
/'))5) [>L@
/'))5) \>L@
08/))))) D [>L@
$''))))) )\>L@
67)5)\>L@ )
$''555L
68%5555 L
%5&5VDOWDVLL
(1'SVLQVWUILQSURJUDPD
673SVLQVWUGHWLHQHIDVH,'
123QRRSHUDFLyQ


5HFDSLWXODQGRHQHVWHSXQWRGHOGHVDUUROOR
WHQHPRV XQ VLPXODGRU GH SURFHVDGRU
VHJPHQWDGR TXH FRQVWD GH YDULDV IDVHV
'HEHPRV WHQHU HQ FXHQWD TXH ItVLFDPHQWH
QR H[LVWH XQD FRUUHVSRQGHQFLD WRWDO HQWUH
ODV IDVHV \ ODV HWDSDV GHO SURFHVDGRU
VHJPHQWDGRSXHVSRUHMHPSORODHWDSD,'
QRHVXQDHWDSDItVLFDHQVL8QDYH]TXHODV
LQVWUXFFLRQHV KDQ VLGR EXVFDGDV \
DOPDFHQDGDV HQ OD FROD PHGLDQWH ORV
UHFXUVRV DFWLYRV FRUUHVSRQGLHQWHV 8Q
DOJRULWPR DO TXH GHQRPLQDPRV ³IDVH GH
HPLVLyQ GH LQVWUXFFLRQHV´ GHFRGLILFD OD
LQVWUXFFLyQTXHVHHQFXHQWUDHQHOIUHQWHGH
ODFROD\ODHQYtDDVXVLJXLHQWHHWDSDHQOD
HMHFXFLyQ 0RVWUDUHPRV DKRUD XQ SULPHU
FURQRJUDPD GH VDOLGD FRQ ODV
IXQFLRQDOLGDGHV LPSOHPHQWDGDV KDVWD
DKRUD



68%555
/'55
/'55
/'))5
/'))5
/'))5
08/))))
$''))))
67)5)
$''555
68%555
%5&5
(1'
673
123


!)'(: 
!)'00:
!)''00:
!)&''00:
!)&&''00: 
!)&&&''00:
!)&&&&'((((((:
!)&&&&&&&&&'(((:
!)&&&&&&&&&&&'00 
!))&&&&&&&&&&'(:
!)&&&&&&&&&&'(:
!))))))&&&&&'
!)))&&&' 
!)&&&'
!)&&&'

7DEOD &URQRJUDPDGH6DOLGD

XVI Jornadas de Paralelismo, JP '2005 707
 

 3UHGLFFLyQGLQiPLFDGHVDOWRV
LPSOHPHQWDFLyQGHXQD%7%
3DUDUHGXFLUODVSHQDOL]DFLRQHVSURYRFDGDV
SRUODVLQVWUXFFLRQHVGHWLSRVDOWREUDQFK
KHPRV LPSOHPHQWDGR XQ EXIIHU GH GHVWLQR
GH VDOWRV WDPELpQ FRQRFLGR FRPR %7%
%UDQFK 7DUJHW %XIIHU (Q HVWD
REVHUYDPRVHQODHWDSD,)VLODLQVWUXFFLyQ
HVGHWLSRVDOWRHQHVHFDVRDVXPLPRVTXH
HOVDOWRVHYDDWRPDUSRUHOSULQFLSLRGH
ORFDOLGDG GH UHIHUHQFLD ORV SURJUDPDV
WLHQGHQ D XWLOL]DU ORV GDWRVH LQVWUXFFLRQHV
TXH KDQ XVDGR UHFLHQWHPHQWH
1RUPDOPHQWHFXDQGRXQVDOWRVHWRPDSRU
SULPHUDYH]QRVHUiOD~QLFD1XHVWUD%7%
JXDUGDLQIRUPDFLyQGHODVLQVWUXFFLRQHVGH
VDOWR\VXVGHVWLQRVFRUUHVSRQGLHQWHVHVWD
LQIRUPDFLyQ VH YD DFWXDOL]DQGR D PHGLGD
TXHVHSURGXFHQORVVDOWRV&XDQGRXQVDOWR
VH WRPD VH HVFULEH OD LQIRUPDFLyQ
FRUUHVSRQGLHQWH HQ HO EXIIHU \ FXDQGR
ILQDOPHQWH XQ VDOWR GHMD GH SURGXFLUVH OD
HQWUDGDHQODPHPRULDGHVWLQRGHVDOWRVVH
ERUUD &RQ HVWR FRQ VXIULPRV
SHQDOL]DFLRQHVVyORFXDQGRHOVDOWRVHWRPD
SRUSULPHUDYH]\FXDQGRGHMDGHWRPDUVH



6H KD LPSOHPHQWDGR HVWD VROXFLyQ SRU VHU
DPSOLDPHQWH H[WHQGLGD HQ ORV GLVHxRV GH
PLFURSURFHVDGRUHV FRPR PHFDQLVPR
KDUGZDUHGHSUHGLFFLyQGLQiPLFDGHVDOWRV
VLQ HPEDUJR QR HV OD ~QLFD 3DUD PiV
LQIRUPDFLyQYpDVH>+(1@
 2EWHQFLyQ\DQiOLVLVGHUHVXOWDGRV
9DPRV D FHQWUDUQRV HQ HVWH HMHPSOR SDUD
REVHUYDU OD VHJXQGDG ILQDOLGDG GH HVWH
DFHUFDPLHQWRHOHVWXGLRGHOLPSDFWRGHODV
WpFQLFDV GH PHMRUD GH OD HMHFXFLyQ HQ ORV
SURFHVDGRUHV 8QD YH] LPSOHPHQWDGD OD
SUHGLFFLyQ PHGLDQWH %7% SRGHPRV
FRQWUDVWDU ORV GLVWLQWRV FURQRJUDPDV \
YDORUHV QXPpULFRV REWHQLGRV 3ULPHUR
PRVWUDUHPRVXQFURQRJUDPDHQHOTXHQRVH
FXHQWD FRQ PHPRULD GH SUHGLFFLyQ
GLQiPLFD GH VDOWRV 8QD YH] KHFKR HVWR
PRVWUDUHPRV HO FRUUHVSRQGLHQWH D XQ
SURFHVDGRU FRQ %7% LPSOHPHQWDGR
*UDFLDV D OD REWHQFLyQ GH YDORUHV
HPStULFRV SRGUHPRV FRQWUDVWDU HO &3, GH
FDGD FRQILJXUDFLyQ \ DQDOL]DU ORV
UHVXOWDGRV

708 Docencia en Arquitectura y Tecnología de Computadores
!)'(:
!)'00:
!)''0:
!)&''00:
!)&&''00:
!)&&&''00:
!)&&&&'((((((:
!)&&&&''''''(((:
!)&&&&&&&&&'''00
!))&&&&&&&&&&'(:
!)&&&&&&&&&&'(:
!))))))&&&&&'
!)))&&&9
!)&&9
!)&9
!)9
!
!)'00:
!)''00:
!)&'((((((:
!)&''''''(((:
!)&&&&&&'''0
!)&&&&&&&&'(:
!)&&&&&&&&'(:
!))))&&&&&'
!
!)))&&&'00:
!)&&&''00:
!)&&&&'((((((:
!)&&&&''''''(((:
!)&&&&&&&&&'''0
!))&&&&&&&&&&'(:
!)&&&&&&&&&&'(:
!))))))&&&&&'
!)'
!)'
!)'
!
!)))&&
!)&
!
)
!)'(:
!)'00:
!)''00:
!))''00:
!))''00:)'00:)'00:
!))''00:)''00:)''00:
!))'((((((:))'((((((:))'((((((:
!)''''''(((:)''''''(((:)''''''(((:
!))))))'''00))))))'''00))))))'''00
!)))'(:)))'(:)))'(:
!)'(:)'(:)'(:
!)')')'
!)'
!)'
!)'

7DEOD &URQRJUDPDGHVDOLGDFRQVLQ%7%


XVI Jornadas de Paralelismo, JP '2005 709
 

(VWDGtVWLFDVSDUDVLPXODFLyQ%7%

QXPHURGHLQVWUXFFLRQHVHMHFXWDGDV
1XPHURWRWDOGHFLFORV
WRWDOGHFLFORVSRULQVWUXFFLyQHV


6,08/$7,2167$7,67,&6 

3$66,9(5(6285&(6

6WDWLVWLFVIRUUHVRXUFH3DVLYH5FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 

$&7,9(5(6285&(6

6WDWLVWLFVIRUUHVRXUFH,)FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 

6WDWLVWLFVIRUUHVRXUFH,'FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 

6WDWLVWLFVIRUUHVRXUFH(;FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 

6WDWLVWLFVIRUUHVRXUFH0(FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 

6WDWLVWLFVIRUUHVRXUFH:%FRQILGHQFHLQWHUYDO

 0HDQUHVSRQVHWLPH 
 0HDQZDLWLQJWLPH 
 0HDQRIFOLHQWVVHUYHG 
 0HDQRIFOLHQWVEHLQJVHUYHG 
 0HDQRIFOLHQWVVWLOOZDLWLQJ 


 /tQHDV)XWXUDV
(O FDUiFWHU ELSRODU GHO SUHVHQWH WUDEDMR VH
H[WLHQGH WDPELpQ SDUD VXV OtQHDV GH
DPSOLDFLyQ(QDPERVFDVRVH[LVWHWUDEDMRD
UHDOL]DU GHVGH HO GHVDUUROOR GH OD
KHUUDPLHQWD \ GHVGH HO XVR GH OD
KHUUDPLHQWD SDUD OD VLPXODFLyQ /D
KHUUDPLHQWDGHVLPXODFLyQGHEHH[WHQGHUVH
SDUD DERUGDU ODV DUTXLWHFWXUDV
VXSHUHVFDODUHV HQ ODV TXH SRGHPRV
DXPHQWDU HO Q~PHUR GH HWDSDV GHO PLVPR
WLSRSDUDHMHFXWDUQRVRORGLVWLQWDVHWDSDVGH
710 Docencia en Arquitectura y Tecnología de Computadores


GLVWLQWDVLQVWUXFFLRQHV(QORVSURFHVDGRUHV
VXSHUHVFDODUHV WHQHPRV OD SRVLELOLGDG GH
HMHFXWDU OD PLVPD HWDSD VREUH GLVWLQWDV
LQVWUXFFLRQHVORFXDOQRVSHUPLWHUHGXFLUHO
&3,LQFOXVRSRUGHEDMRGHODXQLGDG'HVGH
HOSXQWRGHYLVWDGHXVRGHODKHUUDPLHQWD
GHVLPXODFLyQSRGHPRVXVDUODKHUUDPLHQWD
SDUD YHU ORV UHVXOWDGRV GH ORV GLVWLQWRV
PHFDQLVPRV GH DXWRPDWL]DFLyQ SDUD HO
UHRUGHQDPLHQWR GH LQVWUXFFLRQHV SDUD OR
FXDOQRHVQHFHVDULRPRGLILFDUHOVLPXODGRU

(VTXHPDV FRPR HO UHRUGHQDPLHQWR GH
LQVWUXFFLRQHV R GHVHQUROODGR GH EXFOHV
SXHGHQ VHU WDPELpQ HVWXGLDGRV \
FRUURERUDGRV PHGLDQWH HO XVR GH HVWD
KHUUDPLHQWD &XDQWR PiV DPSOLHPRV HO
VLPXODGRU PiV FHUWHUR VHUi PiV DFRUGH D
ODUHDOLGDG\QXHVWURVUHVXOWDGRVVHUiQPiV
ILDEOHV

5HIHUHQFLDV
>%85@ ' %XUJHU 70 $XVWLQ
7KH 6LPSOH6FDODU 7RRO
6HW 9HUVLRQ 
'HSDUWPHQW RI &RPSXWHU
6FLHQFHV 8QLYHUVLW\ RI
:LVFRQVLQ0DGLVRQ
7HFKQLFDO 5HSRUW 
-XQH

>+(1@ -/ +HQQHVV\ '$
3DWWHUVRQ &RPSXWHU
$UFKLWHFWXUH $
4XDQWLWDWLYH $SSURDFK
6HFRQG (GLWLRQ 0RUJDQ
.DXIPDQQ 3XEOLVKHUV
,QF

>6,/@ - 6LOF 7 8QJHUHU %
5RELF $ VXUYH\ RI QHZ
UHVHDUFK GLUHFWLRQV LQ
PLFURSURFHVVRUV
0LFURSURFHVVRU DQG
0LFURV\VWHPV 9RO 

>52'@ -0 5RGUtJXH] &RUUDO
8QD DSRUWDFLyQ DO
HVWXGLR GH HPXODFLyQ GH
%XVHV0HPRULDGH7pVLV
'RFWRUDO 8QLYHUVLGDG GH
6HYLOOD

>6&+@ 6HEDVWLDQ 6FK|QEHUJ
,PSDFW RI 3&,%XV /RDG
RQ $SSOLFDWLRQV LQ D 3&
$UFKLWHFWXUH ,(((
&RPSXWHU6RFLHW\

>67$@ : 6WDOOLQJV
2UJDQL]DFLyQ \
$UTXLWHFWXUD GH
&RPSXWDGRUHV 4XLQWD
(GLFLyQ 3UHQWLFH+DOO
,QF

>7$1@ $6 7DQHQEDXP
  &RPSXWHU 1HWZRUNV
  7KLUG (GLWLRQ 3UHQWLFH
  +DOO ,QF

>7$1@ $6 7DQHQEDXP
6WUXFWXUHG &RPSXWHU
2UJDQL]DWLRQ )RXUWK
(GLWLRQ 3UHQWLFH+DOO
,QF

XVI Jornadas de Paralelismo, JP '2005 711
Simulador de Máquina Sencilla*
Juan A. Ortega, Natalia Ayuso, Luis M. Ramos
Dpto. Informática e Ingenierı́a de Sistemas - Universidad de Zaragoza
Centro Politécnico Superior - 50.018 Zaragoza
juanortega@able.es, nayuso@unizar.es, luisma@unizar.es
Resumen
Máquina Sencilla es una herramienta de apoyo
a la docencia en cursos básicos de arquitectu-
ra de computadores. Está basada en la simu-
lación de un procesador simple que presenta
a los alumnos los bloques funcionales básicos
que comprenden un computador. Para llevar
a cabo esta simulación, se apoya en la ejecu-
ción controlada de programas escritos en un
ensamblador muy básico.
1. Introducción
La máquina sencilla fue creada por Juan J.
Navarro para ser usada en primer curso de la
Facultad de Informática de Barcelona en 1984.
Posteriormente se publicó un libro que recoge
esta arquitectura pedagógica [1]. El simulador
Máquina Sencilla implementa un entorno que
permite tanto la edición y compilación de fuen-
tes en ensamblador como su posterior ejecu-
ción, pudiendo el usuario conocer el estado del
procesador en todo momento. La herramienta
puede simular tres variantes del procesador.
La primera es la versión base, en la cual se
apoyan el resto de versiones. La segunda es
una variación de la primera en la que se han
añadido tres nuevas instrucciones. Por último,
dispone de una versión microprogramable en
la que tanto el comportamiento como el for-
mato de las instrucciones debe ser definido por
el usuario y que añade un modo de direcciona-
miento. Este simulador va dirigido a alumnos
de asignaturas básicas de arquitectura de com-
putadores y de diseño digital.
*
Financiado por el proyecto de innovación docen-
te “Simulador de Procesadores Virtuales para Docen-
cia”, convocatoria 2004. Universidad de Zaragoza.
Figura 1: Montador
La interfaz de usuario está basada en el si-
mulador COVI [2] y ha sido pensada para tres
escenarios distintos: apoyo al profesor en las
clases teóricas, apoyo al alumno en el estudio y
herramienta de prácticas de laboratorio. Para
adaptarse a sus diferentes usos, Máquina Sen-
cilla dispone de diferentes elementos de ayuda
que guı́an al usuario a través del programa.
Máquina Sencilla es de libre distribución y
puede obtenerse a través de la página web del
grupo de Arquitectura de Computadores de la
Universidad de Zaragoza (gaZ) 1
.
Para su funcionamiento requiere 8 Megaby-
tes de espacio en el disco duro y sistema ope-
rativo Windows (98, NT, 2000 o XP).
1
http://webdiis.unizar.es/gaz/docencia/simula.
html
Figura 2: Organización
2. Máquina Sencilla
2.1. Descripción de la herramienta
La herramienta está compuesta por dos módu-
los: el montador (figura 1) y el simulador. El
montador permite la edición de fuentes en en-
samblador, ası́ como su compilación, en un en-
torno amigable con resaltado de sintaxis y de
errores.
El simulador permite ejecutar de forma con-
trolada los programas compilados en el mon-
tador, mostrando al usuario en todo momento
el estado de la máquina. Para ello cuenta con
las siguientes ventanas:
• Organización o unidad de proceso (fi-
gura 2). Muestra la organización de la
Máquina Sencilla, compuesta por los ele-
mentos básicos de un computador: me-
moria RAM unificada, unidad aritmético-
lógica (ALU), contador de programa
(PC), registro de instrucciones (IR), re-
gistros de operandos (A, B), registro de
detección de cero (FZ) y varios compo-
nentes combinacionales.
• Unidad de control. Muestra la unidad de
control de la máquina. Dependiendo de
Figura 3: Memoria
la versión de Máquina Sencilla que este-
mos simulando, podrá ser cableada o mi-
croprogramada. En caso de ser cableada,
permite acceder al diagrama de estados,
mientras que en el caso contrario ofre-
ce al usuario el correspondiente micropro-
grama.
• Memoria (figura 3). Permite observar el
el programa y los datos en todo momen-
to. La instrucción que se está ejecutando
aparece resaltada.
• Ventanas auxiliares. Hay cuatro ventanas
más que muestran el contenido de algunos
registros y señales del procesador.
En cuanto a la ejecución controlada, la
herramienta permite llevarla a cabo de cuatro
modos distintos:
• Ejecución ciclo a ciclo.
• Ejecución instrucción a instrucción.
• Ejecución de un determinado número de
instrucciones dado por el usuario. En este
caso, cada 50 instrucciones se pregunta al
usuario si desea proseguir con la simula-
ción.
• Ejecución hasta breakpoint. El simulador
permite insertar puntos de ruptura en las
instrucciones, a través de la ventana de
memoria. Al igual que en el caso anterior,
se pregunta al usuario cada 50 instruccio-
nes si se desea continuar, para evitar que
un punto de ruptura situado en una ins-
trucción inaccesible, “cuelgue” el progra-
ma.
714 Docencia en Arquitectura y Tecnología de Computadores
Figura 4: Monitorización de señales
Además, para facilitar el seguimiento de la
ejecución por parte del usuario, se realzan los
cables que han estado activos en el último ci-
clo. Asimismo, también es posible monitorizar
su contenido en tres formatos distintos: bina-
rio, hexadecimal y entero (figura 4).
El repertorio de instrucciones es muy bási-
co, dada la simplicidad del procesador. Todas
las instrucciones del repertorio utilizan direc-
cionamiento directo, ya que la máquina carece
de banco de registros.
Como se ha mencionado anteriormente, la
herramienta permite simular tres variantes de
Máquina Sencilla. Cada versión introduce lige-
ras modificaciones en el repertorio de instruc-
ciones. La primera de ellas, que es la base del
resto, cuenta con las siguientes operaciones:
• Instrucciones aritméticas. Cuenta con una
instrucción de suma (ADD) y una ins-
trucción de comparación (CMP), que ac-
tiva el flag FZ dependiendo de si los datos
comparados son iguales o no.
• Instrucciones de transferencia de datos.
Proporciona la instrucción MOV, que per-
mite mover datos de una posición a otra
de memoria.
• Instrucciones de control. Proporciona la
instrucción BEQ, que salta a una posición
de memoria especificada dependiendo del
valor del flag FZ sobre el que opera la
instrucción de comparación.
En cuanto a la unidad de control de esta pri-
mera versión, la herramienta permite al usua-
rio elegir si la desea cableada o microprogra-
mada. A su vez, si se elige cableada, se pueden
escoger dos autómatas diferentes con distinto
nivel de optimización.
La segunda versión extiende el repertorio de
la primera con tres nuevas intrucciones, carac-
terizadas por tener un único operando en me-
moria. Dos de ellas tienen el segundo operan-
do codificado en la propia instrucción, es de-
cir, es un inmediato. Las nuevas instrucciones
son: CLEAR, que pone a cero una posición de
memoria; MOVD, que carga una constante en
una posición de memoria y ACUM, que acu-
mula una constante en una dirección de me-
moria. En este caso la unidad de control sólo
puede ser cableada.
La última versión no posee ningún reper-
torio de instrucciones definido, sino que se
proporcionan cuatro instrucciones genéricas
(inst0, inst1, inst2 e inst3) que el usuario de-
be configurar, microprogramando cada una de
ellas y especificando el número de operandos.
Además, en la ruta de datos se ha añadido un
registro que permite direccionamiento indirec-
to. La unidad de control de esta versión sólo
puede ser, obviamente, microprogramada. Se
trata de una versión abierta pensada para que
el usuario pueda crear su propio repertorio de
instrucciones.
2.2. Aplicación docente
La herramienta Máquina Sencilla sólo supone
conocimientos básicos de diseño digital, es de-
cir, sistemas combinacionales (multiplexores,
sumadores, ALU, . . . ) y secuenciales. Su uso,
por tanto, quedarı́a encuadrado en asignaturas
básicas de arquitectura de computadores y de
diseño digital.
El simulador se ha utilizado con resultados
positivos en las asignaturas “Sistemas Lógi-
cos” y “Fundamentos de Computadores I” (1o
de Ingenierı́a Informática e Ingenierı́a de Tele-
comunicación) del Centro Politécnico Superior
de la Universidad de Zaragoza.
XVI Jornadas de Paralelismo, JP '2005 715
2.2.1. Apoyo en las clases de teorı́a
La herramienta Máquina Sencilla sirve de apo-
yo al profesor en las clases de teorı́a ya que,
tras explicar los fundamentos del procesador,
los alumnos pueden ver un ejemplo real de fun-
cionamiento. El simulador les permite observar
como los datos recorren la unidad de proceso,
apreciando al mismo tiempo el estado y con-
tenido de la memoria, el valor que poseen los
registros, el estado de la unidad de control y
el valor de sus señales.
2.2.2. Prácticas
Hasta ahora, el contacto de los alumnos con
Máquina Sencilla se limitaba a las clases de
teorı́a y no se tenı́a un contacto real con el
procesador. Gracias a la herramienta, ahora
es posible que los alumnos apliquen los cono-
cimientos teóricos adquiridos en las sesiones de
prácticas.
Durante el desarrollo del simulador, se ha
utilizado en una de las prácticas de la asigna-
tura “Fundamentos de Computadores I”, para
evaluar su funcionamiento y corregir errores.
Dicha práctica ha consistido en:
• Analizar un programa con código auto-
modificable para averiguar qué hace, eje-
cutándolo posteriormente en el simulador.
• Calcular el CPI del programa anterior pa-
ra cada unidad de control (cableada nor-
mal, cableada optimizada y microprogra-
mada).
• Escribir el microprograma de una instruc-
ción de acumulación de una constante en
una posición de memoria.
A pesar de que la versión que se utilizó no
era la final y todavı́a tenı́a gran cantidad de
fallos, la valoración media otorgada por los
alumnos ha sido de 7,6. El comentario más
generalizado entre los alumnos fue que la
práctica les resultó muy útil para afianzar sus
conocimientos de Máquina Sencilla, al poder
seguir la ejecución de un programa sobre el
simulador que era, precisamente, el objetivo
que se perseguı́a.
2.2.3. Herramienta de apoyo al estudio
Uno de los problemas de Máquina Sencilla es
la abstracción que debe realizar el alumno para
su estudio y comprensión. Esta herramienta se
presenta como fundamental durante el tiempo
de estudio, ya que los alumnos pueden escri-
bir sus propios programas y microprogramas y
“ver” su ejecución paso a paso.
La herramienta está pensada para que pue-
da ser utilizada sin problemas por el alumno,
debido a su facilidad de instalación y su com-
pleta ayuda, tanto en el montador como en el
simulador. La del montador indica el significa-
do de los errores que se obtienen al compilar, y
otros aspectos de la interfaz de usuario. La del
simulador proporciona un tutorial y presenta
al usuario las funciones de simulación básicas.
Por otra parte, la herramienta cuenta también
con ayuda contextual y con un diálogo de bien-
venida que guı́a al estudiante por las diferentes
tareas que se pueden realizar.
3. Conclusiones
El simulador de Máquina Sencilla facilita a
los alumnos la comprensión de la misma y sirve
de apoyo tanto en la clase de teorı́a, como en
las sesiones de prácticas y en el estudio per-
sonal. Los alumnos valoran positivamente la
herramienta, ası́ como su utilización en prácti-
cas.
Referencias
[1] Eduard Ayguadé i Parra, Juan José Na-
varro Guerrero, Miguel Valero Garcı́a,
La Màquina senzilla : introducció a
l’estructura bàsica d’un computador,
ISBN 84-7653-213-X, Departament
d’Arquitectura de Computadors, UPC,
1992.
[2] J. Alastruey, O. Blasco, A. Hurtado, P.
Ibáñez y V. Viñals, COVI: Computador
Virtual, XIII Jornadas de Paralelismo,
Lérida (España), 9-11 Sept. 2002.
716 Docencia en Arquitectura y Tecnología de Computadores
                            $     (       ,  . 0  1   3   1 
  0  . 7 8 . 7 < > @ B C D        1           0    
         1   0 M      1   0 N     N  1   
Q R S U W X Y Y \ ] W _ ` a c d R e e c e R a \ ] R e g h c Y ] R e i k l m _ e g i ] W e R _ i k W
o c q ` r t u w e y S g ` c i ` S e R t c | W } q S ` R t W e a
 _ g € c e a g ` R ` Q W Y g ` ƒ i _ g i R t c | R ` R Y S _ l R
| R } q S a † W e t
‡ ˆ ‡ ‰ Š
U R e i c Y W _ R
‹ Œ    ‘ ’  ” ” • ”   ‘ ‘  ” – —  • ˜ ” ™ – ‘ › œ  – ž  Œ – ž •   
¡ ¢ £ ¤ ¥ ¢ ¦
§ ¨ © ª « ¬ ­ ¯ ° ¨ ¨ ² ³ ² ¯ ² ¬ ² ¨ ¬ ´ ¬ ¶ ° ³ ² · ¸ º » ¼ ° ½
¨ ² ¶ ´ ¶ ª ¨ ² © ´ ¿ ½ ¯ ° º ½ À ° ½ ´ ° « Á ² § ¨ ° © ¶ « ¿ ½ ´ © ² ¯ ° ¨ ²
§ Â Ã § Â Ä Å · Æ Ç ¼ ¬ ° ´ ³ È ² « ¶ ° ¬ ´ ³ ª ¨ ¶ Ê ½ ° ² ³ ° ½ ¶ °
° ½ ¨ ² ¬ ³ ­ ¯ ² ¨ ´ ¯ ² ¯ ° ¬ È « ° ¬ ° ½ © ´ ² ¨ Ì ¬ ° ³ ´ È « ° ¬ ° ½ Å
© ´ ² ¨ Î § ½ ° ¨ © ² ¬ ­ ¯ ° ¨ ² ³ ­ ¯ ² ¨ ´ ¯ ² ¯ È « ° ¬ ° ½ © ´ ² ¨ ¼
² ¯ ° ³ Ê ¬ ¼ ¨ ² ³ ° ¶ ­ ¯ ­ ¨ ­ À Á ² ¯ ° ¶ « ² Ð ² Ñ ­ Ò ² « Á ² ° ½
Ô
ª ½ © ´ ¿ ½ ¯ ° ¨ È « ­
Ô
° ¬ ­ « Ö ª ° ´ ³ È ² « ¶ ° ° ¨ © ª « ¬ ­
×
³ ° ¶ ­ ¯ ­ ¨ ­ À Á ² ° Ø È ­ ¬ ´ ¶ ´ Ò ² ¼ ¶ « ² Ð ² Ñ ­ © ­ ­ È ° « ² ¶ ´ Ò ­
­ ² È « ° ½ ¯ ´ Ú ² Ñ ° Ð ² ¬ ² ¯ ­ ° ½ È « ­ Ì ° © ¶ ­ ¬ Ü Ì ¼ © ª ² ½ ¯ ­
° ¬ È ­ ¬ ´ Ð ¨ ° ¼ ¯ ° ¨ ° ¬ ¶ ´ ¨ ­ Ì ° ¨ ° © © ´ ¿ ½ ¯ ° ¨ ­ ¬ È « ­ È ´ ­ ¬
° ¬ ¶ ª ¯ ´ ² ½ ¶ ° ¬ Î § ¨ ³ ² ¶ ° « ´ ² ¨ ¯ ° ¨ © ª « ¬ ­ ¼ ¬ ´ ½ ° ³ Ð ² « Å
À ­ ¼ ° ¬ ¬ ´ ° ³ È « ° ° ¨ ³ ´ ¬ ³ ­ ¼ Ì
Ô
ª ° ¯ ´ ¬ ° Ý ² ¯ ­ È ² « ²
Ô
² © ´ ¨ ´ ¶ ² « ° ¨ ¶ « ² Ð ² Ñ ­ ² ª ¶ ¿ ½ ­ ³ ­ ¯ ° ¨ ­ ¬ ° ¬ ¶ ª ¯ ´ ² ½ ¶ ° ¬
¶ ­ ³ ² ½ ¯ ­ © ­ ³ ­ « °
Ô
° « ° ½ © ´ ² ¨ ² ¬ ½ ° © ° ¬ ´ ¯ ² ¯ ° ¬ ¯ ° ¨ ²
³ ­ ¯ ² ¨ ´ ¯ ² ¯ ¬ ° ³ ´ È « ° ¬ ° ½ © ´ ² ¨ Î
§ ¬ ¶ ° ² « ¶ Á © ª ¨ ­ ¯ ° ¬ © « ´ Ð ° ¨ ­ ¬ ­ Ð Ñ ° ¶ ´ Ò ­ ¬ Ì © ­ ½ Å
¶ ° ½ ´ ¯ ­ ¬ ¯ ° ¨ © ª « ¬ ­ ¼ ¨ ² ­ « À ² ½ ´ Ú ² © ´ ¿ ½ Ì À ° ¬ ¶ ´ ¿ ½
° ¨ ° © ¶ « ¿ ½ ´ © ² ¯ ° ¨ ³ ² ¶ ° « ´ ² ¨ ¼ Ì ¨ ² ¬ ¯ ´ ¬ ¶ ´ ½ ¶ ² ¬ ³ ­ ¯ ² ¨ Å
´ ¯ ² ¯ ° ¬ Ì ³ ° ¶ ­ ¯ ­ ¨ ­ À Á ² ¬ Ö ª ° ¨ ­ ¬ ² ª ¶ ­ « ° ¬ à ² ½ ª ¶ ´ Å
¨ ´ Ú ² ¯ ­ È ² « ² ´ ³ È ² « ¶ ´ « ° ¨ © ª « ¬ ­ Î
á â ä
¦ å æ ç è ¤ é é ê ë ¦
§ ½ ° ¨ È ¨ ² ½ ¯ ° ° ¬ ¶ ª ¯ ´ ­ ¬ ¯ ° ¬ ° À ª ½ ¯ ­ © ´ © ¨ ­ ¯ °
º ½ À ° ½ ´ ° « Á ² § ¨ ° © ¶ « ¿ ½ ´ © ² ¯ ° ¨ ² § Â Ã § Â Ä Å · Æ Ç
à ² Ì ¯ ­ ¬ ² ¬ ´ À ½ ² ¶ ª « ² ¬ ¯ ° ¬ ´ ¬ ¶ ° ³ ² ¬ ­ È ° « ² ¶ ´ Ò ­ ¬ ¼
ì
« ´ ¬ ­
×
² « Ö ª ´ ¶ ° © ¶ ª « ² Ì ¬ ´ ¬ ¶ ° ³ ² ¬ ­ È ° « ² ¶ ´ Ò ­ ¬ Ü Ì
í ² Ð ² « ´ ¬ ­
×
¨ ² Ð ­ « ² ¶ ­ « ´ ­ ¯ °
ì
« ´ ¬ ­ Ü ¼ ´ ³ È ² « ¶ ´ ¯ ² ¬
È ­ « ° ¨ î ° È ² « ¶ ² ³ ° ½ ¶ ¯ ï
ì
« Ö ª ´ ¶ ° © ¶ ª « ² ¯ ° Ç ­ ³ Å
È ª ¶ ² ¯ ­ « ¬ Î § ½ ¬ ª Ò ° « ¬ ´ ¿ ½ ² © ¶ ª ² ¨ ¼ ¨ ² È « ´ ³ ° « ² ° ¬
¯ ° ¶ ´ È ­ ¶ ° ¿ « ´ © ­ Ì © ­ ½ ¬ ´ ¬ ¶ ° Ð Ê ¬ ´ © ² ³ ° ½ ¶ ° ° ½ ª ½ ²
´ ½ ¶ « ­ ¯ ª © © ´ ¿ ½ ² ¨ ² ¬ ¨ ¨ ² ³ ² ¯ ² ¬ ² ¨ ¬ ´ ¬ ¶ ° ³ ² · ¸ º »
È ² « ² À ° ¬ ¶ ´ ¿ ½ ¯ °
È « ­ © ° ¬ ­ ¬ ¼ ð © à ° « ­ ¬ ¼ ¬ ° Ý ² ¨ ° ¬ Ì
¬ ­ © ñ ° ¶ ¬ Î í ² ¬ ° À ª ½ ¯ ² ¼ © ­ ³ ­ ¬ ª ½ ­ ³ Ð « ° ´ ½ ¯ ´ © ² ¼
° ¬ ° ¨ ¨ ² Ð ­ « ² ¶ ­ « ´ ­ ¯ ° ¨ ² È « ´ ³ ° « ² Ö ª ° ¼ È ­ « « ² Ú ­ ½ ° ¬
­ « À ² ½ ´ Ú ² ¶ ´ Ò ² ¬ ¯ ° ¨ © ° ½ ¶ « ­ ¼ © ­ ½ ¬ ¶ ² © ­ ³ ­ ª ½ ² ² ¬ ´ À Å
½ ² ¶ ª « ² ´ ½ ¯ ° È ° ½ ¯ ´ ° ½ ¶ ° Î § ½ « ° ² ¨ ´ ¯ ² ¯ ¬ ­ ½ © ­ « « ° Ö Å
ª ´ ¬ ´ ¶ ­ ³ ò ¶ ª ­ Ì ¼ ° ½ ¨ ² È « Ê © ¶ ´ © ² ¬ ° ´ ³ È ² « ¶ ° ½ Ñ ª ½ Å
¶ ² ¬ Î § ½ ¨ ­ Ö ª ° ¬ ´ À ª ° ¼ È ª ° ¬ ¼ à ² « ° ³ ­ ¬ « °
Ô
° « ° ½ © ´ ² ²
¨ ² È ² « ° Ñ ²
ì
« ´ ¬ ­ ó í ² Ð ² « ´ ¬ ­ © ­ ³ ­ ª ½ ò ½ ´ © ­ © ª « ¬ ­
¯ ° ¬ ´ ¬ ¶ ° ³ ² ¬ ­ È ° « ² ¶ ´ Ò ­ ¬ Î
í ² § Â Ã § Â Ä ´ ³ È ² « ¶ ° ò ½ ´ © ² ³ ° ½ ¶ ° ° ¨ ¬ ° À ª ½ ¯ ­
© ´ © ¨ ­ ¯ ° º ½ À ° ½ ´ ° « Á ² § ¨ ° © ¶ « ¿ ½ ´ © ² ¼ ¯ °
Ô
­ « ³ ² Ö ª °
¨ ­ ¬ ° ¬ ¶ ª ¯ ´ ² ½ ¶ ° ¬ ¨ ¨ ° À ² ½ ¯ ° ¯ ´
Ô
° « ° ½ ¶ ° ¬ © ° ½ ¶ « ­ ¬ Ì
¶ ´ ¶ ª ¨ ² © ´ ­ ½ ° ¬ ¼ © ­ ½ È ­ © ­ ¬ © ­ ½ ­ © ´ ³ ´ ° ½ ¶ ­ ¬ ° ½ ³ ² Å
¶ ° « ´ ² ¯ ° ° ¬ ¶ « ª © ¶ ª « ² ¯ ° © ­ ³ È ª ¶ ² ¯ ­ « ° ¬ Ì È « ­ À « ² Å
³ ² © ´ ¿ ½ ° ½ Ç Î ¸ ª ° ¬ ¶ « ² ² ¬ ´ À ½ ² ¶ ª « ² ° ¬ ¨ ² ò ½ ´ © ²
¶ « ­ ½ © ² ¨ ¯ ° ¨ Ê « ° ² ° ½ ¨ ² ¶ ´ ¶ ª ¨ ² © ´ ¿ ½ ¼ Ì ¨ ° ¬ ´ À ª ° ¬ ­ Å
¨ ² ³ ° ½ ¶ ° ª ½ ² ­ È ¶ ² ¶ ´ Ò ² ¯ ° ¬ ´ ¬ ¶ ° ³ ² ¬ ° ³ È ­ ¶ « ² ¯ ­ ¬
´ ³ È ² « ¶ ´ ¯ ² È ­ « ° ¨ î ° È ² « ¶ ² ³ ° ½ ¶ ¯ ï § ¨ ° © ¶ « ô ½ ´ © ² Î
õ
¶ « ² ² ¬ ´ À ½ ² ¶ ª « ² ²
Ô
Á ½ ° ¬ Â ° ¨ ° ³ Ê © ¶ ´ © ² ¼ ´ ³ È ² « ¶ ´ Å
¯ ² È ­ « ° ¨ ¯ ° È ² « ¶ ² ³ ° ½ ¶ ­ © ­ « « ° ¬ È ­ ½ ¯ ´ ° ½ ¶ ° Î
î ° ¬ ¯ ° ° ¨ © ª « ¬ ­ ö ÷ ÷ ø Å ÷ ö ¨ ² § Â Ã § Â Ä à ²
Ò ° ½ ´ ¯ ­ ´ ³ È ¨ ² ½ ¶ ² ½ ¯ ­ È ² ª ¨ ² ¶ ´ ½ ² ³ ° ½ ¶ ° ¨ ² ³ ­ ¯ ² ¨ Å
´ ¯ ² ¯ ¬ ° ³ ´ È « ° ¬ ° ½ © ´ ² ¨ ° ½ ¨ ² ¬ ² ¬ ´ À ½ ² ¶ ª « ² ¬ ¶ ° ¿ « ´ © ² ¬
¯ ° º ½ À ° ½ ´ ° « Á ² § ¨ ° © ¶ « ¿ ½ ´ © ²
×
¨ ² ¬ ² ¬ ´ À ½ ² ¶ ª « ² ¬ ¯ °
¨ ² Ð ­ « ² ¶ ­ « ´ ­ ¬ ­ ½ ¬ ´ ° ³ È « ° È « ° ¬ ° ½ © ´ ² ¨ ° ¬ Ü ¼ ³ ² ½ ¶ ° Å
½ ´ ° ½ ¯ ­ ² ¨ ³ ´ ¬ ³ ­ ¶ ´ ° ³ È ­ ¨ ² ³ ­ ¯ ² ¨ ´ ¯ ² ¯ È « ° ¬ ° ½ Å
© ´ ² ¨ Î § ½ ° ¨ © ª ² ¶ « ´ ³ ° ¬ ¶ « ° ¯ ° È « ´ ³ ² Ò ° « ² ¯ ° ö ÷ ÷ ö
¨ ° ¨ ¨ ° À ¿ ° ¨ ¶ ª « ½ ­ ²
ì
« ´ ¬ ­ Î § ½ ² Ö ª ° ¨ ³ ­ ³ ° ½ Å
¶ ­ ¼ Ì ¬ ´ À ª ´ ° ½ ¯ ­ ¨ ² ¬ ¯ ´ « ° © ¶ « ´ © ° ¬ ¯ ° ¨ º Ç § ¯ ° ¨ ²
· Æ Ç û ø ü ¼ ¬ ° ¶ « ² Ú ¿ ª ½ È « ´ ³ ° « ¯ ´ ¬ ° Ý ­ ¯ ° ¨ ² ² ¬ ´ À Å
            

                $
  %   '   * + ,  +  .   %          .  3     5
    7  %      % :  <       : >  + : ?   %  $
.   %  +    : %   +   +      F     G .   F   $
: ? % : +   J L  % : + :      +   : 3     ,    *  % 
 . 

 N   < .  %  +      + : ? %  . +     5  
,  :    %  + : %    3    .           %  . ?  : $
+   < F  %   ?  : +   5 <   ,  . .  3  %   +  G 
   :    + : ? %  .      : ? %  . +     ,  + : 
.  F .   

    ]

      J
_    :        :    ,          .   % 
    :  <  %  .  G       :  5 .  N   +      F  %  
  +      L e f g %     h i ,          .   J
f     .    %  . : %  %    : F     + :  . +    
.  F     + :  . 5 .      F       .        
%   i     % :         : +  .  %   J
 l   
m n o  p q r m  s t u q p
g       %   +     %  :    %  + + : ?  x y z |
}
~

g z | €  : 3  . F        %   5 +    F : +  $
.  %    G    .    %  . :    F     %  +    %   J
_    G    : 3        .   %  . +     5       .  
 .  * + ,  %  .    :         .    :   :     '
   +   +   F   %   .   +   : %  % <

 + :    %  .    :        F     : 3   J
~   F   + :    .   +   + :  :     G   : $
+     G   .      3 : + :   N   

  + 
.    :        F     : 3    .        $
:  
}
 ,  . . € <  .   F        %    
}
. .  $
  %    .  :      € 5 <   +   F   $
 : ?      :   %  .        +     
%  %     :      %  .  :      J ~   $
F   + :    .     +      F       . : >  
 F . : +  + :      .  : F   +     .     $
  e 5   : . : >  %     F      :  G   : $
+  %  . .    %    .  :     
}
    : ? % 
F   +     5     : ? %  * + ,     5 +    : $
+  + : ? :     +  F : F   <   ˆ  .   5 <
+    + :  + : ?  ‰     +    + Š    € J
        .  F   % : >     +  : 3  5  .
   G      N  : F  5 .  G   N   %  G : G $
. :     * +  < .  F       + : ? %  :

  $
  + : ?   .  + :   %  +  .       : + 
%  .    :       J
L . +           : >    ? %  .   +  .    :   $
:      G    : 3   '
 " % ' ) ' , " - 0 2 4 , 7 ' 0 9
‹   +  : G :  .   G .  $
N   

 + : 
 .   %     %   %   5 %  $
 +  : G :   . + : + .  %     +  + : ? %  :     + $
+ :    5   +  : G : 

        %  + ? % :   
.         N  :  5 %   +  : G :  .     +  :  $
   G   : +   %      %  :   . : %  5 < %   +  : G : 
.     +  :     <   +      %  .    N  : $
  +     F     .       :    %  :      F $
+ :    J L  +  : G :  < %  F     F  N   ˆ   F   $
       e J
~         3  .       +   + :  :     F   $
3 :   .       % :     %  G     . : >   
+     :    :  J L .  ? %  .  : + .  <  %  +  $
    + : ? <  

   + :   F    .   N    +  $
 :     F     % : + ,   +  +  F    J
; =
2 , % - A - ' 7 A 0 9
L ‰ F . : + :    .    ‰ F  +    : 3   <
+   + :  :     :   :  : 3     G   .  N     3 
 F   %    .    ? %  .    :   :     5   F  $
+ :  .        .  + : ?  .   +  +  F    G D  : $
+   %  +  +     + :  J
g     . : >    % :     +     :    :  < 
%  G    J
 " % , 2 - 0 E F 0 ' % 0 9
L       .  

 + :   
%    :       F     : 3  5 %   +  : G :  .   +  $
+  F    G D  : +   %  +  +     + : 
}
    %   5
G .  N    5  :   F  +   F    : %  5   + € 5 % :  $
 :   :      .  

 + :    %  . : G    7  <
.   . .    %    .  :      5 < %   +  : G :  .  
  +  :     %   +  : 3  + : ? %  .   . .    %  
 .  :      J
; H
' " - I 4 2 4 , - , M , % ) A " M 0 O 0 Q ,
H H S
9
x  : . : >    %  +   %      .   +    %  
G   : +   %  . :    F     %  +    %   F   
    : ? %  F   +     5 * + ,     5   % :   + $
+ :    < F : F   J
L     ? %  .       G    7          
 . .  G       :  J
T , 0 - ' V " M , 2 4 % , 0 0 9
L ‰ F . : +   .       : $
+  %  .   . .    %    .  :      F        : ?
%  F   +     5   .  + :    .   +  .    F $
      + : ? :     %  .  :      5   : . : >  
% : + ,   . .    %   F    +      :       N  7  
%  F   +     +  +        <   +   + :  .   J
T , 0 - ' V " M , Y % Q , 4 0 9
L ‰ F . : +   .       : + 
%  .   . .    %    .  :      F        : ? % 
718 Docencia en Arquitectura y Tecnología de Computadores
   


      
     
    
 "      $ 
 &  (     "   (     
      -     (  
2
  3    ( (  -    6 (
8 9         (   
  
(   ( (  -          
 
 (       2
       3           (      - 

  6 (   
    (       B $        C 9   "         9   2
  (
 
I
  
   (           
    9     2
8 9  M     (     
   
    
 "  
  2

 
  9        
- 9     
 
      
"   6 9 P    (    C   -     
  
 "     

    
       B
  

 
R &  (     (    - T        (  
( (  -      (      -      (  C     3 
    M  (      (   
   (   
 (       2
       3           (      -         C 9   "
        9     (
 
I
  
   (          
 &  (     "         
      -     ( 
        
        M  (   " ( (  -     6 (
2
8 9        
    9     8 9  M     (     
  

   M  (  `    3        
   b   

 B
     
  
 9     (   8 9  -  6 T   
 
9   (            
 e f g 
  9        9   2
(  `   
(   ( (  -      (      -      ( 
C     3    
 k    B R      - 3  9 (


           

I
9    `        (   3   
B
l     ( 9 "          ( -          -  (     (
 6    
   
"   
     T       B

     

  ! #  
 
(     P      
 
- 2
 (  
 8 9     ( 9 "    
  
     
 
  M  (   "       9  ( -      
 k    B n   (  `  
       C         ( (         M
    (    2
 
      '  -  
      C   -    
- 9 2
     
     ( C
   -
       
  

 -  (  -       3    f B       M

(
)  +    /   ) 2     
  (  `    3    T    2
    9     (      3  8 9     ( 9 "   
  
 
   
    M  (   " 
 k    B
R    - 3  9 (
     (  `     ( (  6
  
 
B
R (  
"   
8 9         

    
(

 

I
 
     (   r (   -       
     9 
 (            
     9  P 9  C
        
 9  8 9  (
    9         9      

  
9 
 
 
B
4
)  5  6  /  5 9 :   /  5  5

  ; ) 2 <  

  (  `   9     6  P
  6 r  8 9    6  6 (  2

C  T      8 9  

6   9    -  
I
b  
(     C    9    "  & 
   (
 r 6 (    -    
  t u -    B
>  #

   #   
  (  `   9     (
    3    b   2
  
 (  9  
"
I

 - 9 (   
  ( 9  
   
2
6   (
8 9             



  -    2

   
    -    
 "   6  (       $ B
A v C
D w x w D { | } F G ~ }  | x I F
J
} € } { ~ L F N
F G D x w F w x ‚ 
„ 
I

 -    -  (       "      9             
           (    9       8 9     ( 9 "  
   (  

             3  … P †   (    (
         `  P 
  (    9           
 (  
I
      C 9       ˆ
Q
B l   9    3     (   -  B f

  -    
    2
 
 
6 P    
 "  &           
6   (
8 9 
            

 C    `  
       
 $ B
Q Q
B

      3     
I

 -    3           (  
 
I
      
I
9         
  6 (   B
Q Q Q
B g 
    
 
-       3  "        3    ( 
 
I

 -    3      6    B
Q T
B
Š
 (      3  "     
I
         9  
 
 2
  & 
 " 
 
(      3    (
       
B
T
B V  (      3    (        `  P 

(    (      3 

  9  
I
      (    "   (       
8 9 
  6     (  `      
C       -      (
(   C

  (   
   (  
I
         
   $ B
T Q
B R   ( 9    3      ' -    B
T Q Q
B

      9 (    3  B e
-    
          (

8 9             
B
W v C
D Œ F € } ~ x F D Y D F  F w € x ] x | F | }  | } D
w Ž ~  {
  C     3    (  9  
     (  `  -        ( 
 (   
I

 -   ` ` a b c  8 9 
 C    `  -
 
    2
 
     - T      B        3    

      
 2
9 -       3      
C      ( 
-
(      
(     C    9     (   (      

 ( 

I
 d     

  &  3    -
   (   - T 8 9        9 &   ( (  6 2

  
 
B        
              
    
 2
   
     9 
  (
 - 3  9 (
   (      C 2
   9   B
XVI Jornadas de Paralelismo, JP '2005 719

    
               
  
!  

$     

  )   !  , $    - . 0
! 
1
  
 3 $ $   ) 5 - 
$
 3 $ $  
 $
      - 
      
1
   $  

  $ 
-    $ , ?   - 
$  A

  

B  C     
   
   C          0

  $  
      $    A H     
1
     
5    -   $   $  $  A
L
3 M A
             
 0  C
      C ?  0
 3     - 
. R
  $     $    )
  
   0
   -   3    
     )     $ 

     0
 3
      ) !  . $      $  $  
$ 
    
  ) $ 
    
  )  
1
    0

 5 C C   ! 
1
. A
L
) M A
!       %   
Z           
   -  ^  
       $     3   R ^     a 
  -    0
$ $    ^   a      $ $  A
L
) 3 M A
(
) 
-
.
   % 1  1  
c ?  

    
    - 
   ,       C      
L
-     
   M A
L
) 3 M A
2
  4
.

  
H   C     $  - 

  $    

 
 -    -    $ $   A h !      $  -   C 0
      k 6 6 7 8 :      ,   $     
C   ^   < = = ? A B k : B E ^   -     
  !   
   
$  )  
C       -      $       0
  $     )
    !    )
        5  3  0
     a

1
  A c   
  $     -   C 0
    )   ^      ,         $ $    
$ - 
  $     $          ) ^     0
    < = = : = = k : B E n F o ^   ) $   q  $   
      ) 3    ,       
  $   -  
1
 0
          $       ! t  3       !  $ 
  -   - 3      A H
       3   0

  A
L
3 ) 3 M A
2
  I  J     -  L J   J   
- 

  $    

 
 -    $     $     -   5 
  $  -  q
0

 A c  -   5 
     C  !     5 $     0
      $  -  q

 A
L
3 ) 3 ) 3 M A
(
% J   N   O -  %    4
.
 
R

c 
 !    C  ! 0
    5  -   3  $     $    A Z     
   C    $
)     
 !    C  !     
$  C      ,      $   5 -       
 0
,  a   S -      A h    ,
  $    
 
 !    -   3   -         !  a    
y z A Z   $     t     $      $      
  $ 
$ 
  -   C    $
    ^   -   0
$          5 $         !   $  -   0
   $ $ -    ?       A h    
 !    
!      
    C   ^   < = = ? A B k : B E A
L
3 M A
U   V   -   %      X
 3    $      C ?  0
 3   $     $    -  ^         $   
 
-     5   $ 
    $    ^   a
-    $ $  A
L
3 M A
Y
 
-        J  J  [ % 
.

[  
.
 
c    0
$      -            
  5   
   
  $      -  $  $  $

  5 
R   $     $         ,  
     
  
   
       $     -   
 - 0
       -     $  $  $

  A
h 
 3 $ $   $  $  C   )     $  )
   0
     )  ?   -    $   C       ) -   C     5
 
-   
          
       C  !   0
   -      -  
 R

  $    ! 0
    A    C ?   3   
1

     -    $ , ? 
5        
 3 $ $   $      $  A H  
  0
  -   $ )       
 !         $    $  C 
$          ^   a -    $ $  A c  -   5 
  $ 
-  q

    C  !     ) -              3 
-   C     $ $  ^        ,
      

$   -  
1
    ) 5   3     q    -  
   ^    
      $  A h $ R
   $ -  
-  )    !    

   )   
  
$ 
  
      -   3  
$  -   !  
  A
] € _
 ‚ a b ƒ ‚ a ‚ … † e ‡ … ‰  ‚  b  f g a † ‚ …
… Š † … i a Š j a k a l ‹ … Š ‚ ƒ j a
n
…
Π -   C  
     -  $        
    $    ! . $      Ž  , o -    $ , ?  ^    
3    ,  n p o
        $ 
$  ^ 

0
 3 $ $   3    ,        $    -    0
 3  $     
$   $   
1
   $   -   0
$  r ) $   $  3    ,  $
a 
 3 $ $  
L
 

 o       o      C       M ) 5
  ^ 

  3    , 
L
 $ 3 $        o    ^  -  )

    -  
1
    o $ 
1
         M A
s t u t x y z | } y ~  } y } €  z  ‚ ƒ  €  „ …  y ~ t ‡ ~
‚ | ƒ ˆ y Š | ~  | € ‚ y ƒ y  ~ €   ‘  z   „ ˆ | }  ~
… ‘ ƒ € |
c   
  $     $  $ $    -     
 ) -  
        , )   5   . $   
 3 $ $    
720 Docencia en Arquitectura y Tecnología de Computadores
    
 

      
   
      
"  
  '    *   "     - 
     /             

 "   '  3      ' 

      3       ' 

 8
 
9
'           
     
      '   
8
      > @ A  D
    F   '   
 
       /      
    *       "         
 

   '   8

    '  '   L     
"     * 
   
  
     O      
            
   Q
   


      '     -
   @
S     -  ' 
  '               
    '   
      "     - 
        
    
       -  
     '    

    -     
 
         
    
@ Z   \ ]     '   
8
     "        -
          *   /     

      
   3  F  
  
9
 O F    
   
  >   

  -    
  -   

  
'        @
g
   O          
    
  * 
      3 *  
          3 '        '  

                   
   @ S        
       
   '      
   

      m   
 
          @
g
'                 
 O 

   
   

     '            
  
    '   
           * 
 

9
     
 

q r  > @
Z    "           
  '       -     
 
 
'           '  *     "   \  3 "    /  8
  
          '   
      "           8

    -      3     ]
    

   3    
8
 
  D
    
  
    '    
  *   '  
    /     
  -   @ v   '         '  * 8
          /     "   / 
     F  -  
  

   D            
         *     
  

   
 
 x  y "     *           ' 

  
    
  
 
  /                  8
  @ S
    '   

             
  
   3 

                       /     \      

  \ 
9
  "         D  
    L         '  * 8
         @ >  
      
      "     *    8
     
 
9
' @  L    '  *      O    Q    "    
  '        /  >  
               3
  Q         "   \   
   3   '      
  
       
             ' 
  
      '  
8
 Q     
'                3          
"   "     \     
   @ S
  
  /      
/       '   

             / 
     3  
 /      '  
 Q     
@
g
 Q
              8
  
    *  
  -    '   

      
      
   '          *  L                    8
           3   /       
3  
     
    
    @ A         

   '   

    
 ' 
 D 
'     
 "              @
    ! # % ' ) # + - ) # ) 0 2 4 5 4 6 7 - # +  8 + 9 4 2 6 # 9 - = # 5
% 4 9 ' ) ' + ? @ - 7 # 5
S
           '   
            '   

 8
      '    
  *   '  "          /      
'    
'              
   
         8

    
            
     @ S       

         
   '           -   
  }
~
 /  3
  F  -  B  D \       
              

     -
    @    
    - 
   3  '  /   \     
'    ' 
   @
S
           '   
      F r         8
'      *  L  
      3   F r     
   
  *  L     
   @         '              8
   ' 
  '    
  '      F '      
   
8
 
   
9

         > 3        
   L   '    3
'  *      '  '       ' 

  
9
  3    / 
/ >         

         *               8

  '      
   3        
  
     
  
  m 
  F '      /        
  @ A    Q 8
      ' 
  '     "           
          
'  *        
   
 '   "            

   ' 

       /      
    /        

9
/ > @
v     
             /             
*    ' 
  '    
  
  '        3    8
' 
  
   
 
   
9
   >  3          
 
'  *      '  '               
  
9
 /  / > 

 
    
    
        
   ' 
   8
L      /  
      '               
   
   ' 
   L     '     /  x B y @ S
         
"   \   

    * O      
    "           8

       '               
 
    ' 
    
 
9
  > @
S
  *           \   \       ' 
   

       *  
          3 '            
       
   '      I

        
      8
*  L  
             *  L     
    
         
   @ S
           '   
     
 /       
           
           
8
  -    "   '    
       
     
    
          ' 

   3   / 
     
      8
-    
     @ S    *                

  *              @
S
           '   
      /  \  3
 * 
 
  @
XVI Jornadas de Paralelismo, JP '2005 721
                       ! #    &
 #       , #   #  . 
                              #
     '                            
          ' 0                     4 # 6   
   ' 0    #   9            6     =  >   ?
           6      0 A
B
'    C   6   ?
9         6  =  '    >      H  = ' I    ' ?
6       
L
' I       6    # ' I     '         ?
  '  P #    Q  >            ' 0    
R
  ' 
     
L
    '       6    Q   P # T     C  
    ' 0         6        0   Q    6   Q   ?
'       9       A W    6   4      6  I       #
        6       H         9    6   9     H  ?
'       6   4     # 6    
R
  '  '  4 9    
4        A
\                     H       6     =  > 
Q       6   4      a 1 b A e              
                =    0     6   4     #  
 C   6    0  4           A h       =    0   
6   4      Q         #   '  4    '     9   ?
 #          ' 6        C           4    
    
L
6        # j  T     #        4    k    #  
                   \ l m n P A h         0 
    k          '    
R
       C      '   ?
'                >      6       0  C   H   
     =   # 6        
R
 '       =           ?
C                 5    H    A
h       =    0         6   6   4     
R
 ?
         ' 6       0             # C       
  '    H    0             H     6   Q   '  
       # 6     '     #          0  A
B
 6    ?
  6     6   4       6          # 6          ?
                  ' 6        C       I
C        =   # 6          4     6  
R
    #
6     6    H  Q       4     Q        C  
        #         
R
  '       u      =  
4    6     A W              #            ?
    6   4                       H     6   
 ' 6   =  6          9   Q   4    '        
 ' 6   '       0  6  I          
R
          ?
'           '  A
W    '      6   6   4          Q      
  '              
R
  '  # 6      9       ?
6       '       Q       ' I  4      Q  >  
   ' I  6  
R
    A W         6     =  > 
    '          6      0 6             
                 6   4        C  
R
  ?
        '    9    =      6   H   
L
 P #     ?
R
  '    0    Q    
L
  P 4 6      
L
   P >      
  '  '              #    6       0         u ?
     =  
L
 H P # 4  
R
       '        6   6  
6   4        H   H       0 
L
H P A
W    '      6   6   4      #       #   Q ?
        4    Q  >     0   '           # 
R
  '      9    #              6   4     # 4
  6  
R
    T      
R
               4  ?
  '  =             H  A W          '       
          
L
6         6      0             P #
6                  6      '         Q   C  
  '           v    7 Q               A
W      '      #   '  4   v        ?
        ' 6        6  
R
    4      '  ?
 T  6   H   T        Q  >  # 6       9    
L
 
w 8 : P           
R
v                I '    4
j >            A x         #   '      6    ?
         v  ' I        A
; y =
z { | } { z  €
W         v       T  6                
   '           '  \ l m n     9        
 m  9      v  W      0        W ‚ e W ‚ ƒ #  
  C       j      Q >    H   # '              
4 '          ' 6       0  A
e                    6   '     #   '    ?
  6            6  
R
   Q        '  6      ?
    6   C     ' I    I '    4 6   '     
  9   '           Q  >  4    6     =  >   
         A h  '      6            '  4
>
 u  Q            '       9 v           ?
=  5  6     =  > 
L
     '      u 6      H   
 6     =  >     6      H  P # C   6       6 ?
             6          6  
R
    A
h  '      6   6   4                  ?
  H  C  
R
          ' 6       0             #
        ' v      Q  >  4    6     =  >   
6  
R
    A x    9   6   6  C      #   '    ?
  6          4   '      6   6   4     
     ' 6     Q    4   6    Q         9      
                  4               A e   
      0  '  4           6          #    6   4   ?
   6               T                 A
e          0  '  4           6   6   4      #  
                6      6  4         '  ?
      #   '            '  6          A
W   j     H  #          0          
'       6              0  6       
722 Docencia en Arquitectura y Tecnología de Computadores
   
                         "

%   %             /      
   3  5
     
   8       9   /     
   ;  8

 ;      8
    
>      
  /  
   
/    
 C D   E
F   
H
                  /      8     
  
  J   /       / 
    9  
/      5


N
      
/    
  / 
    9  
   
  5
                    8
 /  
    5
 V    9        C   W     /        

  5
  
                      / Y         5
  V   
     C       8
 /     [   
 
]  ^ "          

       C         5
  V   
 / Y     ] a b ^ " >     
  
C      
   8             8
 /         /  
       V   E
f g g i g j l m  o
] a ^          p 
V  3  " 

     
      
      C                 
 " s        
 p        
 v      9 
N
s p v 5 x F p W "
     y b b a "   %    {      E    E    E   E
] y ^ v    

     %  " F   |  J

"    D     5
    
~
       /       9         "
F   /  V    y b b y E
] ^ F
  
H
  /     
 C     9         "   
 
"   %    {   /  
 E   C
] % ^ €    /      
        | 
    "  
%    {      E 8 
 C   8   C   E  
]  ^

  
~
 C 
 9    " F   |  J

"  ' ) )
) ) 
[
. / { €    3     / 9 
 [    
   

  C   /               V      8
 /   "

     J     9         
 C        9 
    / Y     
     C      / Y 
H
  5
        "            9  E
] 0 ^ F   |  J

"  s  V      
       { 3  4
H
 /
      >  4
H
 / 
„  
  "            5
       
       
      8   

v v v † " a a  /    y b b % E
] 6 ^ F     † 
  C "  ‡ %      %   C    
H

  {
~
       
C       /    V    
H
  /      "
~
 ˆ   F  8
  %   C p  " s   " a 7 7 6 E
] 9 ^   %     € < "   %    
>
‡ † /   % @
~
E "

~
   V         C { p              %  p 
5

 C  p
      /  " v    "

        " s     5
      |   ˆ p  /    " a 7 7 a E
] 7 ^  F       |           C  "       
†       5       F       |         5
  C
H
 


   F  C % †  %  
‡    %    E
|   ˆ s       
H
  v        " a 9 p  / /   5
  
|  
 V   " Š  V    " p 

H
     7 % 7 % 7 E
] a b ^ €  V 
~

   9  " F   |  J

"  3  I       5
/   {      C           V   
 / Y    
   8                       8
 5
/    "            9  E
XVI Jornadas de Paralelismo, JP '2005 723
Segmentación de Cauce del Computador Didáctico Elemental
CODE-2
Juan I. López; Javier Díaz; Francisco Pelayo; Alberto Prieto; Julio Ortega
Dept. de Arquitectura y Tecnología de Computadores
ETS Ingeniería Informática, Univ. de Granada
18071 Granada
entradajuan@yahoo.es, jdiaz@atc.ugr.es fpelayo@ugr.es, aprieto@ugr.es, julio@atc.ugr.es
Resumen
En el contexto de los proyectos orientados a la
enseñanza de arquitectura de computadores, en
este trabajo se presenta un diseño segmentado de
CODE-2, un computador didáctico elemental.
La implementación de CODE-2 basada en
circuitos reconfigurables (FPGA) posibilita el
diseño y comparación de prestaciones de
distintas versiones del procesador. Partiendo de
una versión secuencial no segmentada del
procesador en lenguaje VHDL, el nuevo diseño
segmentado es sustituido en el computador y se
realiza un estudio comparativo de prestaciones
para un conjunto básico de programas de
prueba. Reconfigurando la FPGA que incluye el
procesador, los estudiantes pueden fácilmente
apreciar la considerable ganancia de
prestaciones que supone la arquitectura
segmentada, a la vez que relacionan esta mejora
con los recursos inferidos por el código VHDL
que la define.
1. INTRODUCCIÓN.
CODE-2 es un computador didáctico
elemental empleado en la docencia de
asignaturas de introducción a la informática [1],
especialmente orientado a fundamentos de
arquitectura de computadores [2]. Además de la
disponibilidad de un simulador y de un
ensamblador cruzado [3], el año 2002
desarrollamos un prototipo hardware de CODE-
2. En el presente curso académico se ha
terminado de depurar ese prototipo inicial y se
ha construido una primera serie de 15 unidades,
para formar parte del material didáctico de los
laboratorios de la ETS de Ingeniería Informática
de Granada. El procesador de CODE-2, junto
con los módulos de control de memoria y de
interfaz de entrada/salida, y un módulo de
comunicaciones con un computador personal,
fueron diseñados en VHDL y embebidos en el
dispositivo reconfigurable Flex 10K70 de la
tarjeta UP2 de ALTERA.
Siguiendo las directrices de repertorio de
instrucciones y arquitectura concreta definidos
en [1], la primera versión del CODE-2 fue
diseñada con un procesador secuencial no
segmentado. El presente trabajo describe una
versión alternativa del procesador que incorpora
paralelismo entre instrucciones (ILP), ya que la
ejecución de las instrucciones se realiza de
forma segmentada. Pretendemos con ello que los
alumnos contrasten la mejora de prestaciones
inherentes a la segmentación de cauce, técnica
utilizada por la mayoría de los procesadores y
microcontroladores comerciales
2. EL COMPUTADOR CODE2
CODE-2 es un computador básico que ha sido
construido a partir de dos placas (ver Figura 1):
una de ellas es la tarjeta UP2 de programa
universitario de ALTERA [4], ampliada con un
conjunto de conectores para cable plano, y en
cuyo dispositivo Flex10K70 (FPGA con una
complejidad equivalente de 70.000 puertas
lógicas) se integra la mayor parte del
computador especificado en VHDL. La otra es
una tarjeta de interfaz específica, cuyo diseño
fue descrito en [5], que incluye la memoria
RAM de CODE-2, los elementos de interfaz de
usuario (teclado, visualizadores de 7 segmentos,
pulsadores e interruptores), y un conector de
puerto paralelo para la descarga de programas
máquina compilados y depurados en un
computador convencional. CODE-2 funciona
respondiendo a los eventos provocados por el
usuario al accionar los pulsadores de la placa
interfaz. El prototipo incorpora un programa
monitor o sistema operativo básico, con
funciones elementales como: ver el contenido de
una dirección de memoria, almacenar un dato,
visualizar el contenido del banco de registros o
ejecutar un programa a partir de una
determinada dirección, bien en ejecución paso-a
-paso o bien de forma continuada. El sistema
también ofrece diferentes formas de introducir
información, o bien usando el teclado de la
tarjeta de interfaz, o bien a través del puerto
paralelo, transmitiendo desde un ordenador el
programa que se quiere ejecutar. La FPGA
puede reconfigurarse con distintas versiones del
procesador o bien volcando el archivo de
configuración desde el ordenador, o bien desde
una memoria PROM serie ubicada en la propia
placa de ALTERA. El núcleo del programa
monitor de CODE-2 se graba en uno de los
módulos de memoria SRAM (configurado como
ROM) disponibles en la FPGA, mientras que el
resto de la memoria se implementa en chips
SRAM externos.
2.1. El procesador de CODE-2
El repertorio de instrucciones del procesador es
el definido para CODE-2 en [1], y resumido en
la Tabla 1. La nueva versión del procesador
dispone de exactamente las mismas señales de
entrada y de salida que su predecesor no
segmentado. Se trata de un procesador que es
capaz de ejecutar 16 instrucciones diferentes y
operar con datos de 16 bits. Igual que su versión
previa las instrucciones son codificadas en
palabras de 16 bits. La única diferencia con
respecto a la versión no segmentada radica pues
en la forma de ejecutar las instrucciones
empleando un cauce segmentado.
En la Figura 2 se muestra la organización
RT del procesador utilizada como referencia
para la implementación no segmentada [1]. La
ejecución de instrucciones ocupa en este caso un
número variable de ciclos de reloj (entre 6 y 9)
y, con ligeras diferencias, se corresponde con la
descripción estructurada en módulos VHDL de
la primera versión del prototipo construido [5].
Tabla 1. Repertorio de instrucciones del computador
CODE-2.
Figura 1. Aspecto del prototipo de CODE-2 en
funcionamiento. En la parte inferior se conecta con
cables planos la placa de desarrollo UP2, que alberga la
FPGA de Altera. Los chips de memoria SRAM del
computador están ubicados bajo el teclado.
726 Docencia en Arquitectura y Tecnología de Computadores
3. SEGMENTACIÓN DE CAUCE DEL
PROCESADOR DE CODE-2
Puesto que el principal objetivo de la nueva
versión es ser utilizado como herramienta
didáctica, hemos pretendido que el diseño del
sistema sea lo más regular y estructurado
posible. En el apartado 3.1 hacemos un
planteamiento inicial del cauce, con una
estructura que intenta conservar en la medida de
lo posible las etapas originales de CODE-2. El
apartado 3.2 ilustra los problemas de
dependencias asociadas a la segmentación del
cauce y las soluciones aportadas. Finalmente, en
el apartado 3.3 se describe la microarquitectura
resultante de la segmentación de cauce.
3.1. Estructura del cauce
Partiendo de las etapas del procesador
secuencial, hemos creado un cauce con las
siguientes cinco etapas:
IF: Búsqueda de instrucciones y
actualización del valor almacenado en el
contador de programa (PC). Se accede a
memoria para obtener la instrucción a ejecutar
de la dirección indicada en PC, y se incrementa
el valor de éste.
OF/ID: Lectura de operandos de los
registros mientras se decodifica la instrucción a
realizar. Una vez que se tiene la instrucción en
IR, se decodificará ésta y se identifican tanto
los operandos necesarios (registros del banco de
registros) para operar en la ALU, como el
destino del resultado.
ALU: Ejecución de la operación o cálculo
de una dirección de memoria o de puerto de E/S.
Se realizará una operación con la Unidad
Aritmético Lógica en función de la instrucción
que se está ejecutando, y se actualizan los
registros necesarios si la instrucción va a
acceder a memoria o a un puerto de entrada o
salida. Existen instrucciones que requieren la
actualización del registro PC con el valor
calculado en la etapa anterior, o con el contenido
del registro rD (perteneciente al banco de
registros).
MEM: Acceso a memoria o a un puerto de
entrada o de salida. Al igual que en la etapa IF,
se accede a memoria o bien para escribir algún
valor en una dirección específica, o bien para
leer su contenido.
Figura 2. Arquitectura RT del procesador de CODE-2 no segmentado [1].
XVI Jornadas de Paralelismo, JP '2005 727
OS: Escritura del resultado de la instrucción
(ya sea el resultado de una operación aritmética
o un valor traído de la memoria o de un puerto
de entrada) en un registro. Esta es la etapa en la
que se actualiza el contenido de los diferentes
registros que forman el banco de registros del
procesador.
En la figura 3 se observa cómo se suceden
las etapas del cauce en el tiempo para varias
instrucciones, suponiendo un comportamiento
ideal del cauce. Los problemas surgen cuando
aparecen dependencias [6]. El siguiente apartado
aborda este problema y las soluciones elegidas
en cada caso.
Figura 3.
Figura 4.
Figura 5.
Figura 3. Ejecución segmentada de varias
instrucciones de CODE-2, caso ideal.
3.2. Solución de dependencias
El procesador segmentado es capaz de ejecutar
correctamente las instrucciones de forma
independiente. Sin embargo, existen condiciones
que hacen que el cauce no genere los resultados
esperados a no ser que se detenga el
procesamiento de determinadas instrucciones
hasta que la información sea actualizada
correctamente. Estas dependencias que pueden
interrumpir el flujo continuo de instrucciones a
través del cauce se denominan riesgos. Para
evitar la pérdida de eficiencia de un cauce por la
presencia de riesgos existen diversas estrategias,
tanto desde el punto de vista del software
(reorganización adecuada de las instrucciones en
el código) como del hardware. A continuación
se describe la forma en que los riesgos se han
tenido en cuenta en el diseño del cauce.
3.2.1 Dependencias de datos.
Entre las dependencias de datos WAR (escritura
después de lectura), WAW (escritura después de
escritura) y RAW (lectura después de escritura),
sólo las dependencias de tipo RAW ocasionan
problemas dada la organización de las etapas
que tenemos, en la que la escritura de resultados
se produce en la última etapa y la finalización de
las instrucciones es ordenada (ninguna etapa
consume más de un ciclo)
Como es conocido, las dependencias RAW
aparecen cuando una instrucción necesita el dato
almacenado en un registro que aún no ha sido
actualizado con la información correcta que
debe proporcionar una instrucción previa.
Aparecerán también dependencias de datos
cuando se quiere operar con valores que se han
leído de memoria una o dos instrucciones antes,
pues cuando la instrucción en curso lee del
banco de registros la información no está
actualizada.
Se pueden solucionar estos problemas
reorganizando el código, introduciendo
instrucciones con las que no haya dependencias
entre las instrucciones dependientes, o
instrucciones de no-operación si no se
encuentran estas instrucciones independientes.
En este caso, se puede producir una degradación
importante del rendimiento del cauce.
Desde el punto de vista del diseño hardware
de la microarquitectura, es posible introducir
elementos para detectar las dependencias y
bloquear el cauce hasta que terminen las
instrucciones precedentes y una vez que los
registros están bien actualizados operar con ellos
de una forma segura. Sin embargo actuar de este
modo degradaría el rendimiento del cauce. La
alternativa que se ha elegido consiste en
implementar cortocircuitos o bypass. Mediante
esta técnica se permite que la información que
se necesita pase a la unidad funcional donde se
necesita antes de que el registro correspondiente
se actualice. Esto es posible porque el resultado
generado en la etapa ALU, si la instrucción que
da pie a la dependencia es por ejemplo una suma
(ADDS), se puede pasar directamente
(“cortocircuitar”) del registro de salida de la
ALU a la entrada de la ALU donde se necesita
como operando para la instrucción siguiente.
Así, se dispone de la información correcta sin
tener que esperar a que se guarde en su registro
destino y a realizar una lectura de éste. Por
supuesto la gestión de cada cortocircuito o
camino de bypass, se realiza a través de una
lógica de control especial que detecta la
aparición de la de dependencia.
I1
I2
I3
I4
.....
I3
I4
....
....
.....
I2
I3
I4
.....
.....
I4
.....
.....
.....
.....
OS
I1
MEM
I2
I1
ALU
I3
I2
I1
OF/ID
I4
I3
I2
I1
IF
I1
I2
I3
I4
.....
I3
I4
....
....
.....
I2
I3
I4
.....
.....
I4
.....
.....
.....
.....
OS
I1
MEM
I2
I1
ALU
I3
I2
I1
OF/ID
I4
I3
I2
I1
IF
728 Docencia en Arquitectura y Tecnología de Computadores
3.2.2 Dependencia de salto o riesgo de control.
Este riesgo aparece cuando se ejecuta una
instrucción de salto condicional que, por lo
tanto, puede alterar la secuencia de instrucciones
que el cauce debe procesar. En el procesador
CODE-2 segmentado, dicha alteración ocurre en
la etapa ALU de una instrucción B- o CALL-.
Dado que no se sabe si el salto se realizará o no
hasta ese momento, las dos instrucciones que
suceden al salto se habrán introducido en el
cauce y habrá que decidir si la ejecución de
dichas instrucciones puede continuar o si han de
anularse.
Como en el caso de las dependencias de tipo
RAW, es posible resolver este problema
mediante una organización adecuada del código.
Así, mediante la técnica del salto retardado, tras
una instrucción de salto se situarían
instrucciones que deben ejecutarse tanto si el
salto se produce como si no, y que no afectan a
la condición de salto, o bien instrucciones de no-
operar en el caso de no encontrar instrucciones
con las características indicadas.
No obstante, en el diseño hardware de la
microarquitectura se ha implementado una
política de actuación que emula la utilizada en el
procesador MIPS. Así, se permite que las
instrucciones sigan procesándose hasta el
momento en el que se determina si se produce el
salto. Si el salto se confirma se anula toda
consecuencia que estas instrucciones puedan
acarrear y se continúa ejecutando el programa
por donde indica el nuevo valor del registro PC.
Así, si el salto no se produce, no se pierde
ningún ciclo de reloj. Cuando la instrucción que
se ejecuta es RET, entonces no hay más remedio
que esperar sin realizar ninguna operación hasta
que el registro PC se actualiza con el valor
correcto.
3.2.3 Dependencia estructural.
La dependencia estructural aparece en el
momento en el que algún recurso se quiere usar
por más de una instrucción, produciendo en ese
caso una colisión de ambas instrucciones. En
nuestro caso, la existencia de un único bus para
acceder a memoria y la no disponibilidad de una
memoria separada para datos y para
instrucciones, da lugar a colisiones cuando hay
instrucciones (de carga o almacenamiento de
registros) que necesitan acceder a memoria
(hacen que la etapa MEM necesite utilizar el bus
de memoria).
Puesto que en todas las instrucciones es
necesario acceder a memoria en la etapa IF, si
otra instrucción en su etapa MEM necesita
acceder a memoria, se producirá una colisión.
Esta dependencia se ha solucionado evitando
que se capte una instrucción (deteniendo la etapa
IF) si existe otra que hace uso de la memoria o
de un puerto en la etapa MEM. En las
instrucciones en las que no se accede a memoria
o a puertos en la etapa MEM (instrucciones LLI,
LHI, DAS, SUBS, NAND, SHL, SHR, SHRA,
B- y HALT) no será necesario bloquear
instrucciones posteriores. En las demás
instrucciones (LD, ST, IN, OUT, CALL, RET)
se ha de impedir que una instrucción posterior
ejecute su etapa IF al mismo tiempo que las
primeras ejecutan la etapa MEM. En la Figura 4
se muestra el efecto de esta situación para una
secuencia de instrucciones en la que la
instrucción I1 es, por ejemplo, una instrucción
de carga de memoria. Como se ve, cuando está
en su etapa MEM no se capta una nueva
instrucción (de hecho, la etapa IF se marca con
I1 para indicar la causa). En la Figura 4 también
se aprecia la reducción en el rendimiento del
cauce a que da lugar esta situación.
Figura 4. Esquema de la ejecución de instrucciones
con dependencia estructural debido al acceso a
memoria. Bloqueo de la ejecución de la etapa IF como
solución del conflicto.
Es posible paliar el efecto de esta colisión en
algunos casos, si se realizan algunas
modificaciones en la microarquitectura
segmentada (sin tener que utilizar un bus para
acceso a datos y otro para acceso a
instrucciones). La idea consiste en situar una
I4
I3
I2
I1
OS
....
.
I4
I3
I2
I1
MEM
....
.
....
.
I4
I3
I2
I1
ALU
....
.
....
.
....
.
I4
I3
I2
I1
OF/ID
....
.
....
.
....
.
....
.
I4
I1
I3
I2
I1
IF
I4
I3
I2
I1
OS
....
.
I4
I3
I2
I1
MEM
....
.
....
.
I4
I3
I2
I1
ALU
....
.
....
.
....
.
I4
I3
I2
I1
OF/ID
....
.
....
.
....
.
....
.
I4
I1
I3
I2
I1
IF
XVI Jornadas de Paralelismo, JP '2005 729
cola (con cabida para dos o tres instrucciones)
entre las etapas ID y OF/ID. De esta forma, si
en un ciclo, por alguna circunstancia (no debida
a esta colisión entre IF y MEM) debe paralizarse
el cauce, la etapa IF no tiene que detenerse ya
que la instrucción que capte la introduce en la
cola, después de la instrucción que captó en el
ciclo anterior. Así, cuando la etapa IF tenga que
detenerse por colisión con la etapa MEM, la
etapa OF/ID puede seguir tomando las
instrucciones de las existentes en la cola.
3.3. Microarquitectura resultante del
procesador
En esta sección, se proporciona una somera
descripción de la microarquitectura segmentada
que se ha implementado en la FPGA disponible.
3.3.1 Lógica de datos.
Como consecuencia de las restricciones de
diseño enunciadas en los apartados anteriores se
obtiene la arquitectura mostrada en la figura 5.
Se aprecia una división en zonas (en cada una de
éstas se realizan las operaciones oportunas de
cada etapa en función de la instrucción que se
ejecuta) separadas por los registros de
segmentación, que almacenan e independizan la
información de ámbito de las distintas etapas.
3.3.2 Lógica de control.
La lógica que gobierna el comportamiento
del procesador se ha estructurado en varios
módulos: un módulo central controla el instante
en el que se comienza a ejecutar una instrucción,
así como el modo en el que las instrucciones van
avanzando por el cauce, y si han de dejar de
ejecutarse en un instante determinado. Este
módulo está conectado con otros cinco que
actúan sobre una de las cinco zonas del camino
de datos, decidiendo qué hacer en cada etapa en
función de la instrucción que se está ejecutando.
Figura 5. Esquema RTL de la arquitectura segmentada de CODE-2.
730 Docencia en Arquitectura y Tecnología de Computadores
4. EVALUACIÓN Y CONSUMO DE
RECURSOS
Para evaluar la nueva arquitectura se han
ejecutado los siguientes programas: Ejem1.asm
es un contador que llega hasta el valor
almacenado en una posición de memoria,
Burbuja.asm es el conocido algoritmo de
ordenación, Ejercicio1.asm indica el número de
valores positivos, negativos y equivalentes a
cero que hay en una sección de memoria y por
último, el programa Sumaregistro.asm realiza la
suma de los valores almacenados en las primeras
48 posiciones de memoria.
En la tabla 2 se indican los ciclos de reloj
que tardan los dos procesadores en ejecutar estos
programas. De esta comparación se concluye
que en el peor de los casos la velocidad de
proceso se ha incrementado más de cuatro
veces, llegando superar el 500% de ganancia en
algunos programas.
Nombre
Ciclos NO
Segmentado
Ciclos
Segmentado
Ganancia
de
Velocidad
Ejem1.asm 154 30 5.13
Burbuja.asm 576 126 4.571
Ejercicio1.asm 508 125 4.01
Sumaregistros.asm 3236 681 4.75
Tabla 2. Ciclos de procesamiento y comparación de
prestaciones mediante programas de test.
La tabla 3 muestra el consumo de recursos
utilizados tanto por el procesador aislado como
por el computador completo (procesador +
circuitos controladores de periféricos) en las
versiones secuencial y segmentada. Como
vemos, pese a un incremento del 15% del
consumo de recursos del dispositivo, el aumento
de la frecuencia máxima de funcionamiento, que
se triplica en la versión segmentada, incrementa
notablemente las prestaciones del computador.
La eficiencia de la microarquitectura
depende, lógicamente, del perfil de
dependencias de los códigos. Teniendo en
cuenta la dependencia estructural entre la etapa
IF y la etapa MEM en las instrucciones de
acceso a memoria, la frecuencia de instrucciones
de acceso a memoria afectará bastante a la
eficiencia del cauce diseñado. Para dar una idea
de esta situación se han comparado los ciclos
que tardan distintos programas en el simulador
WINDLX, con una distribución de etapas
similar a la del procesador segmentado de
CODE-2, pero con buses separados para datos e
instrucciones. Aunque WINDLX simula un
procesador de 32 bits con más unidades
funcionales y más potentes, en los códigos para
los que se ha realizado la comparación se
utilizan los mismos recursos de cálculo,
operandos de 16 bits, el mismo número de
instrucciones y del mismo tipo, para que los
perfiles de acceso a memoria y dependencias
coincidan en ambos casos.
Sistema L.E
% del
dispositivo
utilizado
Frecuencia
máxima(MHz)
Procesador
secuencial
1606 34 2.08
Procesador
segmentado
1863 49 6.06
CODE-2
secuencial
2105 56 2.08
CODE-2
segmentado
2625 70 6.06
Tabla 3. Consumo de recursos del dispositivo Flex
10K70RC240-4 y frecuencias máximas de sistema
para las arquitecturas secuencial y segmentada.
La eficiencia del procesador segmentado de
CODE-2 es ligeramente inferior a la del
procesador simulado en WINDLX. Por ejemplo,
en un programa que implementa la
multiplicación del valor almacenado en una
posición de memoria por el numero que guarda
un registro interno, CODE-2 necesita 203 ciclos
para concluir y WINDLX 174, es decir 29 ciclos
más (un 16.6% más).
Si se implementa la mejora descrita al final
de la Sección 3.2.3 se podrían reducir las
diferencias con WINDLX dependiendo del
número de bloqueos del cauce (que permitan
seguir captando instrucciones por parte de IF) a
que den lugar los programas.
5. CONCLUSIONES
En este trabajo se ha presentado una nueva
versión del computador didáctico CODE-2, con
una velocidad de procesamiento superior a la de
su predecesor, gracias a la capacidad de
ejecución segmentada y al aumento de la
frecuencia máxima de funcionamiento del
sistema. Los estudiantes que emplean el
XVI Jornadas de Paralelismo, JP '2005 731
prototipo hardware de CODE-2, pueden volcar
las dos versiones de procesador en el dispositivo
configurable de ALTERA para apreciar
claramente la mejora de prestaciones que supone
la arquitectura segmentada para la ejecución de
los mismos programas. La nueva arquitectura
ilustra factores como el aumento de la
frecuencia de reloj, debido a la replicación de
recursos, y consiguiente disminución del fan-out
y fan-in en los componentes del sistema.
También permite el estudio de las dependencias,
consecuencia de la segmentación de las
instrucciones y muestra diferentes
aproximaciones para su solución. También se
pone claramente de manifiesto el aumento de
recursos necesarios asociado al incremento de
hardware utilizado en la creación del cauce.
Por otra parte, al disponerse de hardware
reconfigurable, los estudiantes pueden introducir
cambios en la microarquitectura segmentada que
aquí se ha descrito y comparar las
consecuencias. Por ejemplo, puesto que el
diseño implementado ocupa el 70% del
dispositivo, se pueden incorporar otros recursos
que mejoren el comportamiento del cauce, como
el descrito al final de la Sección 3.2.3 para
reducir el efecto de las colisiones por el acceso a
memoria. También se pueden implementar
microarquitecturas más sencillas, eliminando los
caminos de bypass, y analizar las prestaciones
que se obtienen utilizando únicamente técnicas
software basadas en la organización del código y
en la introducción de instrucciones de no-operar,
al tiempo que se evalúan los cambios en la
complejidad hardware de la microarquitectura.
Todas estas propiedades de la nueva versión
de CODE-2 extienden su capacidad didáctica,
permitiendo al estudiante profundizar en los
conceptos relacionados con las arquitecturas de
computadores.
En algunas ocasiones se ha establecido una
cierta controversia respecto a la mayor o menor
conveniencia de utilizar herramientas de
simulación o realizar las prácticas aprovechando
sistemas reales. Realmente, ambas alternativas
son complementarias, y por lo tanto deben
utilizarse conjuntamente, bien en una asignatura
o bien a través de las distintas asignaturas de la
carrera. A través de este trabajo planteamos que,
junto a estas dos alternativas, habría que
promover el uso de lenguajes de descripción de
hardware, como VHDL, Verilog, SystemC o
Handel-C, y de sistemas basados en hardware
reconfigurable. Éstos permiten un enfoque
docente de la arquitectura que afianza la
asimilación de conceptos con experiencias de
diseño, incluso de sistemas bastante complejos.
Además, proporcionan una aproximación
razonable a la idea de que la mejor forma de
aprender acerca de los computadores es
construir uno. Por otra parte, dada la creciente
complejidad de los elementos hardware, las
descripciones estructurales basadas en esquemas
de puertas no son muy útiles, siendo los
lenguajes de descripción de hardware los
utilizados para introducir las descripciones de
los sistemas en las herramientas de diseño y co-
diseño hardware/software actuales.
Precisamente esta utilidad práctica
contribuye a motivar al estudiante y constituye
un valor añadido importante de los lenguajes de
descripción de hardware y del hardware
reconfigurable.
Referencias
[1] A.Prieto, A.Lloris, J.C.Torres, Introducción
a la Informática, 3ª Ed., McGraw-Hill, 2002.
[2] A.Prieto, F.J.Pelayo, B. del Pino, J.Ortega,
H.Pomares, F. Gomez-Mula, A.Cañas,
A.Diaz, CODE-2: Un Computador
Didactico Elemental, XIII Jornadas de
Paralelismo, pp. 73-77, Lleida, 9-11
Septiembre 2002.
[3] A.Prieto, F.J.Pelayo, F.Gomez-Mula,
J.Ortega, A.Cañas, A.Martinez,
F.J.Fernandez: Un computador didactico
elemental (CODE-2), VIII Jornadas de
Enseñanza Universitaria de la Informatica
(JENUI'2002), pp. 117-124, Cáceres, 10-12
Julio 2002.
[4] Altera website: www.altera.com.
[5] J.Diaz-Alonso, D.C.Roman, J. Gomez-
Osuna, B. del Pino, F.Gomez-Mula,
A.Prieto, F.J.Pelayo, Implementacion en
hardware reconfigurable del computador
CODE-2, II Jornadas sobre Computacion
Reconfigurable y Aplicaciones
(JCRA'2002), pp. 249-256, Almuñecar
(Granada), 18-20 Septiembre 2002.
[6] Ortega, J.; Anguita, M.; Prieto,
A.:”Arquitectura de Computadores”. Ed.
Thomson-Paraninfo, 2005.
732 Docencia en Arquitectura y Tecnología de Computadores
                       !  $         !   *   +    /  0  0 
 1 2 +    5   5  0    9 ; = $ @  B 
D F H I K M O P O R T V F I T
Y [ ] _ a b [ c e g i k l m _ n p q b [ r n s _ [ l q s u v i l ] y _ q b i k [ s
{ e n | a ~ i  n _ € p e n p q b [  q  [ e p n q
‚ ƒ „ … …  q  [ e p n q
q ‡ _ ˆ b n s p q a y ] | a [ s
Š ‹ Œ 
I F D R
Œ
I F   K ‘ I F ’ R
“ ” r c e ‡ [ e n [ k • q b [ ” [  [ p i l y e n p q p n – e
{ e n | a ~ i  n _ € p e n p q b [  q  [ e p n q
‚ ƒ „ … …  q  [ e p n q
l n p q k q  ˆ _ [  [ p i a y ] | a [ s
˜ ™ š › œ ™ ž
Ÿ   ¡ ¢ £ ¤ ¡ ¥ ¡   ¦ ¡ ¦ ¤ § ¨ § ª « ¥ ¡ ¬ ¡ ¥ ­ ¤ ® ¨ ¡ °   ¡   ¦ « ¤   « £ § ¤ §
¢ § ² ¡   ¡ ¤ § ­ ® ´   µ ¤ ¡ § ¢ ® ¶ § ­ ® ´   · ­ « ¤ ¤ ¡ ­ ­ ® ´   ¬ ¡
¡ º » ¼ ¡   ¡ ¥ µ ¨ § ¥ § ¬ « ¡   ¦ ¡ ­   « ¢ « ² ½ § ¥ ¾ ¡ ¨ ¬ ¡ ¿ § À § µ ¡  
£ § ¤ ¦ ® ­ ° ¢ § ¤ ¡ ¢ ¥ ¡ ¤ À ® ¬ « ¤ Ã « ¼ ­ § ¦ · ¢ § ¥ £ » ² ®   § ¥
¬ ®   » ¼ ® ­ § ¥ ¿ Æ Ç È Ÿ ¥ ¦ ¡ ¡   ¦ « ¤   « ¥ ¡ ®   ¦ ¡ ² ¤ § ­ «  
Ë
¡ ¤ ¤ § ¼ ® ¡   ¦ § ¥ ¬ ¡ ¡ ¢ § ¨ « ¤ § ­ ® ´   ¬ ¡ ­ «   ¦ ¡   ® ¬ « ¥
¬ « ­ ¡   ¦ ¡ ¥ Î ° ¡ ° ¦ ® ¢ ® ¶ §   ¡ ¢ ¢ ¡   ² ° § ª ¡ Ï « ­ ¨ « « Ð Î ° ¡ ¡ ¥
­ «   Ñ « ¤ ¼ ¡ ­ «   Ò Ó Õ È Õ § § £ ¢ ® ­ § ­ ® ´   ¬ ¡ ¢ ¡   ¦ « ¤   « ¥ ¡
­ ® ¤ ­ °   ¥ ­ ¤ ® ¨ ¡ ¡   ¢ § ¡ À § ¢ ° § ­ ® ´   ¬ ¡ ¢ § ¥ ¥ ¡ ¥ ® «   ¡ ¥ ¬ ¡
£ ¤ » ­ ¦ ® ­ § ¥ ¼ ¡ ¬ ® §   ¦ ¡ ­ ° ¡ ¥ ¦ ® «   § ¤ ® « ¥ ¬ ¡ ¦ ® £ « ¦ ¡ ¥ ¦ È
Ï ® ­
Ë
« ¥ ­ ° ¡ ¥ ¦ ® «   § ¤ ® « ¥ ¥ ¡ ² ¡   ¡ ¤ §   § £ § ¤ ¦ ® ¤ ¬ ¡ °  
¤ ¡ £ « ¥ ® ¦ « ¤ ® « ¥ ¡ ¢ ¡ ­ ­ ® «   §   ¬ « · ¤ ¡ « ¤ ¬ ¡   §   ¬ «
£ ¤ ¡ ² °   ¦ § ¥ · ¤ ¡ ¥ £ ° ¡ ¥ ¦ § ¥ Ú Û
Ü Ý ß à á â ã ä å æ ç
è é ê ë ì í ì î ï ì ï ë ð ñ ð ò ó ì í ï ð ó ë õ ì î ï ð ö ó ð ÷ ð ø õ é õ ï ð ë é ð í
ï ð ë ì ð í ö ì ù ì î ì ë ð ø õ ú î û ø ó ë ë ì ø ø õ ú î ö ì ì ü ý þ ì î ì í
ÿ
  ì î ê ð ë ï õ ø  é ð ë í ì ï ë ð ï ð ö ì ì  ð é  ð ë ì é ð ê ë ì î ö õ  ð ò ì
ö  ë ð î ï ì é ð í í ì í õ ó î ì í ö ì ê ë ý ø ï õ ø ð í  þ ì ö õ ð î ï ì  î
ì ü ð þ ì î ö ì ï õ ê ó ï ì í ï Û  õ ø  ó ì ü ð þ ì î í ì ë ì ð é õ  ð ë ý ð é
÷ õ î ð é ö ì é ð í ì í õ ú î  ì î  î ï õ ì þ ê ó ê ë ì ì í ï ð ñ é ì ø õ ö ó  û
í ì ø ó ë ë ì ù õ ë ý ö ì ÷ ó ë þ ð ð  ï ó þ ý ï õ ø ð Û
 ó í ù  õ ó î ì í ö ì ê ë ý ø ï õ ø ð í í ì ì é ð ñ ó ë ð î ø ó î ì é
÷ ó ë þ ð ï ó     ó ø ñ ó ó  ÿ   ÿ   ì õ î ø é  õ ë ý î  î
ë ì ê ó í õ ï ó ë õ ó ö ì ê ë ì ù  î ï ð í   õ î ø  é ð ö ð í ð ø ð ö ð ï ð ë ì ð Û
" ð ö ð ù  õ ú î í ì ê ë ó ø ì í ð ø ó î  %  ' ê ð ë ð ù ì î ì ë ð ë ê ó ë
 î ð ê ð ë ï ì ì é ö ó ø  þ ì î ï ó )  , ê ð ë ð é ó í ð é  þ î ó í û
ê ó ë ó ï ë ð ì é ë ì ê ó í õ ï ó ë õ ó .  ì í ì  õ î ø  é ð ë ý ð é ð
ð ê é õ ø ð ø õ ú î ö ì ù ì î ì ë ð ø õ ú î ö ì ì ü ý þ ì î ì í Û  ì ì í ï ð
÷ ó ë þ ð í ì  ï õ é õ  ð  î ð 3 î õ ø ð  ì ë ë ð þ õ ì î ï ð ê ð ë ð ð þ ñ ð í
ï ð ë ì ð í  ÷ ð ø õ é õ ï ð î ö ó é ð é ð ñ ó ë ð é ð  ï ó ë Û
4 5 6 8 5 9 :
; = > ? A ? B D E D G I J D > L M I > O E P A R T L I R D M I W I B A X W B I [ B D \ D
] ^
= = = ` M A X D a R L P A B > L M D M
]
I X L ? c T R L T D M A e D X A R T L D f
g h h j k l m h m l n o p q
r h s s t k k h p h m u v j k q k h r
r l w u l q o x q r q r j q m l y l m h m l t o q r z
{ | }    ‚ ƒ „  „ „ † ˆ † ‰ † Š  Š † ‹ Œ  † ‰ †   ‘ †  ’ “ Š ƒ “  
  Š ’ ƒ Š „ † ” ‰ ‚ “ ‰ – ” ‰ ’ “ „ †  Š † ˆ ” ‰ ’   — Š †   ” †  ’  
 Š † „ † ’ † Š  ƒ ‰  „ “ | ˜ h p h h k u v o t p q š q s q h k l › h s u o
q œ h v q o p l y q s q o x q q o m u h o x t h j s q w u o x h r ž t s p q o
p q q r x h r Ÿ p q r u r s q r j u q r x h r |
  | ¡ † ˆ ” Š ƒ „  „ † ‰ ‘  Š †  ‘ ƒ ¤  ‚ ƒ ¥ ‰ „ † ‘ “  † ‹ Œ  † ‰ †  |
g t r h k u v o t r o t j u q p q o q p l x h s r u r s q r j u q r x h r o l
w q o q s h s p t r q œ ¨ v q o q r p l y q s q o x q r ž h p q v ¨ r r q
p q š q m t o x s t k h s « u q q k h m m q r t h k h h j k l m h m l n o r q h
s q r x s l o w l p t Ÿ x h o r t k t k t r h k u v o t r v h x s l m u k h p t r
j u q p h o s q h k l › h s k t r q œ ¨ v q o q r |
­ | ¯ ” ’ “   ’ ƒ ¤  ‚ ƒ ¥ ‰ „ † ‘  Š “ ‚ †  “ „ † ‚ “ Š Š † ‚ ‚ ƒ ¥ ‰ | g h
t š x q o m l n o p q k h m h k l y l m h m l n o r q s ¨ h u x t v ¨ x l m h ž h r °
v l r v t r q w q o q s h s ¨ o y t s v h x t r p q j s q r q o x h m l n o
p q k h r m h k l y l m h m l n o j h s h j h o x h k k h Ÿ j h s h r u
l v j t s x h m l n o h ¶ q s s h v l q o x h r p q q k h š t s h m l n o p q
h m x h r |
¸ q x t p h r k h r j t r l š k q r x q m o t k t w ° h r p l r j t o l š k q r
j h s h q k p q r h s s t k k t ¹ q š ž ¶ q v t r t j x h p t j t s º h » h
m t v t ¶ q s s h v l q o x h Ÿ š h r q p q x t p t q k p l r q ¼ t | g h
q k q m m l n o r q ¶ h š h r h p t q o k h l o p q j q o p q o m l h p q k h
j k h x h y t s v h ž q o k h p l r j t o l š l k l p h p p q q o x t s o t r p q
p q r h s s t k k t j s t p u m x l » t r Ÿ p q k r q s » l p t s ¹ q š p q
p l r x s l š u m l n o k l š s q À t v m h x Á    |
Ã Ä Æ Ç È É Ê Ë Ê Ì Í Î Ï Ð Ç Ñ Ó Ç Ô Î Ö Î
Ø Ù Ú Ù Û Ü Ý Þ ß à á â ã Û
ä å æ ç è é ê ë ê ì í å î ï ð é è ð î å ë ñ ò ç ò æ ð ë ð ó å ë å å î ë ð è å è ð ô é ç õ
ë å å ë æ ç ï é å æ ð ö å å î ê ï æ å ÷ å î ê ï ø å ö å å ë å î ï ê ì ï å ù å è ð ô é
÷ ç ë å ú é æ ç ï û å ó ÷ ç ü ê ù î ò ç ï æ å ü ê ù ý é þ ü ÿ ú  ê õ ç å
   
            
 
  !   "    & ' ) * + -  
/ 0
! 1 3   5 1 3
0 6
1 7        3 
 3  < 

6
 5    3
/

 !

6
  "  
    & A B     F  7 B   3  3 
 
 1 5 
I  K L  7  B  3 5  7 
6
 B 3  7 
/
 1 3  

6
 5 1 
 3 
 B 3 
/
  1 7 1 N 3
/

   3 1  3   5  B 3 3    !  5 

I  K B  
 7 1  3   U W W  L    K     5  5     

/
1 7  7 1  3   5   
 1 5 
+ -      ] 
/


6
1   3
6
 ^ 7 
U W ` -   
0
3 5 
   
0
 1 7  7  3 B 3
7  3   3 1 5  5 1 3
0 6
1 7  !  3 
 5 
/

   
    +  B
< 1 3  1 5  5   i
j
-  
  5      3  1  5  
/

 B  B 
1  +
j n
B  7 
7 B  A B 1 
 
 1 3 < 

6
 7 1 N 3
 
/
 7   

/
  1 7 1 N 3 A B     s 1 3 7
B    5   3 
/
  1 7 1 N 3
U W W  +
j u
 3 

 
  B   5   +
j v

< 

6
     
  B   5   5  3 
 5  B 3
5  7 B
6
 3   +
j v
    
 5  7 B
6
 3    7 1  3   +
    
/
B  5   |   3 5 

6
 5 1  3    7
1
/
  A B 
1 3 7 

/

 3 7     5       B  1 1 ^  3 5    3 ! B  F 
5    1 A B       W - ' ~ * + -  < B 3 7 1  3  1 5  5 5    W -
 
6 0
 1
6
1   5 
/

  B B  1 1 ^  7 1 N 3
  B  
6 0

  3 7 1  + € 3 3 B   
 
/
1 7  7 1 N 3       7   B   5 

6
K   
/
7 1  3  
/


/

 7   
‚ ` - 5   5   
/ 0
! 1 3      +
„ … „ … † ‡ ˆ
‰ Š ‹ Š Œ  Ž  Š    Ž Œ ‘ ’ “ ” Š ‹ Ž – Œ Š ” Š Œ  — Š “ ˜  ™ Œ š ”  “ ’
  Š ™ › ” Œ ’ œ   ™ Œ š ”  “ ’   ž “  Ÿ › Œ  Š œ  Œ  ™
“  ž ’ œ Ž  ’ “ Ž ’   Œ ’ œ  “ ¡ ” ›   ™  ¢ Š  Š  Œ  ™ ‹ ’ Œ   ¤  ’  
™ Š Š ž ™ Ž ‹ Š ‹ Ž – Œ ¥ § ’ Œ œ Ž   “ Š Œ  ’ Š   ” ¡ œ ¨ › 
›  Ž ™ Ž © Š ” ’ œ ª ’ ‹ « ’ ’ ¬ ­ ® ¯ ž Š “ Š ™ Š  ™ Š « ’ “ Š ‹ Ž – Œ   ™
” Š   “ Ž Š ™  ’ ‹  Œ   ± ²  ” ’ œ ’ ž  Š  ’ ž ’ “ ³ ´ ‰ ­ µ ¯
‹ ’ ” ’ œ Ž œ   ” Š   Š ™ ” Š ‹  Œ Š ” Ž  Œ  ’   Ž Œ ‘ ’ “ ” Š ‹ Ž – Œ ¥
‰ Š ‹ Š “ Š ‹   “ ¶ œ  Ž ‹ Š ž “ Ž Œ ‹ Ž ž Š ™   ™ ’ œ  ’ ‹ › ”  Œ  ’ œ
³ ´ ‰  œ ¨ ›   ’  Š ™ Š Ž Œ ‘ ’ “ ” Š ‹ Ž – Œ ¨ ›  Ž Œ ‹ ™ ›   Œ  œ  ¡
 œ  “ › ‹  › “ Š  Š  Œ ‘ ’ “ ” Š   ¡ “ « ’ ™    ™  ”  Œ  ’ œ  
” Š “ ‹ Š  ’   œ ‹ “ Ž ž  Ž ¢ ’ œ ±  ’ Œ   ‹ Š  Š  ™  ”  Œ  ’ ž ’ œ  
Š  “ Ž « ›  ’ œ  ‹ ’ Œ   Œ Ž  ’ ¥
¸ Œ “  Š ™ Ž  Š  ³ ´ ‰ Œ ’  œ › Œ ™  Œ Ÿ › Š —  œ Ž Œ ’ › Œ
‹ ’ Œ — › Œ  ’   “  Ÿ ™ Š œ  œ  “ Ž ‹  Š œ ¨ ›  ² Š   ‹ › ” ž ™ Ž “ › Œ
™  Œ Ÿ › Š —    ” Š “ ‹ Š  ’ ¥ º   œ  Š « ™  ‹  Œ  Š ” « Ž » Œ
”  ‹ Š Œ Ž œ ” ’ œ ˜ ª ½ ª   œ ¨ ›  ” Š œ   ž Š “ Š   ‘ Ž Œ Ž “
™  Œ Ÿ › Š —  œ   ” Š “ ‹ Š  ’ ¥ ‰ Š ²  “ “ Š ” Ž  Œ  Š œ  
ž “ ’ ‹  œ Š ” Ž  Œ  ’ ž Š “ Š ³ ´ ‰ ±  Œ ž Š “  Ž ‹ › ™ Š “ ™ ’ œ
ž Š “ œ  “ œ ± ž  “ ” Ž   Œ ¢ Š ™ Ž  Š “  ’ ‹ › ”  Œ  ’ œ ± ’ œ  Š
¢  “ Ž ‘ Ž ‹ Š “ ¨ ›  › Œ  ’ ‹ › ”  Œ  ’ ³ ´ ‰ œ  Š — › œ  Š Š › Œ Š
    “ ” Ž Œ Š  Š   ‘ Ž Œ Ž ‹ Ž – Œ   ™  Œ Ÿ › Š —    ” Š “ ‹ Š  ’ ¥
¸ ™  Ž ž
’   ’ ž  “ Š ‹ Ž ’ Œ  œ ¨ ›  œ  ž ›    “  Š ™ Ž © Š “
œ ’ « “   ’ ‹ › ”  Œ  ’ œ ³ ´ ‰ œ ’ Œ Æ ™ ’ ‹ Š ™ Ž © Š ‹ Ž – Œ  
 ™  ”  Œ  ’ œ ˜ ³ È Š  ²   ±  “ Š Œ œ ‘ ’ “ ” Š ‹ Ž – Œ ˜ ³ º ‰ ½   ±
‹ ’ Œ œ › ™  Š œ ˜ ³ Ê ›  “    ±  œ  Š « ™  ‹  “ ² Ž ž  “  Œ ™ Š ‹  œ
˜ ³ ‰ Ž Œ ¬   ± ‹ ’ Œ œ  “ › ‹ ‹ Ž – Œ ” ’  › ™ Š “ ˜ ³ Ë Œ ‹ ™ ›     ±   ‹ ¥ º 
 Ž œ ž ’ Œ   Š ” « Ž » Œ   Ì È Ë œ  œ ž  ‹ ¶ ‘ Ž ‹ ’ œ  Œ ™ ’ œ
™  Œ Ÿ › Š —  œ   ž “ ’ Ÿ “ Š ” Š ‹ Ž – Œ ” ¡ œ  ¤   Œ  Ž  ’ œ ¥
Î Ï Ð Ï Ñ Ò † Ó
¸ Œ  ™ ‹ Š œ ’   ™ ™  Œ Ÿ › Š —  Ô Š ¢ Š œ  ² Š Ž Œ ‹ ’ “ ž ’ “ Š  ’
“  ‹ Ž  Œ   ”  Œ   › Œ Ì È Ë ž Š “ Š ³ ´ ‰   Œ ’ ” Ž Œ Š  ’
Ô Ì ³ È ˜ Ô Š ¢ Š Ì È Ë ‘ ’ “ ³ ´ ‰ È “ ’ ‹  œ œ Ž Œ Ÿ   ­ Ö ¯ ±  ™ ‹ › Š ™
 œ  ¡  Ž œ ž ’ Œ Ž « ™   Œ  ™ ž “ ’ ž Ž ’ Ô × ¸ ž ’ “ ™ ’ ¨ ›  Œ ’ ² Š 
¨ ›  Ž Œ ‹ ™ › Ž “ ™ ’  ™ ™ Š œ ™ Ž « “  “ ¶ Š œ   Š ž ™ Ž ‹ Š ‹ Ž ’ Œ  œ 
Š ž ž ™   œ ¥
Ô Ì ³ È  œ  Œ “  Š ™ Ž  Š  › Œ Š Ž Œ   “ ‘ Š © ¨ ›  ž  “ ” Ž  
›  Ž ™ Ž © Š “  Ž ‘  “  Œ   œ Ž ” ž ™  ”  Œ  Š ‹ Ž ’ Œ  œ ¨ ›  œ  Š Œ
‹ ’ Œ ‘ ’ “ ”  œ ‹ ’ Œ  ™ ™ Š ± ž ›  Ž  Œ  ’ “   ” ž ™ Š © Š “ ™ Š
Ž ” ž ™  ”  Œ  Š ‹ Ž – Œ   ™ Ô × ¸ ž ’ “ ’  “ Š ” ¡ œ Š   ‹ › Š  Š ¥
¸ Œ Ô Ì ³ È œ   Ž œ ž ’ Œ     ’ œ ”  ‹ Š Œ Ž œ ” ’ œ ž Š “ Š
ž “ ’ ‹  œ Š “ ³ ´ ‰ Æ º Ì ³  ª Ú ´ ¥ º Ì ³ ˜ º Ž ” ž ™  Ì È Ë
‘ ’ “ ³ ´ ‰   ž “ ’ ‹  œ Š ™ Š Ž Œ ‘ ’ “ ” Š ‹ Ž – Œ ž ’ “  ¢  Œ  ’ œ ±
ª Ú ´ ˜ ª ’ ‹ › ”  Œ  Ú « —  ‹  ´ ’   ™   œ Ž Œ  ” « Š “ Ÿ ’
Ÿ  Œ  “ Š › Œ ¡ “ « ’ ™  Œ ”  ” ’ “ Ž Š ¥ ‰ Š ¢  Œ  Š — Š   ª Ú ´
 œ œ › œ  Œ ‹ Ž ™ ™  © ± Š ‹ ’ œ  Š   › Œ  ™  ¢ Š  ’ ‹ ’ Œ œ › ” ’  
”  ” ’ “ Ž Š ¥ º Ì ³  œ ” ¡ œ Š   ‹ › Š  ’ ž Š “ Š ž “ ’ ‹  œ Š “
 ’ ‹ › ”  Œ  ’ œ ” ›  Ÿ “ Š Œ   œ ¥ ¸ Œ Œ ›  œ  “ ’ ‹ Š œ ’ œ 
›  Ž ™ Ž © Š “ ¡ ª Ú ´ ž Š “ Š ™   “  Ÿ  Œ  “ Š “  ’ ‹ › ”  Œ  ’ œ
³ ´ ‰ ¥
Î Ï à Ï á â ã ä å æ
¸ ™ œ  “ ¢ Ž  ’ “ ç  « œ ’ « “   ™ ¨ ›  ‘ › Œ ‹ Ž ’ Œ Š “ ¡ ™ Š
Š ž ™ Ž ‹ Š ‹ Ž – Œ  œ ½ ’ ” ‹ Š  ¥ ¸ œ   œ  “ ¢ Ž  ’ “  œ › Œ
ž “ ’   ‹  ’ Š « Ž  “  ’   Ì ž Š ‹ ²  º ’ ‘  ç Š “  ê ’ › Œ  Š  Ž ’ Œ
  œ  ¡  œ ž  ‹ ¶ ‘ Ž ‹ Š ”  Œ    Ž œ  ë Š  ’ ž Š “ Š ‘ › Œ ‹ Ž ’ Œ Š “
‹ ’ ” ’ ‹ ’ Œ   Œ   ’ “ ž Š “ Š œ  “ ¢ ™   œ  ž ¡ Ÿ Ž Œ Š œ Ô º È ¥ ¸ Œ
ž Š “  Ž ‹ › ™ Š “ ›  Ž ™ Ž © Š ” ’ œ ™ Š š ™  Ž ” Š ¢  “ œ Ž – Œ  œ  Š « ™   Œ
 œ  ’ œ ” ’ ”  Œ  ’ œ ± ’ œ  Š ™ Š ¢  “ œ Ž – Œ Ö ¥
‰ Š ‘ › Œ ‹ Ž – Œ ¨ ›  “  Š ™ Ž © Š ½ ’ ” ‹ Š   œ  “ Š  › ‹ Ž “  ™
‹ –  Ž Ÿ ’ ‘ ›  Œ     › Œ Š ž ¡ Ÿ Ž Œ Š Ô º È Š › Œ œ  “ ¢ ™   ±
‹ ’ ” ž Ž ™ Š “ ™ ’  ‹ ’ ™ ’ ‹ Š “ ™ ’  Œ  ™ ™ › Ÿ Š “ ’ ž ’ “  › Œ ’ ž Š “ Š
œ ›  —  ‹ › ‹ Ž – Œ ¥ § › Š Œ  ’ › Œ › œ › Š “ Ž ’ “  Š ™ Ž © Š › Œ Š
ž   Ž ‹ Ž – Œ Š ™ Š ž ¡ Ÿ Ž Œ Š Ô º È ™ ’ ¨ ›  “  Š ™ ”  Œ   œ   œ  Š
 —  ‹ ›  Š Œ  ’  Œ  ™ œ  “ ¢ Ž  ’ “  œ › Œ Š Ž Œ œ  Š Œ ‹ Ž Š   ™
œ  “ ¢ ™   ¥
¸ Œ  ™ ¡ “ « ’ ™    Ž “  ‹  ’ “ Ž ’ œ   ™ œ  “ ¢ Ž  ’ “ œ 
  Œ  “ ¡ Œ ‹ Š “ ž   Š œ ž š « ™ Ž ‹ Š œ ± Š ¨ ›  ™ ™ Š œ ¨ ›  ‹ ’ Œ  Ž  Œ  Œ
™ Š œ ž ¡ Ÿ Ž Œ Š œ Ô º È ¨ ›  œ   œ ž  ‹ Ž ‘ Ž ‹ Š “ ¡ Œ  Œ ™ ’ œ
‹ ™ Ž  Œ   œ ±  ‹ Š “ ž   Š œ ž “ Ž ¢ Š  Š œ Š ™ Š œ ¨ ›  š Œ Ž ‹ Š ”  Œ  
734 Docencia en Arquitectura y Tecnología de Computadores
   
                     
      
     
         *        -          
0

0
     1                    5
0
   -   
 7
8          <            
0
8    
   *                    F
0
            1
   8
          J  8  1   M N P R  S -   T 
R  V          <              8      [   
      7      - 
0
   <   [       
5     M \ ] 
   _     8          8 a  b         a
0
 [ 
  a   
d f h i j k l m n k m o p q i r s s n r m k s k m o p
T  *      <  
0
      [     
       
0
8   
    w     
0
8        
 
0
      x  a 
0
  z { | F
0
   
0
 
  
5    M \ ]   5       [ 
   7  8    |     
0
                

0
 
          7  8     *   8    *   8
0
    
€
J  |  z     <  8          7  8        ƒ 
          
0
     
0
 a  [     *   8
0
      
           a       
0
   -           
0

  _    †  | F
0
   5
0
                    
      
0
8    z  8      8         a     
    
0
     [        
0
8       5
0
  F
0

        
 
0
  
0
8   Š    8   
     <  

0
  7  8   
|        [ 
0
   <  

0
            
   5
0
           
  F
0
  8    _ 
8                8       a            
0
      *   8   [  † \ | J   5
0
 [       
 
       N  a   ’  “                

       
0
   <            M      M T † ]    
 7    
0
 
0
a   w
0
       5
0
   - 5      
             7  8           
        8             5
0
    8    
            
0
   
|       [        7
8            <   
   *       5       
5    M \ ]        [  F
0

                        
0
8            
    
0
8        7  8    “  8    
0
     
5     
0
   a  
€
J  |          F
0
  
8
0
             -
0
   _     
0
 *   8  
  
0
       
0
  
0
  [       5   8    
5    [            w       5   8  ] T N { ž Ÿ    
  z ] ¡ ¢ 
£ ¤ ¥ ¤ ¦ § ¨ © ª « ¬ ­ ® § ¯ ¬ ° ® ±
² ³ ´ ³ µ ¶ · ¸ ³ µ ³ ¹ º » · ¼ ³ ³ ¶ ¼ ½ ´ ³ ´ ½ ¾ ¿ » · ¿ ¸ µ À » · ¼ ³
´ ³ µ ¶ · ¸ ³ » · Á À Â ´ ³ ¸ · Ã Ä Å Æ Ç Ä È Ä É Ê · ¿ ¼ ³ Ë Ì · Ã · ¸ ½ · ¿ ·
¼ ³ Ã Ã ½ Í Ì ½ · ¿ ¸ · Ã Ã Ì Î ´ ³ µ ¶ · ¸ ³ Ã Ï
Ð Ñ Ò
Ï ³ ¼ Â ³ ´ · ¿ ³ ¸ À » ³ ¼ ³ » À ´ Ì Â · ¿ ¸ ³ ´ ½ ¾ ¿ » · ¼ ³
³ ¶ ¼ ½ ´ ³ ´ ½ ¾ ¿ · ¿ · ¼ Ó À µ Â ³ ¸ À Ë Ì ·
à · » · à · · Ô
É Õ
Ò
Ï ´ À ¿ ¸ ½ · ¿ · ¸ À » ³ Ã ¼ ³ Ã ´ ¼ ³ Ã · Ã · Ö ¸ · µ ¿ ³ Ã ´ µ · ³ » ³ Ã
¶ ³ µ ³ ¼ ³ ³ ¶ ¼ ½ ´ ³ ´ ½ ¾ ¿ Ô × ¿ · Ã ¸ · ´ ³ Ã À Ã · Ø ³ ¿ ´ À ¼ À ´ ³ » À
¼ ³ Ã ´ ¼ ³ Ã · Ã ´ Ì · Ã ¸ ½ À ¿ Ô Ù ³ Ú ³ Û ¶ ³ µ Ã · µ Ô Ù ³ Ú ³ Ô
Ý Þ ß à á â ã ä å á æ ç è é ê é Þ á ê ë ì ç á Þ ç í é ê è â â î è Þ ë â ë Þ ï ð
ñ
Ä ò Ï · Ã ¼ ³ ´ ³ µ ¶ · ¸ ³ Ó Ì · ¿ ¸ · » · ¿ Ì · Ã ¸ µ ³
³ ¶ ¼ ½ ´ ³ ´ ½ ¾ ¿ Ê · ¿ · ¼ ¼ ³ Ã · · ¿ ´ Ì · ¿ ¸ µ ³ ¿ ¸ À » À Ã ¼ À Ã
³ µ ´ Ø ½ Ú À Ã ö Á ÷ ² Û ø ù ú ¿ · ´ · Ã ³ µ ½ À Ã Ô û Ã ¹ Â ½ Ã Â À
½ ¿ ´ ¼ Ì Û · ¸ À » ³ Ã ¼ À Ã Ã Ì Î ´ ³ µ ¶ · ¸ ³ Ã Ë Ì · Ã · µ · Ë Ì ½ · µ ³ ¿
¶ ³ µ ³ À µ Í ³ ¿ ½ º ³ µ ¼ ³ ³ ¶ ¼ ½ ´ ³ ´ ½ ¾ ¿ Ê · ¿ ¿ Ì · Ã ¸ µ À ´ ³ Ã À
Æ ü ý Ç È
Ñ
É Û þ Õ
Ñ ÿ
Ä É
Ñ
Õ Ô Á ³ Â Î ½
¿ » · Î · · Ö ½ Ã ¸ ½ µ · ¼
» ½ µ · ´ ¸ À µ ½ À   
              "  $  '  )   ' " 
"  $ )   .   0 2 3 5 6 8 : ; =   ' @  @ "    @ '  C  D  " 
   H  .  ' @   I  "   "  $  )   "   $ )    H   @ '   @  $
@ ) N .   @ "        R @ $ U   @ $ "  $  .  '  " @ " R   
 W '  ' X @ $ "         @ $ [ = \ ^ $      U @  R    ;
\ @ b W  c           @ '  C  D  "   $ " @   $ "   $
@  b   $ g h : i 8 j k l 5 6 8 : n o  '  )  $    '   " 
) '  .    @ $ g 2 6 h 8 t 2 u k 5 6 8 : n ; w    '  "    
  $ 
     @ $ $  .       $ $  W  @ ' )   @ $ y
  
  z { : h l l 2 l y         @ $  @ $  $ " 
|
@ D @   b )  @ " @ $ ;
  
  z : } 3 y         @ $  @ $  $
  b )  @ " @ $        U @  [ = \ ^ ;
  
  z € :  y          $ @ '  C  D  $ " 
 $ )    H   @   I  "         @ $ ) @ ' @ [ = \ ^ ;
3 i } :  y  $  @  @ ' )   @ $  .    ' @ "  $ "  ˆ   o
        @ @ )   @   I    b )  @ " @ ; ‰ $   @   )  @ " 
"  '     '   0 2 3 )  '     @ "  H  '     @ "      
  
  z { : h l l 2 l  $  N  @ $  @ $  $   b )  @ " @ $ " 
l t { ; ^ @ Œ  ^  $ )    H   @ " @            b @  $  @
 @ ' )   @   b  ' @ X U o )  '  @      "  $         "   $
)  W        )   @  @ ' )   @   
  ; ‰ $  @  @ ' )   @
XVI Jornadas de Paralelismo, JP '2005 735
   
      
               
   !     $
                  
      ! -         
 /  -          3 
  4
5 6 7 6 8 : < > ? < @ A B A @ C ?
D
       
                 G    I       3 

!     3  
   -       - 
  !          G 
 -   -    
   P  -    4 S          I 

   Y 
 !      
      
     G  [ \ ] ^ _ ` a b c d e

 
       
!       - j   $       

!  !     4 P  -      m !     !      

 !  !     
[   ! -    $   p       q m ! 
 j      !       - 
   
     I   
 !  !     
 P  -    [ v ] w x y v z
{
c | } c a ~ w \ q 4    I     I         !         
 ! j       x ] ` ‚
        
          G 

P  -    4 † m ! ‡    
      - j  ˆ       -     m ! 
      
 !  !         
 p              
       
  4
D
    
 m !     
! 3   !  p    

 !          G  P  -     
             !  
   
      [ | } } ] } a b c d q m !    -      !  !    
                !           4

  !          G    - j   
         -    

          !   m !   
 !  !     ’     -    
! 
    
           m !           
  4

                
 
          G    I  

  
       
       

     !  • | – a ~ w \ 4
— ˜ ™ š › œ  ž   š ¡ ¢ £ ¡ ˜ ¤ œ ¤ ˜ ¥ £
¦ § ¦ § ¨ © ª « ¬ ­ © ª ® ¬ ¯ ° ± ² ³ « ´ ± ª
µ ¶ · ¸ ¹ ¸ º » ¼ ½ ¾ ¿ ¹ ¼ º À Á · ¾ Â · ¸ ½ º » ¼ ¹ ¼ Ã ¸ Ä ¼ À » ¶ ¿ ¿ ¹ ¿ ½
¸ Å » Æ ¶ ¿ ½ º ¿ À Å ¿ Ç » ¼ Ã ¸ È Ç » ¼ · ¿ ¶ ¾ ¼ Æ º Å ¸ À Å ¸
½ Â ¾ » ¸ · Â Ê ¶ ¹ ¼ Ç » ¼ ¹ ¿ ½ ¸ Å » Æ ¶ ¿ ½ À ¼ ¸ Å Â · ¼ ¶ ¼ Å ¼ Ë ¸ Æ ¼ ¶
· ¿ ¶ Ì » ¶ ¾ ¸ Æ ¼ ¶ ¾ ¼ Í Î ¸ À ¸ ¼ Å Å ¿ ½ ¼ ¹ Â ½ º ¿ ¶ ¼ ¹ ¼ Å ¸ º Á Ï Â ¶ ¸
Ð Ñ Ò Ó
Ô Õ Ö × Ø
Ç » ¼ ½ ¼ · ¸ À Ï ¸ ¹ ¼ ½ º » Û ½ ¹ ¼ » ¶ ¸
¸ » ¾ ¼ ¶ ¾ Â · ¸ · Â Ê ¶ · ¿ À À ¼ · ¾ ¸ Í Þ Â · Ã ¸ º Á Ï Â ¶ ¸ Â ¶ · Å » È ¼ » ¶ ¸
Å Â ½ ¾ ¸ ¹ ¼ ½ º Å ¼ Ï ¸ Ä Å ¼ ¼ ¶ Å ¸ Ç » ¼ ½ ¼ º » ¼ ¹ ¼ ½ ¼ Å ¼ · · Â ¿ ¶ ¸ À ¼ Å
¶ ¿ Æ Ä À ¼ ¹ ¼ Å · ¿ Æ º ¸ à ¼ À ¿ Í á ¿ ½ ¶ ¿ Æ Ä À ¼ ¹ ¼ Å ¸ Å Â ½ ¾ ¸ ½ ¼
¿ Ä ¾ Â ¼ ¶ ¼ ¶ º ¸ À ½ ¼ ¸ ¶ ¹ ¿ ¼ Å ¹ ¿ · » Æ ¼ ¶ ¾ ¿ ä å æ ç
Ñ è × Õ Ô
ç å
Ç » ¼ Â ¶ · Å » È ¼ Å ¿ ½ Â ¹ ¼ ¶ ¾ Â é Â · ¸ · Â Ê ¶ ¹ ¼ Å ¿ ½ ¸ Å » Æ ¶ ¿ ½
Æ ¸ ¾ À Â · » Å ¸ ¹ ¿ ½ Í
¦ § ê § ë © ­ © ² ± ® « ì ­ ´ © î © ï ± ¯ © ­
á ¸ Ï ¼ ¶ ¼ À ¸ · Â Ê ¶ ¹ ¼ Å ¿ ½ ¼ Ë Á Æ ¼ ¶ ¼ ½ ½ ¼ À ¼ ¸ Å Â ð ¸ ¼ ¶ Å ¸
º Á Ï Â ¶ ¸
Ó Ô
ä ç
Õ Ö × Ø
Í µ ¶ º À Â Æ ¼ À Å » Ï ¸ À ½ ¼ Ã ¸ ¹ ¼
· ¿ Æ º À ¿ Ä ¸ À Ç » ¼ ¼ Å » ½ » ¸ À Â ¿ ¸ » ¾ ¼ ¶ ¾ Â · ¸ ¹ ¿ ¶ ¿ Ã ¸
À ¼ ¸ Å Â ð ¸ ¹ ¿ º À ¼ ó Â ¸ Æ ¼ ¶ ¾ ¼ ¼ Å ¼ Ë ¸ Æ ¼ ¶ · ¿ À À ¼ ½ º ¿ ¶ ¹ Â ¼ ¶ ¾ ¼
¸ Å ¸ º À Á · ¾ Â · ¸ Í Î ¸ À ¸ ¼ Å Å ¿ ½ ¼ Å ¼ ¼ ¼ ¶ ¼ Å À ¼ º ¿ ½ Â ¾ ¿ À Â ¿ ¼ Å
 ¹ ¼ ¶ ¾  é  · ¸ ¹ ¿ À ¹ ¼ Å ¸ º À Á · ¾  · ¸ Ç » ¼ ½ ¼ ¼ ½ ¾ Á À ¼ ¸ Å Â ð ¸ ¶ ¹ ¿ ô
È ¸ º ¸ À ¾ Â À ¹ ¼ ¼ ½ ¾ ¼ º ¸ À Á Æ ¼ ¾ À ¿ È ¹ ¼ Å Â ¹ ¼ ¶ ¾ Â é Â · ¸ ¹ ¿ À
¹ ¼ Å ¸ Å » Æ ¶ ¿ ½ ¼ ¹ ¼ ¾ ¼ À Æ Â ¶ ¸ ½ Â ¼ Å ¼ Ë ¸ Æ ¼ ¶ È ¸ é » ¼
Ï ¼ ¶ ¼ À ¸ ¹ ¿ ¿ ½ Â ¼ ½ Å ¸ º À Â Æ ¼ À ¸ ó ¼ ð Ç » ¼ ½ ¼ ½ ¿ Å Â · Â ¾ ¸ Í õ Â
¼ Å ¼ Ë ¸ Æ ¼ ¶ È ¸ é » ¼ Ï ¼ ¶ ¼ À ¸ ¹ ¿ ½ Â ¶ Ã ¸ Ä ¼ À ½ ¼ À ¼ ¸ Å Â ð ¸ ¹ ¿ ô
¼ ¶ ¾ ¿ ¶ · ¼ ½ ½ ¼ ó » ¼ Å ó ¼ ¸ ¼ ¶ ó Â ¸ À Å ¸ Æ Â ½ Æ ¸ Â ¶ ½ ¾ ¸ ¶ · Â ¸ Í õ Â
¼ Å ¼ Ë ¸ Æ ¼ ¶ ½ ¼ Ã ¸ À ¼ ¸ Å Â ð ¸ ¹ ¿ ¼ ¶ ¾ ¿ ¶ · ¼ ½ Å ¸ º ¼ ¾ Â · Â Ê ¶ ½ ¼
À ¼ ¹ Â À ¼ · · Â ¿ ¶ ¸ ¸ ö
Ó ×
æ å ÷ ä
Ò è × Õ Ö × Ø
Æ ¿ ½ ¾ À ¸ ¶ ¹ ¿ ¼ Å ¼ Ë ¸ Æ ¼ ¶
· ¿ ¶ Å ¸ ½ À ¼ ½ º » ¼ ½ ¾ ¸ ½ ¹ ¼ Å ¸ Å » Æ ¶ ¿ ô Å ¿ · » ¸ Å º ¼ À Æ Â ¾ ¼
· ¿ Æ º À ¿ Ä ¸ À Ç » ¼ ¼ Å º À ¿ · ¼ ½ ¿ ½ ¼ Ã ¸ À ¼ ¸ Å Â ð ¸ ¹ ¿
· ¿ À À ¼ · ¾ ¸ Æ ¼ ¶ ¾ ¼ Í µ ¶ · ¸ ½ ¿ ¹ ¼ Ç » ¼ ¼ Å ¼ Ë ¸ Æ ¼ ¶ ¶ ¿ Ã ¸ È ¸
½ Â ¹ ¿ Ï ¼ ¶ ¼ À ¸ ¹ ¿ º À ¼ ó Â ¸ Æ ¼ ¶ ¾ ¼ ½ ¼ Â ¶ ½ ¾ ¸ ¶ · Â ¸ » ¶ ¿ Ä Ì ¼ ¾ ¿
¹ ¼ Å ¸ · Å ¸ ½ ¼
Ø
ä ö
× Ó
ö
Õ Ö
ä ý ä Ç » ¼ Ï ¼ ¶ ¼ À ¸ À Á » ¶ ¶ » ¼ ó ¿
¼ Ë ¸ Æ ¼ ¶ ¸ º ¸ À ¾ Â À ¹ ¼ Å À ¼ º ¿ ½ Â ¾ ¿ À Â ¿ Í
— ˜ ™ š › œ þ ž ÿ

 
  
 
  

     ! # $ & $ ' $ )  ) + # . 0 + + ' + 5  6 + 8 # + 
 +  ' $ :  ) !  !  ) ! #  ' 0 6 8 ! # > 0 8 ! ) + + ' ' ! # >  A  > 
B
! 8  + #   ) ! ! E + 8 +   ) ! # 0 + 5  6 + 8 H + 8 + #  +
B
 # ! # +
E + 8 +    I 0 8 6 + 8 #  M + ) + +   !  $ 8 ) $
B
 8 ) ! . 0 + # +
R
0 + '
R
   +  ' $ :   + ' + 5  6 + 8  +  ! + #  
R
+ :
B
 ) 
 ' 0 6 8 !  !  # +     ) ! U
736 Docencia en Arquitectura y Tecnología de Computadores
   
    
             ! "   
$ & ( ) + , - /
  1  2    5 7 2   9    ;    7      A "     
7    1 7    9  E F H I 1     5   " 7  9  5 A   5
  5 7  5 9  5 I N 7  ;        9  5      1       
1    9          1      7    T
U V W V Y Z [ [ \ ] ] ^ _ `
a    ;  5   7     2 9       1 7   N 7         9 
  1    ;  1  1  g      5   !     5     
   5
1   "       7  1     9  n  2   ! "    p q r r
$
p s
+ , - /
T
a 5 9 ! ! "    v    7 2  1   5    7   1    9 
  9  "       5             5 g       ;  5  
9   "   1 1  5        7 9   9  1  1  g  T ~     9    5  
5  " 7      5 g   5      9   5 9 !     1  g      v  5 9
     5    1 7   9     5        n  2 T      
;  1           5 9    1  g  A       …    †   1  9
7    5     ~ ‡      ;  5         2    9     T
H   2 9   1  g      1    ;  1  1  g  ;     5      

  5      9    5   5   !     5   5    2   5     5
1    9  5       5     5   7    5 T ‡      5 7  9   
5  "        7     9  7   ! "    ‰ † F H I N 7 
    9      5 7   
 1  g      9         5   9  5  
7  ;     9    9  2   I A    9   7    1 v      9   9 
      9       5  1   5 N 7    1  7 A  7   1   7   
1      ‹ Œ   1      7    A  9   1   5 7   9  T
a 5 9  ;     9   5     N 7             1  1  g 
~ ’  “ Œ ‹ ”      "  5 9  g      9  5     ~ – T
— ˜ ™ š › œ ›  ž Ÿ ›   ¡ ¢ ¤ œ ž ž ¥ œ › Ÿ ž Ÿ ›   ¡
¦ § ¨ § © ª « ¬ ­ ® ¯ ° ± ¯ ­ ¯ ¬ ² ± ­ ³ ® ¬ ´ ³ ­
µ ¶ ¸ ¹ º » ¶ ¼ ½ ¾ » ¼ » ¿ ½ ¿ ¹ À º ¼ ½ Â Ã Ä ¾ Å ¹ ¾ » ¿ ¿ ½
¼ ½ ¼ ¹ ¾ » Ã Ä Æ º Å ¹ ½ È Â É Â Ã ½ ¼ ½ Å ½ Ã È ¹ º » ¼ É Â » Ã » ¶ »
à ½ » ¶ ¹ Ë » ¾ ¹ À º ¼ ½ ¶ ½ Í » È ½ º Î Ï º Å É º ¾ ½ ¿ ½ ¶ Â Ã É ¸ ½ ¿ É Ã
¹ º ¹ ¾ ¹ » Ã Ä ½ ¶ ¿ ½ Ã Ð ¹ ¼ É Ã Ñ » ¾ ¹ ½ º ¼ É Æ ¿ É ¼ ½ Æ º » Ã ¾ Ñ ¹ Ð É ¼ ½
À Ã ¼ ½ º ½ ¿ ¼ ½ ¹ º ¹ ¾ ¹ É Î Ò ¹ ¾ Ñ É » Ã ¾ Ñ ¹ Ð É ¼ ½ À Ã ¼ ½ º ½ ¿ ¶ ½ ½ ½ ¶
à ½ Â É ¿ ¹ Å É Ã ¹ É ¼ ½  à ½ Ô Æ º Å » ¿ Õ Ö × Ø Ù Õ Ú Û Ü Ö Ø Ý Þ Â Î ½ ß Î
¼ ½ ¿ ¼ ½ Æ º » Æ º ¹ ¼ » ¼ ½ Í Å ½ Ã º » à á ¶ É ¾ É Â ¹ » ½ º ¶ » ¾ » Ã Â ½ Å »
â
Õ ã ä å æ ç è é ê ë ì » ¾ É º Å ¹ º Æ » ¾ ¹ À º » Ã Ã » º ¾ » í É È ¾ » Å á
¼ ½ ¿ Â ¶ ¹ ½ Ô » ¶ » » Â ¶ ¹ ¾ » ¾ ¹ À º Î
î ï ð ñ ò ó ô õ ÷ ø ò ò ù ú ú ï û ü
ý þ ÿ
         ÿ þ 
   ÿ
    
ÿ   
  ÿ  
  "   $      (  
  + ÿ - 
$    ÿ -  0
 
ÿ  - 
    ÿ -  
    2     ÿ  ÿ  5 " 7  8 7 - 
þ
  -    
$    ÿ   ; 7 < 
ÿ  
   "   $      8  - þ  ÿ  + þ

ÿ  -   B    0   
        
ÿ -  0
" ÿ  ÿ ÿ " ÿ 2 ÿ 
G   - ÿ  J  ÿ -   þ
ÿ -  "  ÿ     2 þ    ÿ   
    -          +  
  5 P Q R S T U V W X Y V [ V \ ; 7
^ ÿ  (  
-  0
  ÿ - ÿ  $  - ÿ -  0
  ÿ  "  + -   - ÿ 
  ÿ  b ÿ  ÿ     B ÿ ÿ - ÿ (  ÿ - -    
  ÿ ÿ " + 2 
ÿ
-     -  7 8  "  ÿ -         -   (  0 ÿ
       
  7
c d e d f g h i j k l m n l j l q r s l q t v g r s
w x y z { | { } x ~ {  €  ‚ | x x ƒ | { ~ x ~ {  € ƒ „ … ƒ x … z ‚  ‚ | „ †
x | y ‡ € „ † … ‚ † y | z x ‡ y Š † { ‡ ƒ | ‚ Š x ‹ y ‚ Œ € { ~ x ‡ ‚ € z ‚
z { ‚ € ‚ € ‹ y ‚ x y z ‚ € z { ~ x … † ‚  {  ‚ € z { Ž { ~ x … x † y ~ „ ‡ ƒ x  ‚ … „
† { ƒ … „ ~ ‚  ‚  ~ „ € z ‚ † z x … ‚ | ‚ ‘ x ‡ ‚ € ‡ x … ~ x €  „ | x †
~ x † { | | x †  ‚ | Ž „ … ‡ y | x … { „ Š ƒ y | † x €  „ ‚ | “ „ z  €  ‚
‚ € ” • „ – — { € x | ‡ ‚ € z ‚ † ‚ ƒ y ‚  ‚ ” ‚ … { Ž { ~ x … ‹ y ‚ ‚ |
‚ ‘ x ‡ ‚ € † ‚ œ x  ‚ € ‚ … x  „ ~ „ … … ‚ ~ z x ‡ ‚ € z ‚ { € { ~ { x €  „
y € x € y ‚ ” x † ‚ † {  € –
Ÿ | ƒ … „ ~ ‚ † „  ‚ ~ „ € z … „ |  ‚ | x … ‚ x | { } x ~ {  €  ‚ | „ †
‚ ‘ ¢ ‡ ‚ € ‚ † x † ‚  y … x ‹ y ‚ € „ † ‚ ƒ y ‚  x € ‡ „  { Ž { ~ x … | x †
… ‚ † ƒ y ‚ † z x † y € x ” ‚ } Ž { € x | { } x  „ y € ‚ ‘ x ‡ ‚ € – ¥ † •
‡ { † ‡ „  y € x | y ‡ € „ € „ ƒ y ‚  ‚  ‚ € ‚ … x …  „ †
‚ ‘ ¢ ‡ ‚ € ‚ †  { † z { € z „ † – Ÿ € | x Ž {  y … x ­ † ‚ ƒ y ‚  ‚ €
„ “ † ‚ … ” x … | „ † ƒ x † „ † x … ‚ x | { } x … ƒ „ … | „ † x | y ‡ € „ †  | „ †
ƒ „ † { “ | ‚ † { € z ‚ € z „ †  ‚ Ž … x y  ‚ Š † y … ‚ † „ | y ~ {  € –
XVI Jornadas de Paralelismo, JP '2005 737
                       !   #   !
% ' ) + - . - 1 3 5 7 9 : 9 + 3 5
< > @ A C @ > F @ C G I @ J G L M O F C @ @ S C G J @ J G L M S > F A F M X @ O @
Y
F Z \ A J \ M J C ^ G O \ ` ^ F > F A ^ C X @ Z ^ c G M X F > F A @ M X F C @
F C @ f \ > @ J G L M O F
Y
F > > @ Z G F M X @ A @ ^ X \ Z @ X G I @ O @ A j
f @ A @ O @ A F M C @ A Z \ O F > M @ A X F J M \ C \ m n @ A O F p F f j ` ^ F
@ A G A X @ M F M C @ C @ f \ > O \ J F M X F r s ^ M ` ^ F F C X > @ f @ v \
> F @ C G I @ O \ S ^ F O @ > F A ^ C X @ > M \ Z ^ c M \ w F O \ A \ j A G ` ^ F
J > F F Z \ A ` ^ F \ y > F J F @ C m ^ M @ A w F M X @ v @ A y > F M X F @ \ X > \ A
A G A X F Z @ A A G Z G C @ > F A r z M S @ > X G J ^ C @ > F C
Y
F J
Y
\ O F
> F ` ^ F > G > ^ M @ } M G J @
Y
F > > @ Z G F M X @ O F @ ^ X \ > f @ A @ O @ F M
~  € ` ^ F y @ J G C G X @ Z ^ J
Y
\ C @ X @ > F @ O F m F M F > @ J G L M O F
J \ M X F M G O \ A r
z C O G A S \ M F > O F ^ M F M X \ > M \ G M X F m > @ O \ O F
O F A @ > > \ C C \ O F Z @ X F > G @ C O \ J F M X F F M y \ > Z @ X \ A
@ f G F > X \ A c O F @ S C G J @ J G \ M F A O F @ J J F A \ @ O G J
Y
\
Z @ X F > G @ C j X @ M X \ S \ > S @ > X F O F S > \ y F A \ >
F A J \ Z \ O F
@ C ^ Z M \ A S ^ F O F G M J > F Z F M X @ > O F y \ > Z @ Z ^ c
A G m M G y G J @ X G w @ C @ F y G J G F M J G @ c C @ F y F J X G w G O @ O O F C
@ S > F M O G I @ v F r z M F A X @ C n M F @ M \ A S > \ S \ M F Z \ A
F C @ f \ > @ > \ X > @ A
Y
F > > @ Z G F M X @ A J \ Z \ ’
“
z M X \ > M \ S @ > @ C @ F O G J G L M O F X F – X \ j m > — y G J \ A j
F J ^ @ J G \ M F A c @ M G Z @ J G \ M F A f @ A @ O \ F M
™ \ J f \ \ š j  @ X
Y
 € c  Ÿ  
“ ¢
F > > @ Z G F M X @ S @ > @ F C @ C Z @ J F M @ Z G F M X \ j
A F C F J J G L M c J \ Z S G C @ J G L M O F J \ M X F M G O \ A r
“
z – X F M A G L M O F C @ m F M F > @ J G L M O F > F S \ A G X \ > G \ A @
\ X > \ A y \ > Z @ X \ A ~  € J \ Z \ § \ > O  € c
¨ S F M ¨ y y G J F ~  € © ª « r
“
z C @ f \ > @ J G L M O F A G Z ^ C @ O \ > F A G M X F > @ J X G w \ A
f @ A @ O \ A F M @ S S C F X A © ­ « r
“
s S C G J @ J G \ M F A S @ > @ C @ A ^ S F > w G A G L M O F
A G Z ^ C @ O \ > F A G M X F > @ J X G w \ A O F A O F A F > w G O \ > p F f r
€ @ A X F J M \ C \ m n @ A f — A G J @ A ` ^ F M \ A S @ > F J F M Z — A
@ O F J ^ @ O @ A S @ > @ @ J \ Z F X F > F A X @ A X @ > F @ A A \ M ~  € c
¯ @ w @ r z C J @ > — J X F > @ f G F > X \ O F ~  € c A ^
G M O F S F M O F M J G @ O F J ^ @ C ` ^ G F > y @ f > G J @ M X F \ @ S C G J @ J G L M
@ A F m ^ > @ M ^ M @ X \ X @ C G M O F S F M O F M J G @ O F C \ A O @ X \ A j @ A n
Z G A Z \ ¯ @ w @ F A ^ M @ S C @ X @ y \ > Z @ S @ > @ F C O F A @ > > \ C C \
O F @ S C G J @ J G \ M F A G M O F S F M O G F M X F O F C A G A X F Z @
\ S F > @ X G w \ c \ > G F M X @ O @ F A S F J n y G J @ Z F M X F @ · M X F > M F X j
S @ > @ C @ ` ^ F A F O G A S \ M F O F F M X \ > M \ A O F O F A @ > > \ C C \
Z ^ c S > \ O ^ J X G w \ A r
¸ ¹ 7 ¹ + ¹ » ¼ ½ - 5
© ¾ « z Z G C G \ ¿ \ M X > F > @ A  ^ Á \ I r z C S > \ y F A \ >
^ M G w F > A G X @ > G \ c C @ F w @ C ^ @ J G L M O F C \ A @ C ^ Z M \ A r
· ¿ z r  M G w F > A G O @ O à \ C G X Ä J M G J @ O F  @ O > G O r ¾ ­ ­ ­
© Å « Ÿ G w F š ¿
Y
\ S > @ j s Z G X Æ @ š \ > F r à > \ y F A A G \ M @ C
s S @ J
Y
F < \ Z J @ X Ç r § > \ – à > F A A r Å È È É
© Ê «
¢
@ M A Æ F > m A X F M r ¯ @ w @  F > w F > à @ m F A r ¨ Ë Ì F G C C c r
Å È È Ê
© É «  ^ F  S G F C Z @ M r ¯  < € ’ S > @ J X G J @ C m ^ G O F y \ > ¯  Ã
S > \ m > @ Z Z F > A r  \ > m @ M Í @ ^ y Z @ M M r Å È È Ê
© Ç « Æ > F X X  J C @ ^ m
Y
C G M r ¯ @ w @ @ M O ~  € r ¨ Ë Ì F G C C c r
Å È È ¾
© Î « z C C G \ X F Ì ^ A X c
¢
@ > \ C O j § r  J \ X X  F @ M A r ~  €
G M @ M ^ X A
Y
F C C r ¨ Ë Ì F G C C c r Å È È É
© Ï « Æ \ f  X @ c X \ M r ™ \ J f \ \ š ~  € r <
Y
F J \ Z S C F X F
m ^ G O F r Å È È Ê
© ª « s r   \ M I — C F I r  @ š G M m j ¨ > m @ M G I G M m @ M O Ì F ^ A G M m
€ F @ > M G M m  @ X F > G @ C p G X
Y
¨ S F M ¨ y y G J F r  z Ñ ·
s M M ^ @ C ¿ \ M y F > F M J F <
Y
F ~ ~ · ¿ F M X ^ > c j X
Y
F
738 Docencia en Arquitectura y Tecnología de Computadores
                      
        ! " # # $
% & ' )
! *  , -   , . / ! 0 ! 2    6  , ! 7        9        :
                  :  :    A     
   C         ! 7          0        
H
    
H
       ! " # # J
XVI Jornadas de Paralelismo, JP '2005 739
Enseñando Paralelismo con una consola PlayStation c

2
David Rubio Raúl Tovar Jesús González
Dept. de Arquitectura y Tecnología de Computadores
ETS Ingeniería Informática. Univ. de Granada
18071 Granada
davidrubioc@gmail.com inkubu@gmail.com jgonzalez@atc.ugr.es
Resumen
En el presente documento se describen los
componentes que conforman la arquitectura de
PlayStation c
2 y el paralelismo existente en-
tre ellos para explotar el máximo potencial de
esta máquina. Se incluye además la descrip-
ción de una aplicación que hace uso de este
paralelismo. Por último se explica el montaje
de un laboratorio con consolas PlayStation c
2
como herramientas para la docencia en Arqui-
tectura de Computadores.
1. Introducción
La consola de videojuegos PlayStation c
2 se
ha convertido en los últimos cinco años en el
sistema de entretenimiento más extendido del
mundo. Se trata de una plataforma hardware
con carácter cerrado, con un alto potencial en
el procesamiento de audio, video y grácos 3D
en tiempo real además de otro tipo de aplica-
ciones de propósito más general.
Desde el punto de vista de la docencia, la
consola nos ofrece una interesante arquitec-
tura hardware reuniendo entre sus unidades a
un procesador de propósito general dedicado
a la entrada/salida, otro de propósito general
con extensiones multimedia que actuará como
núcleo central de procesamiento, dos proce-
sadores vectoriales, una unidad dedicada al
procesamiento de imagenes y todo ello comu-
nicado mediante un bus central de 128 bits.
La consola ofrece su mayor potencial cuando
los anteriores procesadores y unidades traba-
jan en paralelo comunicados mediante DMA.
El potencial hardware antes descrito, junto
a las aplicaciones gratuitas para trabajar en
ella y unido a la motivación que ofrece esta
plataforma lúdica para el alumnado, la con-
vierte en una herramienta a considerar en la
docencia de Arquitectura de Computadores.
2. Descripción breve de la Arqui-
tectura
La consola PlayStation c
2 (en adelante
PS2 c
) está compuesta por:
• Emotion Engine: Comprende varios
procesadores y unidades. Su núcleo es
un MIPS R5900, en adelante EECore,
que trabaja a una frecuencia de 300
MHz y funciona con el repertorio de
instrucciones MIPS III junto con algunas
instrucciones del repertorio MIPS IV y
128 instrucciones especícas multimedia.
Para más información podemos consultar
el manual de referencia de Sony [6].
El Emotion Engine, de aquí en adelante
EE, dispone además de dos unidades de
procesamiento vectorial conocidas como
VPU0 y VPU1 [7], ambas ensambladas
en la misma placa junto al EECore y
otras unidades importantes. Las unidades
de procesamiento vectorial, como su nom-
bre indica, son unidades especializadas en
operar con datos de tipo vectorial, es de-
cir, que pueden ser almacenados en ar-
rays unidimensionales o multidimension-
ales. Su funcionalidad es similar a las ex-
tensiones MMX y SSE de Intel.
Cada VPU posee un núcleo de proce-
samiento conocido como VU junto con
una memoria de datos (VUMem), una
memoria de microprograma (microMEM)
y una interfaz de comunicación VIF a
través de la cuál se harán las transferen-
cias de datos y se recibirán los comandos
de ejecución que más adelante veremos.
Figura 1: Emotion Engine
VPU0 y VPU1 no son iguales. La prin-
cipal diferencia radica en que VPU1
posee más unidades funcionales: una EFU
(unidad para operaciones trigonométricas
y exponenciales) y una RANDU (unidad
de número aleatorios), lo que le otorga
más exibilidad para determinados cóm-
putos. La VPU1 tiene 16 KB de memoria
de datos y otros 16 KB en memoria de mi-
croprograma frente a los 4 KB por cada
memoria en la VPU0. Otra diferencia fun-
damental es que la VPU1 tiene conexión
directa con el Sintetizador Gráco (GS)
y puede dibujar en pantalla sin la inter-
vención del EEcore.
• Sintetizador Gráco : Procesador encar-
gado de dibujar en pantalla.
• IOP: Procesador de Entrada/Salida y
manejo de dispositivos externos. Se tra-
ta de un MIPS R3000 que trabaja a una
frecuencia de 33 MHz, funciona con el
repertorio de instrucciones MIPS III y es-
tá conectado al EE mediante los canales
DMA 5, 6 y 7. Sobre dichos canales lo usu-
al es implementar una comunicación me-
diante RPC (Remote Procedure Call). Los
programas ejecutables para este proce-
sador son conocidos como módulos y se
suelen cargar al principio de la apli-
cación. Estos módulos realizan la función
de driver de los dispositivos externos,
aunque este procesador puede ser usado
con otros nes menos especícos ya que
es un procesador de propósito general. El
comportamiento usual de dichos módu-
Figura 2: Arquitectura de la PS2 c


los es el de trabajar como hebras servi-
doras que se ejecutan concurrentemente
y pueden comunicarse entre ellas. El EE
se comunica con estas hebras mediante
las llamadas RPC. Para obtener informa-
cion más detallada sobre este procesador
se puede recurrir a la especicación de la
PlayStation c
 one ya que éste es el proce-
sador central de dicha consola.
• SP: Procesador de Sonido.
• 32 MB RD-RAM
Además de lo explicado anteriormente sobre
las unidades vectoriales éstas tienen dos modos
de funcionamiento:
• Micromodo: El procesador vectorial actúa
como standalone, es decir, como proce-
sador independiente.
• Macromodo: El procesador vectorial ac-
túa como coprocesador del EEcore.
La unidad VPU0 puede actuar en Micromodo
y en Macromodo, mientras que,la VPU1 sólo
lo puede hacer en Micromodo.
Las microinstrucciones son de tipo LIW
(Long Instruction Word), instrucciones de 32
bits × 2 y pueden ser ejecutadas concurrente-
mente. Una instrucción Upper usa los 32 bits
superiores de la palabra-instrucción mientras
que una instrucción Lower usa los 32 bits
inferiores de la palabra-instrucción. Las in-
strucciones Upper controlan el FMAC y las
instrucciones Lower controlan las unidades
FDIV/EFU/LSU/BRU y las operaciones con
registros enteros.
3. Aplicación
La aplicación que se ha desarrollado para la
consola consiste básicamente en un cubo gi-
742 Docencia en Arquitectura y Tecnología de Computadores
rando sobre sí mismo y en la parte baja de la
pantalla un texto que se desplaza de izquierda
a derecha; el fondo de pantalla es una imagen
animada por ondas concéntricas en movimien-
to; mientras tanto suena una melodía de fondo;
la translación del cubo puede ser controlada
mediante el uso del pad(mando de la consola),
pudiendo de esta forma mover el cubo por la
pantalla.
Una vez que se ha introducido la aplicación
desarrollada veamos la distribución de carga
que se puede realizar para que este proce-
samiento sea viable. Hemos dividido la apli-
cación en partes según su funcionalidad:
• Lectura del pad
• Procesamiento y reproducción del sonido
• Cubo en movimiento
• Fondo animado
• Texto en movimiento
Teniendo en cuenta la arquitectura de la
consola, las distintas partes de la aplicación
han sido asignadas a los elementos hardware
de la consola de la siguiente forma:
• IOP: Lectura del pad y Procesamiento y
reproducción del sonido.
• EEcore + VPU0 en macromodo: Cubo
en movimiento.
• EEcore: opcionalmente fondo animado.
• VPU1: Texto en movimiento y opcional-
mente fondo animado.
El fondo animado es posible ejecutarlo tanto
en el EEcore como en la VPU1. Se le da la
opción de elegir al usuario pulsando el botón
select en el pad. A continuación veremos el
procesamiento llevado a cabo en cada unidad
con más detalle.
3.1. IOP
La lectura del pad se lleva a cabo en este
procesador debido a que la propia arquitectura
de la consola nos obliga a ello, ya que es éste
el único procesador que tiene acceso directo al
controlador del pad. En el caso de la reproduc-
ción del sonido ocurre como en el caso anteri-
or, ya que el IOP es el único procesador que
tiene acceso directo a la SPU. Además de es-
tas tareas el procesamiento/decodicación del
sonido tambien se ejecuta en el IOP ya que el
formato de sonido MOD ([2]) no necesita de-
masiada capacidad de cómputo+ para su de-
codicación. Esta asignación de tareas deja al
EECore mác capacidad de cómputo para el
resto de la aplicación.
3.2. EEcore + VPU0 en macromodo
Estos dos procesadores de encargan de la
rotación/translación del cubo, aprovechando
que estas funciones se modelan mediante op-
eraciones con vectores, que es precisamente el
uso para el que se ha diseñado el VPU0.
3.3. EEcore
Como se comentó anteriormente podemos
usar tanto este procesador como la VPU1 para
realizar los cálculos necesarios para la ani-
mación del fondo. Dicha animación consiste en
aplicar al fondo una ecuación sinusoidal vari-
able con el tiempo y modicable por el usuario.
Aprovechando que el EEcore es el proce-
sador más exible de la consola, el cálculo de
la ecuación anterior se lleva a cabo sin demasi-
adas dicultades.
3.4. VPU1
Otra opción a la hora de asignar las tareas
a los procesadores es usar la VPU1 en vez del
EECore para realizar la animación del fon-
do. Para ello, se puede hacer uso de tablas
(lookup tables) para el cálculo de los senos y
cosenos. Los parámetros son enviados al VU1
a través del VIF1 y tras la espera del cálculo
mediante el método VU1Wait, el resultado de
la ecuación es leído accediendo a la VU1mem
mapeada en memoria principal. El texto en
movimiento se lleva a cabo en el VPU1 ha-
ciendo uso de su conexión directa con el GS.
El VU1 hace el cálculo de coordenadas del tex-
to en pantalla para que éste se desplace lat-
eralmente y tras ese cálculo, envía la orden de
dibujado al GS sin intervención de ningún otro
procesador.
Esta opción obtiene peores resultados que el
uso de EECore ya que el VPU1 introduce un
retardo considerable debido al método VU1
Wait que es necesario para la sincronización
entre procesadores.
XVI Jornadas de Paralelismo, JP '2005 743
Figura 3: Formato de un comando VIF
4. Ejecución de Código en las difer-
entes unidades de la consola
Tras haber realizado una introducción a la
arquitectura de la consola veremos la forma en
la que se puede mandar trabajo a las diferentes
unidades de la consola.
4.1. Transferencias entre EEcore y VU0
VU1
De poco serviría tener varios procesadores
en una misma placa si no existiera comuni-
cación entre ellos. Existen dos formas de trans-
ferir datos a las unidades vectoriales: a través
de VIF0VIF1 y aprovechando que tanto las
memorias de datos (VUMem) como las memo-
rias de microprograma (microMEM) de VU0
VU1 están mapeadas en memoria principal.
Con esta segunda opción escribiremos y leere-
mos en ellas directamente aunque con ciertas
restricciones que veremos más adelante. Sin
embargo las transferencias a través del VIF son
en un solo sentido, sólo se puede escribir en las
memorias de las unidades vectoriales.
4.2. A través de VIF0 y VIF1
En primer lugar conozcamos qué son la
VIF0 y la VIF1. VIF0 y VIF1, situadas en
el VPU0 y VPU1 respectivamente, se encar-
gan de desempaquetar los datos que le llegan a
través del DMA y los transeren a la dirección
especicada dentro de las memorias internas
de cada VPU, memoria de datos o memoria
de microprograma, según proceda.
VIF0 y VIF1 pueden ejecutar instrucciones,
es decir, dentro del paquete DMA que reciben,
encontraremos datos junto con instrucciones
especícas de VIF que actuarán sobre dichos
datos. Una instrucción VIF tiene una longi-
tud de 32 bits y su formato se muestra en la
Figura 3. Los tres campos de los que consta el
instrucción VIF son:
• CMD: código que indica la operación a
realizar por el VIF, por ejemplo UNPACK
para desempaquetar datos, MSCAL para
iniciar la ejecución de un microprograma,
etc.
• NUM: indica la cantidad de datos que
serán escritos en la memoria de micropro-
grama o en la memoria de datos. Nótese
que esta cantidad viene expresada en
unidades de 128 bits y puesto que el cam-
po NUM consta de 8 bits, tendremos que
la máxima cantidad de datos por trans-
ferencia es 4 Kbytes.
• IMMEDIATE: El contenido de este cam-
po varía dependiendo del comando CMD.
4.3. A través de la memoria mapeada
Este otro método consiste en leer/escribir
en aquellas zonas de memoria principal donde
se encuentran mapeadas las memorias internas
de datos o de microprograma de cada VPU.
Este método tiene la clara ventaja de que
es muy fácil acceder a las memorias internas
de los VPUs, pero para efectuar dicho acceso
existen restricciones.
• VPU0: para acceder a la memoria de
datos o a la memoria de microprograma
es necesario que el VU0 esté parado, que
en ese momento no haya transferencias a
través del VIF0.
• VPU1: para acceder a la memoria de
datos o a la memoria de microprograma
es necesario que el VU1 esté parado, que
en ese momento no haya transferencias
a través del VIF1 y que tampoco haya
transferencias DMA entre el EEcore y el
GS.
Por otra parte, desde el VU0 se puede acced-
er a los registros del VU1 ya que, éstos se en-
cuentran mapeados en la memoria de datos del
VPU0. Como única restricción para este acce-
so, se exige que el VU1 se encuentre parado en
ese momento.
4.4. Computación paralela entre EEcore,
VU0 y VU1
El paralelismo entre EEcore, VU0 y VU1
(de ahora en adelante utilizaremos VU0VU1
para denotar VU0 o VU1) se consigue gracias
al modo de operación en micromodo de estos
dos últimos. Cuando VU0VU1 trabajan en
micromodo se comportan como procesadores
744 Docencia en Arquitectura y Tecnología de Computadores
standalone, es decir, como procesadores in-
dependientes del EECore.
Haciendo uso de la característica anteri-
or, podremos extraer muchas de las venta-
jas que de la computación paralela se de-
sprenden, pudiendo entre otras opciones, ten-
er tres procesadores trabajando simultánea-
mente en la misma tarea o en diferentes tar-
eas. Dado que EEcore, VU0 y VU1 tienen su
propia memoria independiente y excepcional-
mente solo EEcore puede acceder a la memo-
ria de datos de los otros dos, pero con una al-
ta penalización, es recomendable que los tres
procesadores trabajen en paralelo y en tareas
independientes.
El máximo paralelismo que se puede ex-
traer, dada la especialización de VU0 y VU1
para trabajar con vectores y la conexión direc-
ta del VU1 con el GS, sería cuando el proce-
sador VU1 se dedique a trabajar en micro-
modo es dedicada a trabajar con la geometría
del mundo 3D en operaciones tales como rota-
ciones, translaciones, cambios de perspecti-
va, y luces mientras que, EEcore + VU0 en
macromodo se encargan de asignarle tareas de
geometría al VU1 y realizar otras tareas que
requieran de más exibilidad, como manejar la
IA del juego, manejar la física del mundo 3D,
detección y manejo de colisiones; y un largo
etcétera. De este tipo de paralelismo hay que
destacar que la VU1 mandará directamente
las primitivas de dibujado al GS sin interven-
ción directa del EEcore. Estas primitivas son
tratadas con la máxima prioridad por el GS.
Para llevar a cabo el paralelismo anteri-
ormente descrito necesitaremos sincronización
entre el EEcore y las dos unidades vectoriales
VU0 y VU1. Existen tres formas diferentes de
llevar a cabo esa sincronización:
• VU1Wait: esta sincronización es solo
aplicable entre EEcore y VU1. La razón
de esto es que el EEcore emplea al VU0
en macromodo para consultar el estado
del VU1 dado que, VU0 tiene conexión di-
recta con VU1. El EEcore permanecerá
indenidamente en un bucle de consulta a
la espera de que el VU1 termine su tarea.
Como es obvio, la desventaja de esta
sincronización es que el EEcore per-
manecerá parado durante un tiempo in-
denido. Por otra parte la ventaja de este
tipo de sincronización es que es muy fácil
de implementar.
• Interrupción generada por VIF0VIF1:
como ya se ha comentado anteriormente,
una de las formas de transferir datos des-
de el EEcore hacia la memoria de datos
o la memoria de programa del VU0VU1
es a través del VIF0VIF1. Cuando quer-
emos que un cierto código VIF genere una
interrupción tras su nalización, debemos
poner el bit más signicativo del cam-
po CMD a 1. Con esto conseguimos que
cuando la VIF0VIF1 termine de ejecutar
el código en cuestión, genere una inter-
rupción lo que provocará que el siguiente
código VIF permanezca en espera.
Este método de sincronización aventaja
al anterior claramente en el aspecto de
que ahora el EEcore estará funcionan-
do paralelamente al VU0VU1 hasta que
una interrupción le avise explícitamente
que el VU0VU1 ha terminado su tarea.
La utilidad que de esta interrupción se
puede extraer con respecto al paralelis-
mo es activar la interrupción de los códi-
gos VIFMSCAL, VIFMSCNT o VIF
MSCALF, estos tres códigos se encargan
de ejecutar un microprograma residente
en la micromemoria del VU y cuando
dicha ejecución haya nalizado, una in-
terrupción será generada. La desventaja
de éste método radica en que aumenta
la complejidad de código implementado y
el riesgo añadido de que la interrupción
puede saltar en cualquier parte del códi-
go ejecutado por el EEcore por lo que,
habría que tener una lógica adicional que
controle éste riesgo.
• Interrupción generada por VU0VU1:
este tipo de interrupción se genera por
cualquier microinstrucción que se ejecute
en el VU0VU1 y que haya sido congura-
da para ello. Congurar una microinstruc-
ción para que ésta active la interrupción
VU0VU1 consiste en que dicha microin-
strucción ponga el bit , o el bit 6 a 1.
Esto llevado a código puede ser visto en
la Figura 4.
En el código anterior vemos como en la
línea 2 aparece una microinstrucción nop
seguida de una @ entre corchetes, al igual
que en la línea 3 aparece una J entre
corchetes. Ambas microinstrucciones po-
nen los bits @ y J a 1 (enable) y como con-
secuencia se generará una interrupción de
XVI Jornadas de Paralelismo, JP '2005 745
ftoi0.x vf06x, vf01x nop ;1
nop[d] nop ;2
nop[t] nop ;3
nop nop ;4
Figura 4: Ejemplo de activación de interrupcción
en las unidades vectoriales
Figura 5: División del código en función de la ar-
quitectura de la consola
tipo VU0VU1.
Este método de sincronización, al igual
que el anterior, ofrece la ventaja de que
el EEcore no necesita permanecer en es-
pera de que el VU0VU1 nalice su tarea
sino que, la interrupción VU0VU1 será
el indicativo de éste evento. Además, este
método de sincronización ofrece la venta-
ja de ser más fácil de implementar que
el VIF0VIF1 anteriormente visto, pero
también añade la desventaja de complicar
el ujo de programa y el riesgo de inter-
rupción visto en el punto anterior.
5. Montaje del Laboratorio
Un laboratorio que nos permita desarrol-
lar código ejecutable para la PlayStation c
2
puede ser desde un simple PC a una red de or-
denadores y consolas para trabajo en equipo.
Un ejemplo de laboratorio de desarrollo es el
que se encuentra situado dentro la Escuela
Técnica Superior de Ingeniería Informática en
el Departamento de Arquitectura y Tecnología
de Computadores de la Universidad de Grana-
da se puede ver en la Figura 5 y se encuentra
Figura 6: Laboratorio de desarrollo
Figura 7: Conexión directa PC-PS2 c


en [1]. Para poder desarrollar código para la
PlayStation podemos recurrir a los kits de de-
sarrollo que encontramos en los sitios web es-
pecializados. El hardware necesario para poder
montar un puesto de desarrollo consta de:
• Un PC (con tarjeta de red Ethernet
10/100).
• Una Videoconsola (PS2 c
-two o
PlayStation c
2 con tarjeta de red).
• Software de desarrollo (Ps2Dev, Ps2SDK,
etc).
• Un Conversor de Señal para poder conec-
tar la salida de vídeo de la consola con el
monitor del puesto de desarrollo.
La conexión del PC con la consola puede
hacerse directamente (con un cable de red
RJ45 cruzado, Figura 7) o mediante un con-
centrador (Figura 8), si lo hacemos con un con-
centrador tendremos la ventaja de poder con-
trolar varias consolas desde un PC.
El software necesario para desarrollar códi-
go para PlayStation c
2 se basa en una serie de
compiladores cruzados. El sofware de desarrol-
lo que se ha utilizado es el siguiente:
746 Docencia en Arquitectura y Tecnología de Computadores
Figura 8: Conexión a través de un concentrador
Figura 9: Ejemplo de puesto de desarrollo
• PS2DEV: kit de desarrollo en el que en-
contraremos compiladores para EE, IOP
y Unidades Vectoriales creados con GCC
v3.2.2, para más información podemos
visitar su sitio web referenciado en [4].
• PS2SDK: Conjunto de librerías Open
Source que nos permiten acceder a fun-
ciones internas del sistema operativo de
la PlayStation c
2, controlar el PAD, ac-
ceso a la memory card, acceso a la pila
de TCP/IP, acceso al CD/DVD, etc. Para
más información podemos visitar su sitio
web referenciado en [5].
Una vez que tenemos el software desarrollado
y compilado podemos probarlo utilizando la
red como medio de comunicación entre el PC
y la consola. La forma de lanzar código en la
PlayStation c
2 es mediante un software servi-
dor que ejecutamos en la misma, este software
Figura 10: Xlink
puede ser Ps2Link, Pukklink, o cualquiera de
las otras versiones del mismo. En el PC eje-
cutaremos un cliente de dicho software que
puede ser Xlink 5 Otra forma de probar códi-
go desarrollado en la PlayStation c
2 sin uso de
la red de comunicación es grabar en un CD el
código objeto empaquetado, el empaquetado
del código es la fase anterior a la grabación en
CD y sirve para preparar el código para ejecu-
tarse desde cd, y probarlo directamente en la
consola como si de un videojuego se tratase, di-
cho software puede ser obtenido desde la pági-
na web de PS2DEV en [4]. Los problemas que
conlleva esta solución es el desperdicio en CD's
que se genera debido a que para que un cam-
bio se vea reejado es necesario recompilar el
código fuente y por lo tanto es necesario volver
a grabar otro CD.
Finalmente hay que destacar que tanto para
un método como para otro es necesario tener
un modchip instalado en la consola. Un mod-
chip es un elemento interno que se le instala a
la consola para que permita ejecutar el código
generado por nosotros mismos.
XVI Jornadas de Paralelismo, JP '2005 747
6. Posibles prácticas realizables en
la consola
Las posibles prácticas realizables en la
PlayStation c
2 pasan por tratar de trabajar
con cada uno de los procesadores de la misma.
Por ejemplo:
• Programación en código ensamblador uti-
lizando instrucciones VLIW con slots
para 2 instrucciones sobre las uniades vec-
toriales.
• Programación Superescalar usando el
MIPS.
• Programación usando Hebras usando el
IOP.
• Programación Paralela usando todos los
procesadores de la consola.
• Multicomputación, usando varias conso-
las para que trabajen como una única
unidad de computación.
• Programación gráca utilizando librerías
existentes (LlibPlanar [3], PbDemoLib
[4], etc)
7. Conclusión
Podemos concluir que la consola
PlayStation c
2 es una herramienta con
una alta capacidad de motivación para la do-
cencia, al ser una conocida plataforma lúdica,
además de posibilitar la implementación de
prácticas que estudian diferentes aspectos
cubiertos por el área de Arquitectura y
Tecnología de Computadores, como se ha
mencionado anteriormente. Estamos ante un
excelente ejemplo de plataforma real que usa
el paralelismo entre procesadores.
8. Agradecimientos
Este artículo se ha llevado a cabo dentro
del proyecto de innovación docente Uso de
la Consola Sony PlayStation c
2 como her-
ramienta de docencia de Arquitectura de Com-
putadores, nanciado por el Vicerrectorado
de Planicación, Calidad y Evaluación Do-
cente de la Universidad de Granada, gracias
al que se ha podido adquirir el hardware nece-
sario para su desarrollo.
Referencias
[1] Comunidad PlayStation Universidad de
Granada. http://ps2.ugr.es.
[2] Ficheros MOD.
http://www-cs-
students.stanford.edu/ franke/SoundApp/formats.html.
[3] LlibPlanar, Angel Garbayo Dominguez.
http://ps2dev.ofcode.com/.
[4] PS2DEV. http://ps2dev.org.
[5] PS2SDK. http://ps2dev.org.
[6] Sony Computer Entertainment Inc. EE
User's Manual Version 3.1, 2001.
[7] Sony Computer Entertainment Inc. VU
User's Manual Version 3.1, 2001.
748 Docencia en Arquitectura y Tecnología de Computadores
ÍNDICE DE AUTORES
Abda Fidalgo, Pablo..........................................................................................395
Acacio Sánchez, Manuel Eugenio........................................................91,101,285
Acosta Ojeda, Carmelo Alexis............................................................................59
Aldasht, Mohammed.........................................................................................467
Alfaro Cortés, Francisco José.............................................................235,259,275
Almeida, Francisco...........................................................................................527
Alonso Díaz, Marina.........................................................................................181
Andrade, Diego.................................................................................................321
Andreu García, Gabriela...................................................................................631
Aparicio, Luis Carlos........................................................................................329
Arbelaitz, Olatz.................................................................................................639
Arnal García, Josep...........................................................................................487
Ávila Bermúdez, Rafael....................................................................................585
Ayguade, Eduard...............................................................................................403
Ayuso Escuer, Natalia.......................................................................................713
Badía, José M....................................................................................................411
Balart, Jairo.......................................................................................................403
Baños Navarro, Raul.........................................................................................655
Baydal, Elvira....................................................................................................189
Beivide, Ramon..........................................................................................125,133
Beltrán Pardo, Marta..................................................................................459,553
Beltran, Vicenç..................................................................................................301
Benavides Benítez, José Ignacio................................................................309,313
Bermúdez, Aurelio............................................................................................117
Bianchini, German............................................................................................623
Blanquer Espert, Ignacio...................................................................................339
Bofill Soliguer, Pau...........................................................................................717
Bosque, José Luis..............................................................................................459
Boullón Magán, Marcos....................................................................................363
Bustamante, Paul...............................................................................................695
Cabaleiro Domínguez, José Carlos...................................................................363
Calderón Mateos, Alejandro.............................................................................347
Caminero Herráez, Agustín C...........................................................................221
Caminero Herráez, Blanca................................................................................221
Cañamares, Nuria..............................................................................................695
Capel Tuñón, Manuel Isidoro...........................................................................495
Carcelen, Miguel Angel....................................................................................733
Carrera, David...................................................................................................301
Carretero Pérez, Jesús................................................................................347,387
Carretero, Jesús.................................................................................................685
Carrión Espinosa, Carmen................................................................................221
Casado, Rafael..................................................................................................117
Castro Rodríguez, Fernando...............................................................................27
Cazorla Almeida, Francisco Javier................................................................51,67
Cesar, Eduardo..................................................................................................443
Chaver, Daniel...............................................................................................19,27
Civit Balcells, Antón.........................................................................................703
Coll Arnau, Salvador.........................................................................................197
Colmenar, J. Manuel.........................................................................................293
Corbalán, Julita..........................................................................................379,435
Cortés, Ana........................................................................................................623
Cortés, Toni.......................................................................................................419
Costa, Juan José................................................................................................419
Cristal, Adrián......................................................................................11,43,75,83
Cuenca Castillo, Pedro......................................................................................267
Dana Pérez, José Miguel............................................................................229,537
de la Viesca Santafé, Carlos..............................................................................371
de Sande, Francisco...........................................................................................411
de Toro, Francisco J..........................................................................................663
Díaz Alonso, Javier...........................................................................................725
Díaz García, Juan..............................................................................................585
Díaz, Antonio F..........................................................................................213,467
Doallo, Ramón..................................................................................................321
Dorta González, María Isabel...........................................................................519
Dorta, Antonio J................................................................................................411
Duato Marín, José................141,149,157,165,173,181,189,197,243,251,259,275
Durán, Alejandro........................................................................................379,403
Escolar, María Soledad.....................................................................................387
Expósito Singh, David......................................................................................685
Falcón, Ayose......................................................................................................59
Farreras, Montse................................................................................................717
Fernández Fernández, Juan Carlos....................................................................591
Fernández García, Enrique.............................................................................43,51
Fernández Peinador, Juan.................................................................................205
Fernández Pena, Tomás....................................................................................363
Fernández Rivera, Francisco.............................................................................363
Fernández Rodriguez, Jose Jesus......................................................................561
Fernández, Pascual............................................................................................647
Ferrer i Pérez, Joan-Lluís..................................................................................189
Flich, José.....................................................................................141,149,157,173
Fraguela Rodríguez, Basilio B..........................................................................321
Fuentes, Antonio...............................................................................................355
Galiano Ibarra, Vicente..............................................................................487,511
Galluzzi, Marco...................................................................................................83
García Arbelo, Alejandro....................................................................................43
García Arenas, Maribel.....................................................................................677
García Carballeira, Felix...................................................................................347
García Carrasco, José Manuel...............................................................91,205,285
García Fernández, Inmaculada.....................................................229,537,561,647
García García, Pedro Javier..............................................................................149
García Manso, Almudena.................................................................................371
García Ortiz, Juan Pablo............................................................................229,537
García Palacios, Pablo E...................................................................................205
García Rodríguez, Sebastián......................................................................229,537
García Sánchez, José Daniel......................................................................347,387
García, Eva M...................................................................................................117
García, Félix...............................................................................................387,685
García, Isabel....................................................................................................545
García, Jorge.....................................................................................................427
García, José Manuel..........................................................................................101
Garnica, Oscar...................................................................................................293
Gil, Consolación................................................................................................655
Giné, Francesc...................................................................................................615
Gómez Requena, María Engracia.....................................................................165
Gómez, Julio.....................................................................................................655
González García, Rubén.....................................................................................75
González Peñalver, Jesús..................................................................................741
González Ruiz, Vicente..............................................................................229,537
González Téllez, Alberto...........................................................................591,733
González, Daniel...............................................................................................527
González, Marc.................................................................................................403
Górriz, Juan Manuel..........................................................................................467
Guim Bernat, Francesc......................................................................................435
Guirado Fernández, Fernando...........................................................................451
Guitart, Jordi.....................................................................................................301
Gurrutxaga, Ibai................................................................................................639
Gutiérrez, Jaime................................................................................................125
Guzmán Sacristán, Antonio.......................................................................459,553
Hernández García, Vicente...............................................................................339
Hernández Sanz, David.....................................................................................395
Herrera Díaz, Miguel Ángel..............................................................................309
Herruzo Gómez, Ezequiel..........................................................................309,313
Hidalgo, J. Ignacio............................................................................................293
Huecas Fernandez-Toribio, Gabriel..................................................................371
Huedo, Eduardo................................................................................................355
Ibáñez, María Blanca........................................................................................685
Isaila, Florin......................................................................................................685
Izu, Cruz............................................................................................................125
Jiménez Laredo, Juan Luis................................................................................677
Johnson, Ian......................................................................................................149
Juan, Mª Carmen...............................................................................................569
Labarta, Jesús...............................................................................379,403,419,435
Lanchares, Juan.................................................................................................293
Lausuch Sales, Ivan...........................................................................................569
León Hernández, Coromoto................................................................503,519,607
López Albín, Julio.............................................................................................363
López García, Fernando....................................................................................631
López Martínez, Juan I......................................................................................725
López Martínez, Manuel Francisco...........................................................229,537
López Redondo, Juana......................................................................................647
López, Pedro.......................................................................................165,181,189
Luque, Emilio...............................................................................443,451,623,671
M. Llorente, Ignacio..........................................................................................355
March, Maribel..................................................................................................717
Margalef, Tomàs........................................................................................443,623
Marín, Raul.......................................................................................................477
Martín Garzón, Ester.........................................................................................561
Martín Molina, Víctor.......................................................................................677
Martín Ruiz, Sandra..........................................................................................607
Martín, José Ignacio..........................................................................................639
Martínez Fernández, Carmen............................................................................125
Martínez Moráis, Raúl......................................................................................235
Martínez Ortigosa, Pilar....................................................................................647
Martínez Rodríguez, Santi................................................................................615
Martínez Vicente, Alejandro.............................................................................259
Martínez, Carmen..............................................................................................133
Martínez, Juan Miguel......................................................................................181
Martínez, Pablo.................................................................................................545
Martorell, Xavier........................................................................................403,419
Mas Doménech, Ferran.....................................................................................339
Medina, Pedro.....................................................................................................43
Mejía, Andrés....................................................................................................141
Menéndez de Llano Rozas, Rafael....................................................................395
Merelo Guervós, Juan Julián.............................................................................677
Migallón Gomis, Héctor F.........................................................................487,511
Migallón Gomis, Violeta............................................................................487,511
Miguel-Alonso, Jose.........................................................................................109
Millán Marco, Pere...........................................................................................577
Miñana Ropero, Guadalupe..............................................................................293
Mir, Stéphan........................................................................................................67
Miranda Valladares, Gara..........................................................................503,607
Montañana Aliaga, Jose Miguel........................................................................173
Montero, Lídia..................................................................................................301
Montseny, Eduard.............................................................................................577
Mora Más, Francisco J......................................................................................197
Morancho, Enric................................................................................................717
Moreno Díaz, Pilar............................................................................................371
Moreno Vendrell, Andreu.................................................................................443
Moreno, Paloma................................................................................................243
Moretó Planas, Miquel......................................................................................133
Morillo, Pedro............................................................................................243,251
Mostaccio, Diego..............................................................................................671
Mota, Sonia.......................................................................................................663
Muguerza, Javier...............................................................................................639
Nachiondo Farinos, Teresa...............................................................................157
Navajas Modelo, Pedro.....................................................................................313
Naven, Finbar....................................................................................................149
Nemirovsky, Mario...........................................................................................427
Nou Castell, Ramon..........................................................................................301
Olivares Bueno, Joaquín...................................................................................599
Orduña Huertas, Juan Manuel....................................................................243,251
Orozco López, Alejandro..................................................................................101
Orozco-Barbosa, Luis.......................................................................................267
Ortega Lalmolda, Juan Antonio........................................................................713
Ortega, Julio..........................................................................213,467,655,663,725
Ortiz, Andrés.....................................................................................................213
Pajuelo, Alex.......................................................................................................11
Palomares Muñoz, José Manuel.................................................................309,599
Peinado Pinilla, Jesus........................................................................................591
Peláez, Ignacio..................................................................................................527
Pelayo, Francisco J............................................................................................725
Pelegrín, Blas....................................................................................................647
Peña Taveras, Manuel.......................................................................................585
Penadés Martínez, José..............................................................................487,511
Pérez Malumbres, Manuel................................................................................591
Pérez Menor, José María...................................................................................347
Pérez, Jesús Mª..................................................................................................639
Pérez, José María..............................................................................................387
Pericás, Miquel....................................................................................................75
Petit, Salvador.....................................................................................................35
Petrini, Fabrizio.................................................................................................205
Piñuel, Luis....................................................................................................19,27
Plaza Miguel, Antonio......................................................................................545
Plaza, Javier......................................................................................................545
Potenciano Enciso, Víctor.................................................................................585
Prieto Gómez, Pedro.........................................................................................585
Prieto, Alberto............................................................................................213,725
Prieto, Manuel................................................................................................19,27
Puntonet, Carlos G............................................................................................467
Quiles, Francisco J.....................................................................................117,149
Quintana, Enrique S...................................................................................411,477
Ramírez García, Tanausú....................................................................................11
Ramírez, Alex........................................................................................3,51,59,67
Ramos Martínez, Luis M..................................................................................713
Reina, Enrique...................................................................................................695
Ridruejo Pérez, Francisco Javier.......................................................................109
Rioja del Río, Carlos.........................................................................................703
Ripoll, Ana........................................................................................................451
Robles Gómez, Antonio.............................................................................117,189
Robles, Antonio................................................................................................173
Ródenas Picó, David.........................................................................................419
Rodero Castro, Iván..........................................................................................379
Rodríguez Corral, José María...........................................................................703
Rodriguez León, Abelardo................................................................................591
Rodríguez León, Casiano..................................................................................607
Rodríguez Martínez, Diego...............................................................................363
Rodríguez Pedrianes, Jorge...............................................................................607
Rodríguez, Nuria...............................................................................................695
Roig, Concepció.........................................................................................451,615
Rojas, Miguel Ángel...........................................................................................19
Ros Bardisa, Alberto...........................................................................................91
Ros, Eduardo.....................................................................................................663
Rossainz López, Mario.....................................................................................495
Rubio, David.....................................................................................................741
Rueda, Silvia.....................................................................................................251
S. Montero, Rubén............................................................................................355
Sáez Peña, Edmundo.........................................................................................599
Sahuquillo, Julio.................................................................................................35
Sánchez Allende, Jesús.....................................................................................371
Sánchez García, José Luis...................................................................235,259,275
Sánchez Salido, Daniel.....................................................................................599
Santana, Oliverio J......................................................................................3,11,43
Santonja, Vicente..............................................................................................181
Segarra, Juan.....................................................................................................329
Segrelles Quilis, Damià.....................................................................................339
Smith, James E....................................................................................................83
Sorribes, Joan....................................................................................................443
Stenström, Per.....................................................................................................83
Subijana, Xabier................................................................................................695
Suppi, Remo......................................................................................................671
Tabik, Siham.....................................................................................................561
Tirado, Francisco...........................................................................................19,27
Tomàs, Rosana..................................................................................................615
Torres, Jordi......................................................................................................301
Tovar, Raúl........................................................................................................741
Valencia, David.................................................................................................545
Valero, Mateo.......................................................3,11,43,51,59,67,75,83,133,427
Valiente González, José Miguel........................................................................631
Vallejo Gutiérrez, Enrique....................................................................83,125,133
Valls, Magda.....................................................................................................615
Vázquez Poletti, José Luis................................................................................355
Veidenbaum, Alex..............................................................................................75
Verdu, Javier.....................................................................................................427
Vidal, Antonio...................................................................................................569
Villa Aroca, Francisco Javier............................................................................285
Villalón Millán, José Miguel............................................................................267
Villar Ortiz, Juan Antonio.................................................................................275
Villarroel, José Luis..........................................................................................329
Viñals, Víctor....................................................................................................329
Wirz, Raul.........................................................................................................477